[ltp] Re: Bluetooth button not working after installing Debian 2.6.29 kernel

[Bjørn Mork]

Henrique de Moraes Holschuh <hmh@hmh.eng.br> writes:
> On Fri, 17 Apr 2009, Bjørn Mork wrote:
>> Henrique de Moraes Holschuh <hmh@hmh.eng.br> writes:
>> > Hmm, let me check the latest acpid in Debian...  Hey, it has been upda=
ted,
>> > my info was outdated.  Check acpid -n.  It now listens over netlink.
>> 
>> Thanks for the pointer.  I've now finally looked at it, and using this
>> patch on top of the Debian acpid restores previous functionality for me,
>> using a default Debian linux-image-2.6.29-1-amd64 kernel (version
>> 2.6.29-2):
>> 
>> 
>> --- a/input_layer.c	2009-04-17 15:27:40.000000000 +0200
>> +++ b/input_layer.c	2009-04-17 15:48:45.000000000 +0200
>> @@ -57,7 +57,16 @@
>>  	{{{0,0}, EV_KEY, KEY_SUSPEND, 1}, 
>>   		"button/suspend SUSP 00000080 00000000"},
>>  	{{{0,0}, EV_SW, SW_LID, 1}, "button/lid LID close"},
>> -	{{{0,0}, EV_SW, SW_LID, 0}, "button/lid LID open"}
>> +	{{{0,0}, EV_SW, SW_LID, 0}, "button/lid LID open"},
>> +
>> +	/* Additional Lenovo Thinkpad keys */
>> +	{{{0,0}, EV_KEY, KEY_BATTERY, 1}, "ibm/hotkey HKEY 00000080 00001003"},
>> +	{{{0,0}, EV_KEY, KEY_RADIO, 1}, "ibm/hotkey HKEY 00000080 00001005"},
>> +	{{{0,0}, EV_KEY, KEY_SWITCHVIDEOMODE, 1}, 
>> +	        "ibm/hotkey HKEY 00000080 00001007"},
>> +	{{{0,0}, EV_KEY, KEY_F22, 1}, "ibm/hotkey HKEY 00000080 00001008"},
>> +	{{{0,0}, EV_KEY, KEY_F24, 1}, "ibm/hotkey HKEY 00000080 00001009"},
>> +	{{{0,0}, EV_KEY, KEY_ZOOM, 1}, "ibm/hotkey HKEY 00000080 00001014"},
>>  };
>
> Is thet a table that makes acpid issue input events from acpi events? 

Yes.

> You should never need that, thinkpad-acpi already issues input events,
> at most you need to use a simple HAL .fdi file to set, e.g.,
> KEY_BATTERY on fn+f3.


You can?  Even with keys which are not reported by xev at all?  I find
the hal un(der)-documented magic, while I do have a nicely working setup
based on acpid.  Adding the above will make that continue to work with
CONFIG_ACPI_PROC_EVENT disabled.

It does not prevent someone else from fixing hal.  Or even me, if I'd
only known where to start with the hal magic.  Most of the keys listed
above do show up as unknown keys in xev.  Fn+F5 is the only exception.
But I haven't got the faintest idea how to remap them to something
useful. 

And BTW, mapping to an X key is only half the solution to replace acpid
functionality.  What is the recommended utility for mapping key events
to some script nowadays?  I'm using xbindkeys at the moment to bind keys
like XF86ScreenSaver (which is correctly mapped from Fn+F2 by hal).

> And BTW, KEY_RADIO is to select your AM/FM tuner in a remote control, it =
is
> not related to any sort of data link radios.  There is no generic "data
> radio" input event, only specific ones like KEY_BLUETOOTH, KEY_WIFI, etc.

I am sure you're right.  The data above were based on observed values
from the thinkpad_acpi driver in Debian's 2.6.29 kernel.  When pushing
Fn+F5 I get:


nemi:/tmp# input-events 11
/dev/input/event11
   bustype : BUS_HOST
   vendor  : 0x17aa
   product : 0x5054
   version : 16641
   name    : "ThinkPad Extra Buttons"
   phys    : "thinkpad_acpi/input0"
   bits ev : EV_SYN EV_KEY EV_MSC EV_SW

waiting for events
19:37:46.829015: EV_KEY KEY_RADIO pressed
19:37:46.829037: EV_SYN code=0 value=0
19:37:46.829043: EV_KEY KEY_RADIO released
19:37:46.829050: EV_SYN code=0 value=0
^C
nemi:/tmp# uname -a
Linux nemi 2.6.29-1-amd64 #1 SMP Sat Apr 4 16:54:07 UTC 2009 x86_64 GNU/Linux



>
>> Any reasons why this shouldn't be added to acpid?  Any additional keys
>> which should be included at the same time?
>
> acpid is not going to receive ACPI ibm/hotkey events by default. If it is
> receiving them in your box, that's because you have some legacy support
> active for acpi in Kconfig, and the events are going over procfs.  The
> thinkpad-acpi driver won't issue them over netlink.

Nope, I don't have CONFIG_ACPI_PROC_EVENT:

nemi:/tmp# ls -l /proc/acpi/event
ls: cannot access /proc/acpi/event: No such file or directory


> Those hotkey events are input events, they will be sent to the input layer
> (thinkpad-acpi input device) excusively when the legacy reporting over
> procfs is gone.

Yes, and Debian's acpid is patched to use netlink.  The patch uses the
static table shown above to map input events to "fake" acpi events.

> The proper fix is to teach HAL to do stuff when it receives a certain inp=
ut
> event.  But if you just need to get input events, that's something the
> driver already generates, so you should not need acpid at all, and the
> problem is elsewhere...
>
> The typical problem is that X evdev ignores events above 255, so you need=
 to
> remap the thinkpad-acpi input device (typically using HAL .fdi files) to
> have KEY_* codes that are below 255 only.

Well, I would have done that if I found it easier than patching acpid.
Might be just me, but I don't know where to start with hal.  I have no
problems reading the acpid source.  And extra bonus:  The necessary
scripts handling the acpi events are already there - tested and working.


Bjørn