Using HAL for X Server Config Properties?

[David Zeuthen]

On Fri, 2005-10-07 at 14:38 -0400, Jim Gettys wrote:
> There are a number of things going on here:
> 
> 1) I think we are mostly agreed on probably using dbus to talk to the X
> server to control configuration.  There isn't any particular Linux
> dependency to dbus that I can see.
> 
> And configuration can get complicated, with many different input devices
> and potentially more than one seat on a system.
> 
> 2) Where to store configuration information: I think we mostly agree
> that having this stored in some mystic X configuration file is a
> mistake: the current situation is pretty broken.  We can argue about
> whether this should get stored in a desktop specific configuration
> system, something unique to X, or some yet-to-be-agreed on common
> desktop configuration storage system.  But this is a separate issue, and
> one for the desktop systems themselves to worry about (though so far, no
> one seems to have successfully cracked this nut).

Yes. Please leave usage of the configuration API to the GNOME and KDE
projects of the world. They will then give you feedback too which may be
interesting because they come from a different part of the ecosystem :-)

> 3) There is *a lot* of hardware related stuff involved in X.  We have
> many different classes of input devices (mice, touchscreens, tablets,
> joysticks, data gloves, etc.; last I looked, XInput had a dozen classes
> or so, and people have been inventing new ones since it was defined),
> which may require the startup of device drivers, loading of firmware,
> restoration of calibration information after reboot, and possibly server
> processes to handle remote input devices.  Ideally, a new device of a
> manufacturer can get added without having to touch the X server (or wait
> until a distro gets around to adding configuration GUI's for it).
> 
> Similarly, we have the advent of hotplug screens (e.g. PCIE), though
> these have been around a while on cardbus and pcmcia.  Again, screens
> should plug in and "just work".  I certainly agree with the sentiment
> I've heard that plugging in a new screen, whether hot plug or not,
> should result in a "working" configuration that uses that screen.  We
> can argue about exactly what the default behavior should be.
> 

Yes - sorting out this mess and providing a nice API that abstracts the
hardware is exactly what the IPC interface based on e.g. D-BUS should
provide. 

> I'm less familiar with HAL than D-BUS...  but certainly the above sounds
> a lot like HAL's wiki page or Havoc's manifesto.  But I have no clue if
> other platforms have been interested in picking up HAL: X serves many
> different platforms, not just Linux.

I've argued that there is no need whatsoever to include HAL into this
equation. And I say this as the HAL maintainer.

On IPC: D-BUS is inherently crossplatform, heck it's "only" IPC but it
does this very well: extensive test suite, written with security in
mind, no controversial deps, etc etc etc. See mails from Havoc on the
dbus at freedesktop.org mailing list for details. 

Btw, to me, whether D-BUS, home-made stuff on a Unix socket, XML-RPC or
whatever else IPC system is used is merely an implementation detail. But
I think D-BUS ought to be considered here.

> 4) Hotplug itself seems to vary between platforms; and I'm unaware of
> how it works elsewhere at all (e.g. Mac OSX, Windows, *BSD).  Can people
> enlighten us?

Not really sure why you need to consider hotplug at this early point.
Really. As I see it this is just transforming the the configuration of
the X server from reading a configuration file to providing an API
whereby another process can do it. 

Specifically you can write a parser for the /etc/X11/xorg.conf file that
invokes this API and all is good. Only later I would consider hotplug.

Cheers,
David