Replacement for hal-setup-keymap

[Martin Pitt]

Hello Kay,

Kay Sievers [2009-05-06  1:16 +0200]:
> > Originally I intended this to become a script which we can run
> > permanently to maintain keymaps in hal-info side by side with the new
> > udev-extras rules. However, udev rules are not expressive enough for
> > some of the weirder constructs we currently have in the hal-info
> > keymaps
> 
> What do we miss here? Usually the fdi files are much more limited than
> the udev matches.

Most are indeed just hard to convert automatically, but
30-keymap-module-sony-laptop.fdi uses a construct which cannot be
mapped 1:1 to udev rules:

       <!-- Older Vaios have a different keymap -->
        <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains_outof="PCG-C1;PCG-K25;[...]">
          <append ...>
          [...]
        </match>

        <!-- now the generic mapping -->
        <match key="input.keymap.data" exists="false">
          <append ...>
        </match>

        <!-- now the common part -->
        <match key="input.keymap.data" exists="true">
          <append ...>
        </match>

I don't want to invest hours in figuring out how to write a program to
convert those into a behavioural equivalent. I'll just make use of the
guaranteed top-down processing order of udev rules, set the generic
and common mapping first, and then conditionally overwrite it with the
mapping for older models.

> >  - Would you prefer using input-utils or a copy of the input-kbd
> >   script in udev-extras?
> 
> I think, we should put all of that, including the binary, in a subdir
> in udev-extras, and install the binary in /lib/udev/. Then we are free
> to change stuff as we need, and don't depend on stuff that might not
> exist on some systems.

*nod*, will do.

> We should just disable the keymaps in the current HAL when you are
> ready.

hal trunk is still officially in feature freeze (0.5.12rc2) for a
0.5.12 final release which might never happen. But anyway, for the
sake of other distros which still need it, I'd vote for just making it
conditional with a configure switch.

> >  - Do you think that in the future these udev rules should be
> >   maintained as they are, or being autogenerated from a more abstract
> >   source format which avoids the udev boilerplate?
> 
> I don't know, it's more your call, what you think is easier to
> maintain. To me, they look trivial enough that we can keep them just
> as they look now.

Ack, especially with manual post-processing and beautification.

> Btw, maybe related to that topic or not, do you know how the
> language keymaps are/should be handled? Is that related to this?
> Shouldn't we have some way of specifying a language per keyboard
> device instead of changing the global console?

Only very roughly, I'm afraid. The VTs use console-setup's loadkeys,
wich sets it globally. However, X.org's -evdev driver properly
understands multiple keyboards and uses the evdev interface to set a
keymap for a particular keyboard, pretty much with the same calls that
we use in hal-setup-keymap now, or with the udev rules from above
(note the "%n" argument which is passed to the callout, which is the
/dev/input/eventX device number).

So with X (which is all we should be concerned about wrt. multiple
keyboard and keyboard hotplugging handling, I think), it uses the very
same mechanism, just of course different keymaps (letters/numbers
instead of Fn keys).

I do have an external keyboard for my laptop, but they aren't exposed
separately in the GNOME control applet. However, I can't say right now
whether that's a limitation in X.org or GNOME.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)