Created attachment 41372 [details] working rc3 kernel, /proc/modules New here, thank you for your patience. The laptop is a Fujitsu-Siemens Esprimo Mobile U9200, while setting the backlight through software (sysfs, KDE's powerdevil) works fine, the brightness hotkeys don't behave as they should - intead of increasing/decreasing the brightness level by 1 step, down decreases the rightness by 2 steps, while up momentarily increases the brightnes (presumably by 2 steps), then immediately reverts to previous value, making it nigh impossible to increase brightness with keyboard. (Side note: kernel from previous ubuntu installation behaved similarly wrt. 2-step increments, but I at least managed to increase brightness by holding the up key down.) The keys behave(d) normally 1) during POST and GRUB (and in Windows) 2) in 'buntu 8.04 - kernel 2.6.24 3) in mainline kernel version 2.6.35-rc3 provided by Ubuntu here> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc3-maverick/ I reported the bug against ubuntu kernel here> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/629358 the mainline kernel behaves the same way but tell me if you need more/stable mainline kernel's output. The important part of that report is probably that in the working rc3 (mainline), showkey -s reported nothing on pressing the keys, while a quick keypress produces 4 codes from the down key and 8 codes from the up key both in ubuntu kernel and in mainline stable: # single brightness-down 0xe0 0x4c 0xe0 0xcc #single brighness-up 0xe0 0x54 0xe0 0xd4 0xe0 0x4c 0xe0 0xcc
Created attachment 41382 [details] rc3 kernel, acpidump output
Created attachment 41392 [details] rc3 kernel, dmesg
Created attachment 41402 [details] Ubuntu's then-current kernel 2.6.35-19 Ubuntu's then-current kernel behaves same way as then-current and now-current mainline
are you still using ubuntu 8.04 now?
Not anymore, sorry. I have 9.10 and 10.10 installed. Booting into 8.04 live session is not a problem as long as I only need to boot the stock kernel.
(In reply to comment #0) > (Side note: kernel from previous ubuntu installation behaved > similarly wrt. 2-step increments, but I at least managed to increase > brightness > by holding the up key down.) > in this case, brightness hotkeys works in the same way as described in bug #19592, right?
(In reply to comment #6) > in this case, brightness hotkeys works in the same way as described in bug > #19592, right? Yes and no - down always worked in 2-step increments but up was simply unpredictable - sometimes it went up 2 steps and stayed there, sometimes it went up 2 steps briefly and went back to the level it was before the keypress. Now, I have two pieces of new info. Few days ago I stayed a while longer in the rc3 kernel (I rebooted after 2 days - probably 2 suspend-resume cycles and quite a few mode-switches LVDS<->VGA later) and when I was about to reboot I noticed the hotkeys were broken here too! Can the relevant info be found in dmesg output? If so, I'll see if I can reproduce the situation. Second, the /sys/module/video/parameters/brightness_switch_enabled is set to Y in current Ubuntu kernel. Setting it to N fixes pretty much everything - hotkeys increment and decrement properly, powerdevil detects the keypresses and shows the brightness level as it's increased/decreased correctly, showkey -s detects 4 characters on quick keypress for both keys, and brightness is adjusted in tty as well as in X. Down: 0xe0 0x4c 0xe0 0xcc Up: 0xe0 0x54 0xe0 0xd4 I'm not sure I understand from #19592's comments how this is intended to work - is this merely this laptop missing from/being in some white/blacklist incorrectly, or is this an ACPI bug or intel-driver bug?
Just trying out the brightness_switch_enabled in rc3; it makes no difference whatsoever - in either setting, hotkeys change the brightness correctly (X and tty) and there's no response shown in showkey -s output.
(In reply to comment #7) > (In reply to comment #6) > > in this case, brightness hotkeys works in the same way as described in bug > > #19592, right? > > Yes and no - down always worked in 2-step increments but up was simply > unpredictable - sometimes it went up 2 steps and stayed there, sometimes it > went up 2 steps briefly and went back to the level it was before the > keypress. > > Now, I have two pieces of new info. Few days ago I stayed a while longer in > the > rc3 kernel (I rebooted after 2 days - probably 2 suspend-resume cycles and > quite a few mode-switches LVDS<->VGA later) and when I was about to reboot I > noticed the hotkeys were broken here too! Can the relevant info be found in > dmesg output? If so, I'll see if I can reproduce the situation. No, at least I didn't find anything interesting in the dmesg attached in comment #2. > Second, the /sys/module/video/parameters/brightness_switch_enabled is set to > Y > in current Ubuntu kernel. Setting it to N fixes pretty much everything - > hotkeys increment and decrement properly, powerdevil detects the keypresses > and > shows the brightness level as it's increased/decreased correctly, showkey -s > detects 4 characters on quick keypress for both keys, and brightness is > adjusted in tty as well as in X. > so it seems that everything works well if brightness_switch_enabled=N, right? But I'm wondering why it affects the input event generated.
(In reply to comment #9) > > Second, the /sys/module/video/parameters/brightness_switch_enabled is set > to Y > > in current Ubuntu kernel. Setting it to N fixes pretty much everything - > > hotkeys increment and decrement properly, powerdevil detects the keypresses > and > > shows the brightness level as it's increased/decreased correctly, showkey > -s > > detects 4 characters on quick keypress for both keys, and brightness is > > adjusted in tty as well as in X. > > > so it seems that everything works well if brightness_switch_enabled=N, right? Correct. Is this normal and the laptop simply needs to be put into some white-/black-list to work OotB or is this a bug and the correct behavior should not depend on the switch_enabled parameter? > But I'm wondering why it affects the input event generated.
*** This bug has been marked as a duplicate of bug 19592 ***