[RFC PATCH] Initial libudev input-hotplug support
Alan Coopersmith
Alan.Coopersmith at Sun.COM
Wed Sep 30 17:10:37 PDT 2009
Dan Nicholson wrote:
> On Wed, Sep 30, 2009 at 7:42 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> On Wed, Sep 30, 2009 at 10:17:47AM +0200, Julien Cristau wrote:
>>> On Wed, Sep 30, 2009 at 08:47:27 +0200, Rémi Cardona wrote:
>>>> I think the "xkb" HAL keys were deprecated in favor of
>>>> "x11_options.Xkb*", let's at least drop the deprecated one.
>>>>
>>> Well my understanding was that input.xkb.foo was preferred. There's
>>> nothing strictly x11-specific to the xkb keys (we use the
>>> xkeyboard-config data files to set the console keymap, e.g.).
>> Correct.
>
> One thing I was hoping was not to have the options input from the
> device configuration again. Having people migrate their setups to hal
> was not fun, and now they'll have to do it again to udev rules files.
Having looked at this a bit since the discussions at XDC this week,
it will be a lot easier for me to add a solaris backend to the config
system to use our system device discovery & hotplug API's than to port
libudev to sit on top of them. If configuration is moving to libudev,
I might consider it - but then the libudev maintainers would have to
agree to both making their code cross-platform, and to making some of
their API's a more reasonable OS-agnostic abstraction instead of the
current direct interface to the Linux kernel infrastructure for this,
and thats a lot more work for both them and us.
The win of HAL was that it was really an OS abstraction layer, moving
to libudev means the OS abstraction layer either becomes libudev or
xserver/config/*.c. What I really don't want to see is configuration
options becoming platform specific - "To set 3 button emulation on,
you edit udev rules on Linux, mouse.cf on Solaris, XXXX on NetBSD,
YYYY on FreeBSD, ..."
Or in short, +1 from me for what Dan seems to be proposing.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
More information about the xorg-devel
mailing list