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

[Richard Hughes]

On Mon, 2007-05-07 at 12:21 -0400, David Zeuthen wrote:
> 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.

How do we know which input device is the hardware keyboard - is it
always event1?

I guess it might even be better to match against the keyboard device -
rather than the computer device, something like:

    <match key="info.category" string="input">
      <match key="info.product" string="AT Translated Set 2 keyboard">
        <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" string="LENOVO">
          <match key="/org/freedesktop/Hal/devices/computer:smbios.system.version" contains="3000">
            <append key="keymap.linux.data" type="strlist">e016:238</append>	<!-- Fn+F5	Wireless -->
            <append key="keymap.linux.data" type="strlist">e017:142</append>	<!-- Fn+F4	Suspend -->
            <append key="keymap.linux.data" type="strlist">e018:205</append>	<!-- Fn+F12	Hibernate -->
          </match>
        </match>
      </match>
    </match>

Which means we don't have to play games with the console and looking for
input devices. I'm also fairly sure you can't do this sort of thing
easily as a udev rule FWIW.

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

Heh, HAL is even in the GMAE stack...

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

That's not policy, that's getting things working like they should. If I
have a suspend button on my keyboard then it can only do one thing -
suspend.

> HAL... is an easy to use mechanism to enable high-level clients to
> discover, configure and monitor devices attached to the system.

Dude, that should be on the wiki in big letters.

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

Sure, I would be happy to add freebsd or solaris data and support into
the callout if they tell me what ioctl or whatever those guys use.

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

Yes, agree 4000% about this one. That's a passionate 4000% as well.

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

Cool. What do you think about matching to /dev/input/event1 AND dmi
data, and then using that directly in the addon? Seems most clean to me,
and also allows us to treat two keyboards differently.

Do you want me to merge the patch and we can work from head, or wait
until we have discussed this some more? Thanks.

Richard.