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

[Lennart Poettering]

On Sun, 06.05.07 14:06, Richard Hughes (hughsient at gmail.com) wrote:

We discussed most of this already on IRC. Hence not much new in this mail.

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

Humm. Prefixing those keys makes the incompatiblity with non-Linux
systems explicit. I doubt that this would be a good idea.

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

Hmm? So?

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

I am not sure if that is a benefit.

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

Yes. It's ok'ed by Kay. And noone on LKML opposed this patch. gregkh
and a few others had a look on it. Hence I assume its in good shape to
be merged. There might even be chance to get into into the current
cycle. We'll see.

Patch is here, BTW: http://lkml.org/lkml/2007/5/8/428

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

Hehe, that's the Linux device model's fault. Blame Kay ;-)

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

No, but it's trivial to do that.

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

Hmm? It's going to be part of Linux proper. Is that upstream enough?

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

I am quite sure that after the initial phase not many updates will be
required for that package. There are not that many laptop manufacturers
around. And they are slowly moving to USB.

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

No. Not ACPI generates them. The EC does. It sends all kinds of
notifications to software as normal keypresses (including power
plug/unplug events and suclike). Windows ignores them. On Linux they
fill up dmesg.

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

I wouldn't call this "breaks things for fbsd and solaris)

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

yes, i had. see above.

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

Paul responded. He prefers the udev method. I asked for permission to
forward his mail to this ML.

Lennart

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