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

Bjørn Mork linux-thinkpad@linux-thinkpad.org
Sat, 18 Apr 2009 13:20:48 +0200


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:
>> > 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
>
> Sure.  The reason you don't see them in xev is because X's crappy idea of
> a key event is so limited that evdev discards anything above 255 well
> before it reaches Xev.
>
> The moment you remap all positions to keycodes below 255, they will show
> up in Xev.  Except for brightness up/down and volume up/down/mute, which
> have other stuff behind them (firmware, opregion bios/kernel/x.org
> interface, whatever).

OK, so the missing Fn+F5 is caused by the bogus remapping to KEY_RADIO.  


>> 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.
>
> Hal already HAS .fdi files to do such remappings, just look at
> /usr/share/hal/fdi/./information/10freedesktop/30-keymap-module-thinkpad-=
acpi.fdi,
> modify to taste, and place it wherever in /etc hal wants it to override
> its defaults.

Thanks.  There's the explanation:

bjorn@nemi:~$ cat  /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">
  <device>
    <!-- These are buttons synthesized in the thinkpad-acpi kernel module -->
    <match key="input.product" string="ThinkPad Extra Buttons">
      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" prefix="IBM">
        <append key="input.keymap.data" type="strlist">0x01:battery</append> <!-- Fn+F2 battery -->
        <append key="input.keymap.data" type="strlist">0x02:screenlock</append> <!-- Fn+F3 lock -->
        <append key="input.keymap.data" type="strlist">0x03:sleep</append> <!-- Fn+F4 suspend -->
        <append key="input.keymap.data" type="strlist">0x04:radio</append> <!-- Fn+F5 switch radio -->
        <append key="input.keymap.data" type="strlist">0x06:switchvideomode</append> <!-- Fn+F7 switch video output device -->
        <append key="input.keymap.data" type="strlist">0x07:zoom</append> <!-- Fn+F8 screen expand -->
        <append key="input.keymap.data" type="strlist">0x08:f24</append> <!-- Fn+F9 undock -->
        <append key="input.keymap.data" type="strlist">0x0b:suspend</append> <!-- Fn+F12 hibernate -->
        <append key="input.keymap.data" type="strlist">0x0f:brightnessup</append> <!-- Fn+Home -->
        <append key="input.keymap.data" type="strlist">0x10:brightnessdown</append> <!-- Fn+End -->
        <append key="input.keymap.data" type="strlist">0x11:kbdillumtoggle</append> <!-- Fn+PgUp - ThinkLight -->
        <append key="input.keymap.data" type="strlist">0x13:zoom</append> <!-- Fn+Space -->
        <append key="input.keymap.data" type="strlist">0x14:volumeup</append> <!-- Volume Up button -->
        <append key="input.keymap.data" type="strlist">0x15:volumedown</append> <!-- Volume Down button -->
        <append key="input.keymap.data" type="strlist">0x16:mute</append> <!-- Mute button -->
        <append key="input.keymap.data" type="strlist">0x17:prog1</append> <!-- ThinkPad/ThinkVantage button  (high keycode: "vendor") -->
        <append key="info.capabilities" type="strlist">input.keymap</append>
      </match>
      <!-- Lenovo systems have a similar but different layout to IBM systems -->
      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" prefix="LENOVO">
        <append key="input.keymap.data" type="strlist">0x01:screenlock</append> <!-- Fn+F2 lock -->
        <append key="input.keymap.data" type="strlist">0x02:battery</append> <!-- Fn+F3 battery -->
        <append key="input.keymap.data" type="strlist">0x03:sleep</append> <!-- Fn+F4 suspend -->
        <append key="input.keymap.data" type="strlist">0x04:radio</append> <!-- Fn+F5 wifi -->
        <append key="input.keymap.data" type="strlist">0x06:switchvideomode</append> <!-- Fn+F7 switch video output device -->
        <append key="input.keymap.data" type="strlist">0x07:f22</append> <!-- Fn+F8 touchpadtoggle -->
        <append key="input.keymap.data" type="strlist">0x08:f24</append> <!-- Fn+F9 undock -->
        <append key="input.keymap.data" type="strlist">0x0b:suspend</append> <!-- Fn+F12 hibernate -->
        <append key="input.keymap.data" type="strlist">0x0f:brightnessup</append> <!-- Fn+Home -->
        <append key="input.keymap.data" type="strlist">0x10:brightnessdown</append> <!-- Fn+End -->
        <append key="input.keymap.data" type="strlist">0x11:kbdillumtoggle</append> <!-- Fn+PgUp - ThinkLight -->
        <append key="input.keymap.data" type="strlist">0x13:zoom</append> <!-- Fn+Space -->
        <append key="input.keymap.data" type="strlist">0x14:volumeup</append> <!-- Volume Up button -->
        <append key="input.keymap.data" type="strlist">0x15:volumedown</append> <!-- Volume Down button -->
        <append key="input.keymap.data" type="strlist">0x16:mute</append> <!-- Mute button -->
        <append key="input.keymap.data" type="strlist">0x17:prog1</append> <!-- ThinkPad/ThinkVantage button (high keycode: "vendor") -->
        <append key="info.capabilities" type="strlist">input.keymap</append>
      </match>
    </match>
  </device>
</deviceinfo>



>> 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).
>
> Right now you need something in X, yes.  No, I don't like it.  But I also
> don't have the time to go add functionality to HAL right now.
>
>> 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:
>
> I removed any semblance of KEY_RADIO from thinkpad-acpi a long time ago
> (i.e. before 2.6.23), so something else is crapping that keymap.  Like
> some old stuff in a forgotten HAL config file in /etc somewhere?  New HAL
> packages certainly don't map anything to KEY_RADIO.  Or maybe it is
> hotkey_setup...

It was hal.  Found it thanks to your pointer.  Stupid me thought I could
do a "rgrep KEY_RADIO /usr/shar/hal", but hal do of course have its own
(similar) names for these keys... I'm unable to find the definition of
these key codes anywhere. Can I assume "<input key> = 'KEY_' . uc(<hal key>)"
and look them up in /usr/include/linux/input.h?

Anyway, the bug still seems to be there in newer HAL packages.  At least
in Debian.  The file quoted above is pretty recent:

bjorn@nemi:~$ ls -l /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
-rw-r--r-- 1 root root 4080 2009-03-10 17:32 /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
bjorn@nemi:~$ dpkg -S /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
hal-info: /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
bjorn@nemi:~$ apt-cache policy hal-info
hal-info:
  Installed: 20090309-1
  Candidate: 20090309-1
  Version table:
 *** 20090309-1 0
        600 http://ftp.no.debian.org sid/main Packages
        100 /var/lib/dpkg/status
     20080508+git20080601-1 0
        700 http://ftp.no.debian.org lenny/main Packages



>> > Those hotkey events are input events, they will be sent to the input l=
ayer
>> > (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.
>
> I see.  Well it turns acpid into a input event processor.  A stopgap
> measure at most, acpid is for acpi events, not input events.

Agreed.  But it will keep existing apcid setups working with kernel
images without /proc/acpi/event.  It might therefore be useful during a
transition to Something Else(tm)?


Bjørn