How to migrate the X server?

[Peter Hutterer]

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?

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

Cheers,
  Peter