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

[David Zeuthen]

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

It's not Linux specific. See also below.

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

Sure. That's fixable.

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

XML is not for human beings. But it has a bunch of other good things
that are not always apparent for some people..

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

Yeah. Because no-one uses HAL _anyway_.

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

Not true; we don't enforce policy at all in HAL but I guess you're
trying hard to make "inject known-good quirks" to be policy.

HAL, which is a really bad name (I blame Havoc), is an easy to use
mechanism to enable high-level clients to discover, configure and
monitor devices attached to the system.

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

If you want to go down that road...

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

If you check the archives of this list.. one of the things Kay and I are
looking at is starting udev and hal in tandem. So in the future that
will no longer apply.

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

Smuggle? The data is not "Linux specific" either because the Linux
keytable is well-known already. As such, this data is useful for other
OS's if they have map from Linux keycodes to their own keycodes (either
at build (via e.g. XSLT) or run time). Linux just happens to be the
prominent free OS around which means that we're using that key table.

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

Other cons:

 - Now we have yet another project collecting hardware quirks and
   configuration data. We need _fewer_ of these, not more. This is
   by far the most important reason for me; we're trying to make
   the Linux/Free software world _less_ fragmented, not more.

 - Have you thought about a future where this data wouldn't be used
   to inject quirks into the kernel but rather used to configure
   how e.g. the X server uses the evdev input device? (e.g. the
   mapping from scan codes happens at a higher level?)

So I think merging Richard's patch is the right approach.

       David