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

[Lennart Poettering]

On Fri, 04.05.07 17:48, Bastien Nocera (hadess at hadess.net) wrote:

> > What about the following:
> > http://live.gnome.org/GnomePowerManager/AddingKeymapData
> > 
> > i.e. not something a newbie could do, but someone who is half competent
> > and knows what a terminal is should be able to cope.
> > 
> > If it's crack, tell me so. :-)
> 
> Lennart just told me he wrote a kernel module to export DMI information
> in modalias, so that driver that we could potentially load driver, and
> keytables from udev rules, rather than from HAL.
> 
> It would also allow to load drivers such as ibm-laptop, sonypi, dcbdas
> (or whatever that Dell module is called) automatically, without hacks in
> startup scripts.
> 
> Did I explain that right Lennart?

Yes, you did.

Here are my five euro cent on this issue:

First, I would like to point out a few problems I see with Richard's
patch:

- Moves Linux-specific stuff into HAL, by using the Linux keycode ids for
  the patch files

- Uses KDSETKEYCODE/setkeycodes on the console which is evil. Should
  be using EVIOCSKEYCODE on the input device.

- Humm, coding scan code tables in XML doesn't seem that much fun to me.

- Doing this stuf in HAL adds a big, big dependency tree to something
  that is very simple task.

- Honestly, I am not sure what the definition of HAL as it is right
  now should be. Something that informs clients about changes in the
  device tree and offers some basic functionality. Or some generic
  configuration thing, that will do all kinds of configuration for
  you, even if you don't want it?

What is good: 

- Since HAL abstracts the product ids (DMI, PMU, ...) it
  works on both macs and x86.

- The code is already available.

Now, this is what I am proposing:

Use my new dmi-id.c kernel module, which will hopefully be merged into
the kernel soonishly. That module exports a few DMI fields via sysfs:

</snip>
/sys/class/dmi/id
|-- bios_date
|-- bios_vendor
|-- bios_version
|-- chassis_serial
|-- chassis_vendor
|-- chassis_version
|-- modalias
|-- product_name
|-- product_serial
|-- product_version
|-- subsystem -> ../../../class/dmi
|-- sys_vendor
`-- uevent
</snip>

(My laptop doesn't have a DMI "mainboard" block. On systems which have
that the list is longer)

The contents of that is (on my machine):

<snip>
bios_date = 09/26/2005
bios_vendor = American Megatrends Inc.
bios_version = A1013AM7 V3.70
chassis_serial = To Be Filled By O.E.M.
chassis_vendor = MICRO-STAR INT'L CO.,LTD
chassis_version = 
modalias =
dmi:bvnAmericanMegatrendsInc.:bvrA1013AM7V3.70:bd09/26/2005:svnNOTEBOOK:pnSAM2000:pvr0131:cvnMICRO-STARINT'LCO.,LTD:cvr:
product_name = SAM2000
product_serial = FFFFFFFF
product_version = 0131
sys_vendor = NOTEBOOK
</snip>

An udev rule would then as soon as either this device -- or the atkbd
input device -- show up the device tree load a the keytable using the
tool "keyfuzz" i wrote a while ago, which is basically just some
wrapper around EVIOCSKEYCODE, and currently not much used, except on
my laptops.

keyfuzz is ready. dmi-id.c is almost ready for posting it for kernel
inclusion. The last missing bit is a handful of udev rules for
running keyfuzz based on the proper DMI info. (probably most of that
info can be acquired from the ubuntu package). Probably we don't need
too many rules, since vendors usually use the same set of keycodes for
all their models.

The key database would be shipped as part of the keyfuzz
package. Also, keyfuzz will include the udev rules.

Pros:

- Doesn't need any dependencies besides udev and a kernel wth
  dmi-id.c. HAL haters will definitely like that.

- I might say it is much, much simpler. No XML, No HAL involved. Much
  Unixisher -- just gluing a few small parts together to build a grand
  solution.

- Can be run very early on boot. Which is quite nice -- at least on my laptop,
  because it generates all kinds of fake keypresses for all kinds of
  ACPI EC events which causes dmesg to fill up very early during boot.

Cons:

- Works on Linux only --- So what? At least it doesn't smuggle 
  some Linux specific stuff into HAL FDIs.

- Works exclusively with DMI right now.

- Getting dmi-id.c into the kernel will take a while, due to their
  relatively long release cycles. (Though the HAL release cycle didn't
  appear to be that short either)

I'd love to hear some feedback from the Ubuntu "hotkey-setup" guys on
this. i.e. Matthew Garret, Scott James Remnant, Paul Sladen. I'll ping
them.

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/