Bug 25482
| Summary: | Backlight hotkeys behave erratically on FSC Esprimo Mobile U9200 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Michal Zatloukal (myxal.mxl) |
| Component: | Power-Video | Assignee: | acpi_power-video |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | acpi-bugzilla, lenb, mjg59-kernel, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.35 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
working rc3 kernel, /proc/modules
rc3 kernel, acpidump output rc3 kernel, dmesg Ubuntu's then-current kernel 2.6.35-19 |
||
|
Description
Michal Zatloukal
2010-12-22 18:48:35 UTC
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 *** |