Replacement for hal-setup-keymap
Kay Sievers
kay.sievers at vrfy.org
Tue May 5 16:16:38 PDT 2009
On Tue, May 5, 2009 at 23:09, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> I now wrote a small hackish script (current version: [1]) which
> convers a set of keymap fdi files into udev rules:
Cool.
> 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.
> So, my questions:
>
> - Does the general structure of the approach and rules look okay?
Looks good.
> - 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.
> - Is everyone okay with doing this as an one-time migration? If so,
> I'll create the lists from our current hal-info data with
> fdi2rules.py and some manual cleanup.
Sounds good to me. We should just disable the keymaps in the current
HAL when you are ready.
> - 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.
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?
Thanks for looking into all this, and taking care of of the remaining
to-convert hal pieces. That's great.
Kay
More information about the devkit-devel
mailing list