Latest working kernel version: none that I know (tested with 2.6.18/22/24/26) Distribution: Ubuntu 8.04 - tested with runlevel 1 and vanilla kernel Hardware Environment: Samsung NP-P500Y laptop 00:00.0 Host bridge: ATI Technologies Inc Unknown device 7930 00:01.0 PCI bridge: ATI Technologies Inc Unknown device 7932 00:05.0 PCI bridge: ATI Technologies Inc Unknown device 7935 00:06.0 PCI bridge: ATI Technologies Inc Unknown device 7936 00:07.0 PCI bridge: ATI Technologies Inc Unknown device 7937 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Xpress 1250 02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) 05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8039 PCI-E Fast Ethernet Controller (rev 15) Problem Description: On this laptop some function keys are BIOS-controlled (they work before Linux boots). As soon as Linux boots they stop working. Trying some boot options I've found that "acpi=off" makes them work and the less drastic "acpi=ht" works too. I'm mostly interested in brightness adjusting and since both xbacklight and radeontool fail I've to use "acpi=ht". Not good on a laptop ;) This is what happens when a FN key is pressed: 1) dmesg (immediatley after being pressed and for every FN key tried) [ 1201.791512] atkbd.c: Unknown key pressed (translated set 2, code 0x89 on isa0060/serio0). [ 1201.791521] atkbd.c: Use 'setkeycodes e009 <keycode>' to make it known. 2) grep . /sys/firmware/acpi/interrupts/*: ... almost everything = 0 ... /sys/firmware/acpi/interrupts/gpe03:215 /sys/firmware/acpi/interrupts/gpe1F:3 /sys/firmware/acpi/interrupts/gpe_all:218 /sys/firmware/acpi/interrupts/sci:218 gpe1F stay fixed gpe03,gpe_all,sci change in this way: - brightness UP/DOWN (and other les interesting FNkeys too): they go up by two after 5-6 seconds - backlight on/off: no change at all other uninteresting FN keys (because BIOS does nothing with them anyway): - sleep FN key they go up by 2 immediatley - other misc FN keys behaves like brigthess UP/DOWN I'll attach dmesg, acpidump, and acpi-interrupts...
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!