Bug 11102
Summary: | no hotkeys if ACPI enabled - Samsung P500 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Paolo Ornati (ornati) |
Component: | Input Devices | Assignee: | Dmitry Torokhov (dmitry.torokhov) |
Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | acpi-bugzilla, dmitry.torokhov, marek |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.26 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 56331 | ||
Attachments: |
acpidump
dmesg for 2.6.26, minimal config acpi-interrups dump patch: print out EC query method full dmesg with keypress --> EC: query method |
Description
Paolo Ornati
2008-07-16 12:22:45 UTC
Created attachment 16846 [details]
acpidump
Created attachment 16847 [details]
dmesg for 2.6.26, minimal config
Created attachment 16848 [details]
acpi-interrups dump
please kill acpid, run "cat /proc/acpi/event" and attach the output after pressing the hotkeys. Please apply the patch at http://bugzilla.kernel.org/show_bug.cgi?id=10206#c13, then check if it's still empty under /sys/class/backlight. If no, please poke these I/F and see if they work for you. (In reply to comment #4) > please kill acpid, run "cat /proc/acpi/event" and attach the output after > pressing the hotkeys. No output is generated for brightness hotkeys (other hotkeys work, like the "sleep" one) > > Please apply the patch at > http://bugzilla.kernel.org/show_bug.cgi?id=10206#c13, > then check if it's still empty under /sys/class/backlight. > If no, please poke these I/F and see if they work for you. > With the patch I get "acpi_vide0 andacpi_video1". I can change the brightness echoing in the "brightness" virtual file :D. Both video_0 and video_1 control the same (and only ;) backlight. Good news. Now we know that the ACPI backlight control methods work for you. If acpi video driver can get the ACPI events when pressing the brightness up/down hotkey, it should poke the backlight control methods. Please applied the following debug patch and send the dmesg output after pressing hotkeys for several times. Created attachment 16873 [details]
patch: print out EC query method
(In reply to comment #6) > > Please applied the following debug patch and send the dmesg output after > pressing hotkeys for several times. > UP [ 102.624717] atkbd.c: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0). [ 102.624723] atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known. [ 107.843175] EC: query method _Q72 DOWN [ 111.159546] atkbd.c: Unknown key pressed (translated set 2, code 0x89 on isa0060/serio0). [ 111.159551] atkbd.c: Use 'setkeycodes e009 <keycode>' to make it known. [ 117.058938] EC: query method _Q72 ON/OFF [ 120.334356] atkbd.c: Unknown key pressed (translated set 2, code 0x84 on isa0060/serio0). [ 120.334362] atkbd.c: Use 'setkeycodes e004 <keycode>' to make it known. [ 134.980018] EC: query method _Q66 There is always this strange delay between keypress and "EC: qurey". Created attachment 16874 [details]
full dmesg with keypress --> EC: query method
NOTE: I will be (probably) offline for 2 weeks Hi, Paolo
Thanks for the info.
It seems that the keybord interrupt(IRQ 1) is also triggered while the EC triggeres the ACPI interrupt(IRQ 9). In such case the unknown keyboard scan code is gotten. So Linux will complain the following warning message:
>atkbd.c: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
>[ 41.881732] atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known.
>[ 42.142836] atkbd.c: Unknown key pressed (translated set 2, code 0x88 on
>isa0060/serio0).
>[ 42.142840] atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known.
>[ 42.398830] atkbd.c: Unknown key pressed (translated set 2, code 0x88 on
>isa0060/serio0)
Maybe it is related with the BIOS configuration.
Will you please confirm whether the keyboard mode can be changed in BIOS option?
Will you please do the following command and get the serio type?
>cat /sys/devices/platform/i8042/serio0/id/type
Thanks.
Just use setkeycodes to assign proper keycodes (KEY_BRIGHTNESSUP/KEY_BRIGHTNESSDOWN, etc) to the scancodes reported in dmesg. You may want to check/submit quirk to HAL quirk site (http://people.freedesktop.org/~hughsient/quirk/) so that keymap will get adjusted automatically upon boot. Actually I see that it already has Samsung quirk in it: http://gitweb.freedesktop.org/?p=hal-info.git;a=blob;f=fdi/information/10freedesktop/30-keymap-misc.fdi so I guess it is just a matter of updating HAL fdi info on your box. (In reply to comment #11) > Maybe it is related with the BIOS configuration. > Will you please confirm whether the keyboard mode can be changed in BIOS > option? There's no such option. > > Will you please do the following command and get the serio type? > >cat /sys/devices/platform/i8042/serio0/id/type 06 (In reply to comment #13) > Actually I see that it already has Samsung quirk in it: > > > http://gitweb.freedesktop.org/?p=hal-info.git;a=blob;f=fdi/information/10freedesktop/30-keymap-misc.fdi > > so I guess it is just a matter of updating HAL fdi info on your box. > Ahh.. mine version is before this Samsung unification patch. http://gitweb.freedesktop.org/?p=hal-info.git;a=commitdiff;h=f03aa98039195e5e2b6f0c70068af43fd9b5479d For some reason it still doesn't work with patched "fdi", giving "Unknown key pressed"... but this is a configuration/hal issue. Manually setting keycodes with "setkeycodes" doesn't work too: the keys are not reported as "unknown" but brightness doesn't change. The "BIOS" control of the hotkeys is certainly done by SMI/SMM for the benefit of DOS. It is disabled when the OS puts the platform into ACPI mode. When in ACPI mode, the keys cause ACPI events, but you confirmed above that they do not. Alternatively, the could cause regular keyboard events, which you confirmed that they DO. moving this report to the INPUT category. Could you please locate evtest utility and verify that the keycodes reported are correct ones. If the are correct then there is probably an userspace piece missing. (In reply to comment #17) > The "BIOS" control of the hotkeys is certainly done by SMI/SMM > for the benefit of DOS. It is disabled when the OS puts the platform > into ACPI mode. > > When in ACPI mode, the keys cause ACPI events, > but you confirmed above that they do not. > Actually it seems that only the "sleep" function key generate an ACPI event: root@paolo-laptop:~# /etc/init.d/acpid stop * Stopping ACPI services... [ OK ] root@paolo-laptop:~# cat /proc/acpi/event button/sleep SLPB 00000080 00000001 Side note: this Ubuntu 8.04 go to sleep pressing the fn key even with "acpid" stopped... (In reply to commen
t #18)
> Could you please locate evtest utility and verify that the keycodes reported
> are correct ones. If the are correct then there is probably an userspace
> piece
> missing.
>
Ok.
To sum up, most fn keys are working:
- sleep
- show battery status (F2)
- sound mute (F6)
- touchpad on/off (F10)
- numpad on/off (F11)
- volume up/down
...
============================
= evtest /dev/input/event1 =
============================
Volume UP (working)
===========================
Event: time 1219480496.563548, type 4 (?), code 4 (?), value 176
Event: time 1219480496.563557, type 1 (Key), code 115 (VolumeUp), value 0
Event: time 1219480496.563559, type 0 (Reset), code 0 (Reset), value 0
Brightness UP
==============
Event: time 1219480674.389893, type 4 (?), code 4 (?), value 136
Event: time 1219480674.389901, type 1 (Key), code 225 (?), value 2
Event: time 1219480674.389904, type 0 (Reset), code 0 (Reset), value 0
Brightness DOWN
================
Event: time 1219481077.125163, type 4 (?), code 4 (?), value 137
Event: time 1219481077.125173, type 1 (Key), code 224 (?), value 2
Event: time 1219481077.125178, type 0 (Reset), code 0 (Reset), value 0
Backlight on/off
=================
Event: time 1219481151.522231, type 4 (?), code 4 (?), value 132
Event: time 1219481151.522240, type 1 (Key), code 148 (Prog1), value 2
Event: time 1219481151.522242, type 0 (Reset), code 0 (Reset), value 0
This last one is "ok" looking at HAL rules:
... type="strlist">e004:prog1</append> <!-- Fn+F5 backlight on/off -->
-EUSERISSTUPID I was missing "CONFIG_INPUT_EVDEV" in the self compiled kernel... without that HAL cannot write the "fake" ACPI events to "/dev/input/event*" ;) Now it works! |