Bug 11102 - no hotkeys if ACPI enabled - Samsung P500
Summary: no hotkeys if ACPI enabled - Samsung P500
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Dmitry Torokhov
URL:
Keywords:
Depends on:
Blocks: 56331
  Show dependency tree
 
Reported: 2008-07-16 12:22 UTC by Paolo Ornati
Modified: 2013-04-09 06:23 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.26
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
acpidump (150.29 KB, text/plain)
2008-07-16 12:23 UTC, Paolo Ornati
Details
dmesg for 2.6.26, minimal config (14.67 KB, text/plain)
2008-07-16 12:24 UTC, Paolo Ornati
Details
acpi-interrups dump (1.51 KB, text/plain)
2008-07-16 12:25 UTC, Paolo Ornati
Details
patch: print out EC query method (516 bytes, patch)
2008-07-18 00:19 UTC, Zhang Rui
Details | Diff
full dmesg with keypress --> EC: query method (23.57 KB, text/plain)
2008-07-18 02:24 UTC, Paolo Ornati
Details

Description Paolo Ornati 2008-07-16 12:22:45 UTC
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...
Comment 1 Paolo Ornati 2008-07-16 12:23:45 UTC
Created attachment 16846 [details]
acpidump
Comment 2 Paolo Ornati 2008-07-16 12:24:34 UTC
Created attachment 16847 [details]
dmesg for 2.6.26, minimal config
Comment 3 Paolo Ornati 2008-07-16 12:25:15 UTC
Created attachment 16848 [details]
acpi-interrups dump
Comment 4 Zhang Rui 2008-07-16 19:28:09 UTC
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.
Comment 5 Paolo Ornati 2008-07-17 23:24:04 UTC
(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.
Comment 6 Zhang Rui 2008-07-18 00:13:52 UTC
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.
Comment 7 Zhang Rui 2008-07-18 00:19:59 UTC
Created attachment 16873 [details]
patch: print out EC query method
Comment 8 Paolo Ornati 2008-07-18 02:22:17 UTC
(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".
Comment 9 Paolo Ornati 2008-07-18 02:24:24 UTC
Created attachment 16874 [details]
full dmesg with keypress --> EC: query method
Comment 10 Paolo Ornati 2008-07-18 23:12:25 UTC
NOTE: I will be (probably) offline for 2 weeks
Comment 11 ykzhao 2008-07-20 20:36:49 UTC
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.
Comment 12 Dmitry Torokhov 2008-07-22 12:31:52 UTC
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.
Comment 13 Dmitry Torokhov 2008-07-22 12:36:56 UTC
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.
Comment 14 Paolo Ornati 2008-08-02 09:50:38 UTC
(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
Comment 15 Paolo Ornati 2008-08-02 09:56:07 UTC
(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.
Comment 16 Paolo Ornati 2008-08-03 00:52:01 UTC
Manually setting keycodes with "setkeycodes" doesn't work too: the keys are not reported as "unknown" but brightness doesn't change.
Comment 17 Len Brown 2008-08-22 11:19:26 UTC
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.
Comment 18 Dmitry Torokhov 2008-08-22 13:30:51 UTC
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.
Comment 19 Paolo Ornati 2008-08-23 01:26:29 UTC
(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...
Comment 20 Paolo Ornati 2008-08-23 01:49:40 UTC
(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 -->
Comment 21 Paolo Ornati 2008-10-13 00:28:46 UTC
-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!

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