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

Richard Hughes hughsient at gmail.com
Mon Jun 4 10:48:32 PDT 2007


On Mon, 2007-06-04 at 19:26 +0200, Lennart Poettering wrote: 
> 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) } }' < $< > $@

Cool, but:

hal-setup-keymap-hash-name.h:975: error: ‘WWW’ undeclared (first use in
this function)

Because WWW isn't defined, but KEY_WWW is.

> 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.

Ick, that's not going to be popular.

> 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.

Sounds like a plan to me.

> 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. 

Good man.

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

Seems good to me.

Richard.




More information about the hal mailing list