Bug 25482 - Backlight hotkeys behave erratically on FSC Esprimo Mobile U9200
Backlight hotkeys behave erratically on FSC Esprimo Mobile U9200
Status: CLOSED DUPLICATE of bug 19592
Product: ACPI
Classification: Unclassified
Component: Power-Video
All Linux
: P1 normal
Assigned To: acpi_power-video
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-22 18:48 UTC by Michal Zatloukal
Modified: 2011-03-03 01:05 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.35
Tree: Mainline
Regression: Yes


Attachments
working rc3 kernel, /proc/modules (2.59 KB, application/octet-stream)
2010-12-22 18:48 UTC, Michal Zatloukal
Details
rc3 kernel, acpidump output (137.50 KB, application/octet-stream)
2010-12-22 18:50 UTC, Michal Zatloukal
Details
rc3 kernel, dmesg (89.84 KB, text/plain)
2010-12-22 18:51 UTC, Michal Zatloukal
Details
Ubuntu's then-current kernel 2.6.35-19 (53.96 KB, application/octet-stream)
2010-12-22 18:53 UTC, Michal Zatloukal
Details

Description Michal Zatloukal 2010-12-22 18:48:35 UTC
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
Comment 1 Michal Zatloukal 2010-12-22 18:50:17 UTC
Created attachment 41382 [details]
rc3 kernel, acpidump output
Comment 2 Michal Zatloukal 2010-12-22 18:51:18 UTC
Created attachment 41392 [details]
rc3 kernel, dmesg
Comment 3 Michal Zatloukal 2010-12-22 18:53:44 UTC
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
Comment 4 Zhang Rui 2010-12-27 05:59:58 UTC
are you still using ubuntu 8.04 now?
Comment 5 Michal Zatloukal 2010-12-27 06:16:22 UTC
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.
Comment 6 Zhang Rui 2010-12-27 06:39:00 UTC
(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?
Comment 7 Michal Zatloukal 2010-12-27 08:11:55 UTC
(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?
Comment 8 Michal Zatloukal 2010-12-27 19:49:32 UTC
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.
Comment 9 Zhang Rui 2010-12-28 01:17:58 UTC

(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.
Comment 10 Michal Zatloukal 2010-12-28 13:46:04 UTC
(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.
Comment 11 Zhang Rui 2010-12-30 05:37:11 UTC

*** This bug has been marked as a duplicate of bug 19592 ***

Note You need to log in before you can comment on or make changes to this bug.