GNOME Bugzilla – Bug 340231
Causes rapid, repeating brightness up / down
Last modified: 2006-05-14 22:44:29 UTC
On my IBM x31, the brightness control is all done in hardware, g-p-m sees the key press and then updates the brightness itself. The hardware also synthesises keypresses when the brightness is changed programatically, this means that 2 very quick changes causes g-p-m to get into a state where the brightness changes up and down quickly: - We start off at full brightness (level 7) - I press down (hardware sets to level 6, emits key press) - I press down (hardware sets to level 5, emits key press) - g-p-m sees first key press, sets to level 6, hardware emits sythesised brightess up key press - g-p-m sees second down key press, sets to level 5, hardware emits synthesised 'down' key press' At this point there are outstanding key presses (an up and a down), when g-p-m gets them, it updates the brightness, and causes new synthesised key presses, so it gets into a feedback loop. The solution for my laptop is to have g-p-m not update the brightness itself, but just get the value from the hardware.
Created attachment 64590 [details] [review] example patch This will get things working, but is obvioulsy non ideal. We need a HAL property so we can discover this automatically with fdi files. Your suggestion of laptop_panel.brightness_in_hardware seems sane. Richard.
I also confirm a variant of this bug : if i check "dim the backlight when idle" in "general" properties of "power management", waiting a few minutes to make it happen, the backlight of my IBM X31 starts to blink rapidly and never stops, even i hit some keys or move the mouse. Only way to get it back is to hit Fn-End *very* quickly, many times to go to *minimum* brightness, then restore full brightness with Fn-Home (pressed slowly). Trying to *raise* the brightness while blinking is a bad idea, it doesn't solve the problem. Very annoying. Paranoid thoughts make me fear backlight could get out of usage quicker than normal. Workaround : uncheck «dim backlight when idle» in general properties of G-P-M. Workaround to original bug : hit Fn-End / Fn-Home very slowly to not trigger the loop.
Oliver, can you add perhaps to the thread on hal-devel? I can work on such a patch after this weekend, but at the moment I'm on a post-exam enjoying myself-binge. :-) Richard.
Either of you got an "lshal | grep smbios" please?
I have emailed richard my entire lshal output, but for completeness, here is my output from the command above (some details obscured). smbios.chassis.type = 'Notebook' (string) smbios.chassis.manufacturer = 'IBM' (string) smbios.system.uuid = 'X0000X00-0000-0000-00XX-0000XXX00XX' (string) smbios.system.serial = '00XXXXX' (string) smbios.system.version = 'ThinkPad X31' (string) smbios.system.product = '2672C2G' (string) smbios.system.manufacturer = 'IBM' (string) smbios.bios.release_date = '09/22/2005' (string) smbios.bios.version = '1QET97WW (3.02 )' (string) smbios.bios.vendor = 'IBM' (string)
Thanks. In CVS HEAD: 2006-05-14 Richard Hughes <richard@hughsie.com> * src/gpm-brightness.c (gpm_brightness_init): Add support for laptop_panel.brightness_in_hardware if present. We can trivially rename this if the HAL name is to change, but the checks are in place now. This starts to fix #340231. The patch for HAL has been sent to hal@ and is awaiting approval/review. Richard.
Patch has been accepted upstream by HAL. Using hal and gnome-power-manager cvs everything should work great. Thanks. Richard.