|
consistent brightness control in liquorix kernels
Hi damentz,
How does liquorix manage to do consistent brightness control when stock distro kernels are having problems especially when DEs provide their own OSDs and implementations of such controls? In Xfce for example, while using the stock distro kernel, the brightness control provided in the DE halves the brightness steppings when using controls specific for that DE (xfce4-power-manager intercepts brightness key presses and handles changing the levels). On a Thinkpad T61, this means that instead of having a 16-level brightness, it now only does 8 levels under Xfce. Here are possible explanations on why this is such [1] [2]. There is also that problem that whenever switching between gettys (Ctrl+Alt F1-F6) and X, the brightness level is not synchronized with the level set under X. However, while using a liquorix kernel, I get consistent brightness control and synchronized levels between a getty and X. I get the native 16-level steppings instead of 8 levels under Xfce. I'm just wondering how liquorix does this, what kernel configs, if any, are responsible for having such great brightness control? Or would a patch or two might be involved? Here's my system info for reference. :: Code :: System: Host: nixbook-t61 Kernel: 3.18-5.dmz.1-liquorix-amd64 x86_64 (64 bit gcc: 4.9.1)
Desktop: Xfce 4.11.8 (Gtk 2.24.23) dm: lightdm Distro: Ubuntu 14.04 trusty Machine: System: LENOVO (portable) product: 7659AC5 v: ThinkPad T61 Chassis: type: 10 Mobo: LENOVO model: 7659AC5 Bios: LENOVO v: 7LETC9WW (2.29 ) date: 03/18/2011 CPU: Dual core Intel Core2 Duo T7300 (-MCP-) speed/max: 800/2001 MHz Graphics: Card: Intel Mobile GM965/GL960 Integrated Graphics Controller (primary) bus-ID: 00:02.0 chip-ID: 8086:2a02 Display Server: X.Org 1.15.1 driver: intel Resolution: 1440x900@60.1hz GLX Renderer: Mesa DRI Intel 965GM GLX Version: 2.1 Mesa 10.5.0-devel (git-661c8bb 2015-02-04 trusty-oibaf-ppa) Direct Rendering: Yes Network: Card-1: Intel 82566MM Gigabit Network Connection driver: e1000e v: 2.3.2-k port: 1840 bus-ID: 00:19.0 chip-ID: 8086:1049 Card-2: Intel PRO/Wireless 4965 AG or AGN [Kedron] Network Connection driver: iwl4965 v: in-tree: bus-ID: 03:00.0 chip-ID: 8086:4230 Drives: HDD Total Size: 500.1GB (9.3% used) Info: Processes: 189 Uptime: 16 min Memory: 447.5/3883.7MB Init: Upstart v: 1.12.1 runlevel: 2 default: 2 Gcc sys: 4.8.2 alt: 4.4/4.6/4.7/4.9 Client: Shell (bash 4.3.111 running in xfce4-terminal) inxi: 2.2.16 Back to top |
|||||
|
Hi braveheartleo,
What stock kernel are you comparing to? It could just be that Liquorix, being closer to upstream, has a patch that's not yet available in Debian's stable or trunk kernel. Also, there's a chance that one of the fixes of our upstream tp_smapi module github site (https://github.com/evgeni/tp_smapi), slipstreamed in the change you linked to. Back to top |
|||||
|
:: Quote :: What stock kernel are you comparing to? It could just be that Liquorix, being closer to upstream, has a patch that's not yet available in Debian's stable or trunk kernel.I'm referring to the Ubuntu kernel that ships with Trusty (3.13.0-45-generic) as well as Utopic (3.16.0-30-lowlatency) under Ubuntu LTS 14.04.1. :: Quote :: Also, there's a chance that one of the fixes of our upstream tp_smapi module github site (https://github.com/evgeni/tp_smapi), slipstreamed in the change you linked to.Hmm, the tp-smapi kernel module being at v0.41 both in liquorix (integrated) and Ubuntu's Universe repos, but liquorix having the more recent code from upstream, that could also be the case. I'll take a look at the commits upstream. UPDATE: There aren't any commits from tp-smapi upstream that would indicate a change in handling brightness functions. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||