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

[Richard Hughes]

On Sat, 2007-05-05 at 02:01 +0200, Lennart Poettering wrote:
> 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:

Sounds good, I'll comment on then also :-)

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

Well, not a problem if we prefix the keys with linux.* or something like
that. Other keys have this if they are Linux specific.

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

Agreed, but HAL might have been started after X has started (in the case
of rhgb).

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

It's only a little more complex than a flat file format, and it has the
benefits of mixing the rules with the data.

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

Agreed. But we are targeting distros rather than embedded guys who want
super small - the super-small embedded guys are just likely to put
static dev in place and then run setkeycodes a few times in an init
script...

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

David's already said (and I think the title in the IRC channel is IIRC):
HAL is a really bad name.

> What is good: 
> 
> - Since HAL abstracts the product ids (DMI, PMU, ...) it
>   works on both macs and x86.
> 
> - The code is already available.

Yes, and could just work without any other extra stuff - see below.

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

To be honest, until the patch is upstream then we have to use something
above udev layer. Is this patch likely to be merged anytime soon?

> </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)

Sure, that looks sane, although DMI doesn't actually sound like a
"class" of devices, more a splattering of dmi data onto sysfs.

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

Is it packaged for Debian and Fedora?

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

Yes, with a few exceptions, although you mentioned we could do quite
sophisticated udev rules if we had to.

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

Have you got an example of what a keyfuzz udev rule would look like?

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

If dmi-id.c isn't very-close to upstream then this is not an option IMO.

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

Sure, but my counter argument to that would be that it's more bits to
update frequently (like hal-info) and that you're putting noarch data
into an arch-specific package. Maybe that can be solved with packaging,
although having two super small packages (keyfuzz and keyfuzz-udev-data)
might be overkill.

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

ACPI produces scancodes at bootup? What do you map the scancodes to?

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

Well, it breaks things for freebsd and solaris (which may have very
different ways to assign scancodes) and also for the embedded people
that still might run static dev. For the case of freebsd we could just
use the IOCTL (or whatever) they use in the callout and then we have a
cross architecture solution.

> - Works exclusively with DMI right now.

Yes, as in we could fix this in a few days and roll out a new HAL
release for post F7 updates. Keys could be added to hal-info as they are
discovered, and hal-info should be updated frequently because of the
other quirk data being updated.

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

That should change, IIUC DavidZ wants to avoid the super-huge releases
timetable like we've had before. Have you also had lkml review for the
new dmi class?

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

Yes, that would be good also; discussion is good.

Richard.