[patch] add keymap data to make random laptop vendor keys work

[Lennart Poettering]

On Mon, 04.06.07 17:56, Richard Hughes (hughsient at gmail.com) wrote:

> > One last thing: to make this truely portable you might want to drop
> > the ".linux" suffix from "input.keymap.data.linux", and also drop the
> > KEY_ prefix from the keycode names. (yeah, keyfuzz had those in the
> > keycode names, but keyfuzz wasn't about portability, while HAL is.)
> > With these two minor changes the FreeBSD/Solaris people can just add
> > their own addon for parsing this data and can make use of the
> > collected data as well.
> 
> Yes, sounds a very good idea. My awk skillz are lacking - how do I strip
> off the KEY_ prefix? 

Replace this in the Makefile:

awk '/^#define.*KEY_/ { if ($$2 != "KEY_MAX") { print $$2 } }' < $< > $@

With this:

awk '/^#define.*KEY_/ { if ($$2 != "KEY_MAX") { print substr($$2, 5) } }' < $< > $@

BTW: I am not sure if I have read your Makefile that well, but it
appears that now both awk and gperf are deps when building hal. If so,
this has to be checked for in configure.ac.

However, I would recommend to just stick the resulting
keys-from-name.h into the tarball and just keeping these Makefile
rules around for documentedation purposes or to rerun them if input.h
changes upstream. That way, for normal builds neither gperf nor awk
becomes a build-time dep. Yeah, some people say that one should never
put any prebuilt code into the tarball, but don't listen to
them...

> And do we want this ideally lower case or upper
> case?

The gperf table is already built with --ignore-case. Hence both ways
are supported. 

Lowercase symbols are used everywhere else in HAL, hence I guess
lowercase makes a lot of sense here too.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4