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

[Bjørn Mork]

gregor herrmann <gregor+usenet-0601@comodo.priv.at> writes:
> On Sat, 18 Apr 2009 13:20:48 +0200, Bjørn Mork wrote:
>
>> 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?
>
> If I understand you correctly: Yes, $hal_key is the KEY_FOO name from
> input.h withouth KEY_ and lower-cased.

Thanks.  I found it in the hal sources too when I just knew what to
look for.  The following Makefile.am snippet shows how the lookup_key
function is built (@LINUX_INPUT_H@ is typically /usr/include/linux/input.h):

if HAVE_GPERF
hal-setup-keymap-keys.txt: @LINUX_INPUT_H@
        awk '/^#define.*KEY_/ { if ($$2 != "KEY_MAX") { print substr($$2, 5) } }' < $< > $@

hal-setup-keymap-hash-name.gperf: hal-setup-keymap-keys.txt
        awk 'BEGIN{ print "struct key { const char* name; unsigned short id; };"; print "%null-strings"; print "%%";} { print $$1 ", KEY_" $$1 }' < $< > $@

hal-setup-keymap-hash-name.h: hal-setup-keymap-hash-name.gperf
        gperf -t --ignore-case -N lookup_key -H hash_input_names -p -C < $< > $@
endif #HAVE_GPERF



Any ideas on the reasoning behind this?  It seems like completely
unnecessary obfuscation to me.


Bjørn