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

[Richard Hughes]

On Mon, 2007-06-04 at 16:33 +0200, Lennart Poettering wrote:
> On Mon, 04.06.07 14:24, Richard Hughes (hughsient at gmail.com) wrote:
> No need to include "kd.h" if you use the linux input API.

> > +	kb.keycode = keycode;
> > +	kb.scancode = scancode;
> 
> Uh!
> 
> You have to pass an int[2] here, not a struct kbkeycode.

I'll take your word for this, as the original setkeycode used kbkeycode.

> > +	/* add each of the keys */
> > +	do {
> > +		values = sscanf (keymap_list[i], "%x:%i", &scancode, &keycode);
> > +		if (values == 2) {
> > +			printf ("hal-setup-keymap: Parsed %s to (%x, %i)", keymap_list[i], scancode, keycode);
> > +			evdev_set_keycode (fd, scancode, keycode);
> > +		} else {
> > +			printf ("hal-setup-keymap: Failed to parse %s", keymap_list[i]);
> > +		}
> > +	} while (keymap_list[i++] != NULL);
> 
> Please do not use the numeric Linux keycodes directly for
> this. Firstly, this is not portable. Secondly, this is not extensible,
> since the Linux keycode space is mostly depleted already. Use the
> names instead. Eventually the kernel guys might come up with a
> completely new mapping thing again, to extend the code space.
> 
> In keyfuzz I use these Makefile lines for generating a static gperf hashtable
> for translating these keycodes:

Sure, sounds sane.

> http://0pointer.de/cgi-bin/viewcvs.cgi/trunk/src/Makefile.am?rev=19&root=keyfuzz&view=auto
> 
> You can probably omit the keys-to-name part, as you only want to
> translate keycodes to names and not vice versa.

Clever stuff indeed.

> > +    <!-- These are raw scancodes produced by the keyboard driver -->
> > +    <match key="info.product" string="AT Translated Set 2 keyboard">
> > +
> > +      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" prefix="LENOVO">
> > +        <match key="/org/freedesktop/Hal/devices/computer:smbios.system.version" contains="3000">
> 
> There seems to be an implicit guarantee that atkb shows up in the HAL
> device tree after DMI. Is that really guaranteed in all cases?

No, and this is causing other bugs with the backlight quirks; there is a
serious bug in this respect when we are using device:foo.bar matching.

> One question here: Why don't the thinkpad kernel drivers contain the proper
> mappings anyway? Why is there the need for additional remapping from userspace?

As they give out the same scancode for lots of different models, and the
consensus on LKML was that dmi mapping should not be done in
kernel-space.

New patches attached, please review. Thanks everybody so far.

Richard.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hal-keymap.patch
Type: text/x-patch
Size: 10400 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20070604/33e2232d/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hal-info-keymap.patch
Type: text/x-patch
Size: 2970 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20070604/33e2232d/attachment-0003.bin