How to migrate the X server?

[Dan Nicholson]

On Tue, Aug 4, 2009 at 11:42 PM, Peter Hutterer<peter.hutterer at who-t.net> wrote:
> On Fri, Jul 31, 2009 at 06:33:14AM -0700, Dan Nicholson wrote:
>> On Thu, Jul 30, 2009 at 6:49 PM, Peter Hutterer<peter.hutterer at who-t.net> wrote:
>> > On Thu, Jul 30, 2009 at 08:21:52AM -0500, Dan Nicholson wrote:
>> >> On Wed, Jul 29, 2009 at 11:13 PM, Peter
>> >> Hutterer<peter.hutterer at who-t.net> wrote:
>> >> > I have poked at libudev a bit today in a weak effort to look what's required
>> >> > to switch the X server over. I'd be happy if someone else takes over at
>> >> > this, but right now I don't see this happening for 1.7 anyway. Especially
>> >> > since the udev code I just wrote required me to put a big "i know this API
>> >> > will change" define in.
>> >>
>> >> Peter,
>> >>
>> >> I've been working on some patches to add an InputClass configuration
>> >> in the anticipation that when udev hotplugging shows up to the server
>> >> so we don't have to attempt to migrate people to a udev configuration.
>> >> Would you consider having a look at the patches before we add yet
>> >> another input device configuration system?
>> >
>> > sure, just send them my way. Are we talking about similar patches you did
>> > ages ago to get xorg.conf and HAL together?
>>
>> Yes, but improved (IMO). I'm still not sure you'll like them, but this
>> adds an InputClass section where you can match on properties of the
>> device to apply settings. Basically, I think hal and udev should be
>> used for device notification and get out of the business of being our
>> configuration stores.
>>
>> Have a look at these two patches. There are some of improvements I
>> have in mind, but this is the gist of it. Also, I just rebased them to
>> master, so I'm not sure they even build.
>>
>> Let me know what you think.
>
> First of all, a disclaimer: I haven't tested them and didn't look at the
> code, only the documentation. The basic approach is good, essentially
> duplicating the <match key contains> approach of fdis.
>
> The main issue I see is with the integration of distribution-shipped code
> and user-configured code. With the current system, we have /usr/share/hal/*
> for distro-code and /etc/hal/* for user-configured code.
> This is quite convenient as we can update device blacklists and other
> configurations while still maintaining user-specific configurations.
> Anything in the xorg.conf doesn't allow this, at least not easily.
>
> The other issue I can see with the this approach is the lack of information
> about the device that is outside of the scope of path and device names. For
> example, the input.touchpad capability was assigned based on what the device
> itself was able to do (BTN_TOUCH, amongst other things).
> This allowed for new devices to be supported automatically, without adding
> extra match rules.
>
> I don't see any way to do this in the InputClass approach, at least not
> without an external program or integrating these bits into the server
> itself. Personally I think this feature is even more important than the
> patch matching.
>
> Do you have any ideas on how to address these issues?

Here are some thoughts I've had that I planned to code up, but need to
get some time.

1. Read /etc/X11/xorg.conf.d/* in addition to /etc/X11/xorg.conf.
Then, for example, you could drop in a default InputClass
configuration with the synaptics package in
/etc/X11/xorg.conf.d/50-synaptics.conf. I haven't really had a look at
the code, but I have an idea how it would work and how I think the
different cases would go. This, obviously, could be a controversial
change.

2. Add an Ignore token to the InputClass configuration such that you
can ignore input devices in the same manner as removing the hal
x11_driver key. Just gives a little more flexibility on "I want
hotplugging, but not _these_ devices".

3. Add more property matches to InputClass like HasKeys, HasPointer,
etc. I'm not too sure the best approach on this one, but for hal it
would simply walk the input.capabilities strlist. For udev, you'd
probably have to recreate what hal's input prober does or use udev
rules to setup the properties.

4. Strictly code movement, but have the config backend pass a
InputProperties struct in NewInputDeviceRequest so xf86Xinput doesn't
have to try to figure these things out from the InputOptions.

>> Basically, I think hal and udev should be used for device notification and
>> get out of the business of being our configuration stores.
>
> IMO there is nothing wrong with hal/udev being configuration _stores_. The
> bad thing is that they are also the configurators, i.e. that the
> configuration became part of HAL rather than the X package.
>
> However, right now I can only think of another process being the
> configuration store, adding the properties to udev for the server to pick it
> up (which, incidentally, would be quite similar to the original hotplug
> support (daniel's "respeclaration" tool)).
> my gut tells me that this isn't a good solution either though.

That thought has popped into my mind a couple times. For storage
devices, the user session says when and how to mount a removable
device. It could be nice to do this with input devices, but that's a
lot of code in different areas where I'm not sure how it'd work
relative to the current setup.

--
Dan