GNOME Bugzilla – Bug 579224
ThinkPad X60s and X300, improper brightness adjustment using function keys Fn+{Home,End}, twice long step
Last modified: 2013-03-11 07:46:33 UTC
Please describe the problem: Brightness regulation using function keys works improperly. When I press Fn+{Home,End} than OSD indicator shows two graphical steps instead on one. Regulation step is twice longer than display is capable. OSD indicator is also displayed too long on the screen. Thinkpad X60s is capable to set backlight brightness in 8 levels (measured using Power Manager Brightness Applet): 100-93% => 92-79% => 78-65% => 64-50% => 49-36% => 35-22% => 21-8% => 7-0% But there are only 4 steps using function keys. Reducing goes like this: 100% => 71% => 42% => 14% => 0% Steps to reproduce: 1. Set brightness to 100% on ThinkPad laptop. 2. Reduce brightness using Fn+End. 3. Watch OSD indicator. Two steps instead of one happen. Brightness will be reduced -29%. Actual results: OSD indicator shows two steps instead of one. Pressing Fn+{Home,End} once will do two reducing/increasing. Expected results: Brightness should be reduced/increased in one step -15/+15% only. OSD indicator should show only one graphical step. OSD indicator should disapper earlier. Does this happen every time? yes Other information: Tested also on Lenovo ThinkPad X300. Display is capable to set backlight brightness in 16 levels. But there are only 8 steps using function keys.
X60s running Ubuntu 8.10 X300 running Ubuntu 9.04 RC
This bug is actually in ACPI and has been reported at: http://bugzilla.kernel.org/show_bug.cgi?id=13511
hallo, I have kernel 2.6.32-23 and bug should be fixed, but it is still there. I think main problem is that, kernel increases brightness and also gpm increases it => twice steps try "killal gnome-power-manager" and brightness works properly https://bugs.launchpad.net/gnome-power/+bug/257827
no answer?
(In reply to comment #4) > no answer? Hi Pavol, the problem is still present on my Thinkpad X60s. Brightness works properly after "killall gnome-power-manager" Ubuntu 10.04, kernel 2.6.32-24-generic #42-Ubuntu SMP
http://ubuntuforums.org/showthread.php?p=9809088 my investigation This is not bug of gnome-power-manager the easiest way is making a workaround in g-p-m (I can provide patch), but I don't want that kind of fix, I think it is kernel problem Martin Bajer, could you provide information in this ubuntuforums? thanks and does work brightness control in tty1?
Brightness control works correctly on tty1 - I can change brightness in 7 steps. The problem is in graphical mode only (just 4 steps available in GNOME).
Hallo, I have made branch in Launchpad. You can test it
Created attachment 174538 [details] there is patched file Hi, this is working patch, please, test it. It works at me and my friend => 2/2 works and fixes problem In launchpad, they just a little suck to volunteers (they have a little time)
Comment on attachment 174538 [details] there is patched file This is not a patch. Please provide a patch instead. See http://live.gnome.org/Git/Developers#Contributing_patches
thanks bro, I will modify it tomorrow
Created attachment 175312 [details] [review] patch For the record, this is the patch that Pavel wrote. Note that I'm just the messenger here, I haven't studied it in detail.
thanks martin
With this patch, aren't we assuming that the display gets changed *then* the key is emitted from the kernel? What happens if it's the other way around... I guess we can't detect that without delaying the original increment or decrement. I'm also not sure that doing the operation in gpm_brightness_foreach_resource() is the best idea, as we control many outputs, and can't cache a single output value. i.e. we can't assume we only have one screen attached. One day XOrg is going to support i2c properly, and we need to be able to control the external panel too. Generally keeping cached hardware values around is bound to break machines that do not issue brightness changed events. In the "gnome-power-manager --verbose" log, is the "emitting brightness-changed" output *before* the action is taken to dim the screen? If so, it would be trivial to just ignore any brightness button events if there was a brightness changed event in the last few hundred milliseconds. I think that would be a much better patch.
- resource 1 of 3 TI:14:46:47 TH:0x1d990a0 FI:gpm-brightness.c FN:gpm_brightness_output_get_percentage,333 - hard value=9, min=0, max=15 TI:14:46:47 TH:0x1d990a0 FI:gpm-brightness.c FN:gpm_brightness_output_get_percentage,335 - percentage 60 TI:14:46:47 TH:0x1d990a0 FI:gpm-brightness.c FN:gpm_brightness_foreach_resource,491 - resource 2 of 3 TI:14:46:47 TH:0x1d990a0 FI:gpm-brightness.c FN:gpm_brightness_foreach_resource,491 - resource 3 of 3 TI:14:46:47 TH:0x1d990a0 FI:gpm-backlight.c FN:gpm_backlight_button_pressed_cb,506 - emitting brightness-changed : 60 TI:14:46:47 TH:0x1d990a0 FI:gpm-button.c FN:gpm_button_filter_x_events,121 - Key 232 mapped to key brightness-down TI:14:46:47 TH:0x1d990a0 FI:gpm-button.c FN:gpm_button_emit_type,77 - ignoring duplicate button brightness-down steps are double I don't know, what you mean, but kernel generates event and change brightness (not at all devices), so I think, you have to cache value and compare it with /sys value I don't know howto make it for all screens, ... I put only idea how it should be fixed
please, fix it, it is annoying :/
Why was it marked as NOTGNOME? When I kill GPM I have no problem. ARGH Could you please add to GPM just checking, if brightness was changed by kernel and then npot change it again? It should not be that hard.
(In reply to comment #17) > Could you please add to GPM just checking, if brightness was changed by kernel > and then npot change it again? It should not be that hard. It is that hard. You've got two unfixable races in the kernel->userspace->kernel path. I've tried, and failed, to find any metric or kludge that works. Really, the kernel just has to tell the hardware not to do it's own brightness adjustments, which according to mjg is fairly easy to do.
I see, when I tried it, I just watched file for brightness level, then save it to buffer and compare when button is pressed
(In reply to comment #18) > (In reply to comment #17) > > Could you please add to GPM just checking, if brightness was changed by kernel > > and then npot change it again? It should not be that hard. > > It is that hard. You've got two unfixable races in the > kernel->userspace->kernel path. I've tried, and failed, to find any metric or > kludge that works. Really, the kernel just has to tell the hardware not to do > it's own brightness adjustments, which according to mjg is fairly easy to do. Hi Richard, There is a module parameter /sys/module/video/parameters/brightness_switch_enabled which can be set to 1 or 0, meaning if kernel will change backlight or not once it received a notification(it will always report the event to user space). I was wondering shall we just disable in kernel brightness change by setting that param to 0 when g-s-d starts and restore its value when g-s-d exits? Does this make sense? Thanks.