Using HAL for X Server Config Properties?

Johnson, Charles F charles.f.johnson at
Mon Oct 10 10:55:53 PDT 2005

Maybe I'm being dense, what is the end user benefit of moving the X
Server configuration information from the text file (/etc/X11/xorg.conf)
to where it is managed by some kind of configuration API as refered to
here.  Is this just engineering goodness in that it will make it easier
to support other operating systems, etc ??  Or is these seen as a
necessary infrastructure improvement needed before we can handle Hotplug
and some of these X11 devuce management issues ??  If there is a bigger
picture here, then I want to make sure I'm seeing it.

--Charles Johnson
Intel Corporation
charles.f.johnson at

>-----Original Message-----
>From: xorg-bounces at [mailto:xorg-
>bounces at] On Behalf Of David Zeuthen
>Sent: Friday, October 07, 2005 1:08 PM
>To: jg at; Discuss issues related to the xorg tree
>Cc: Richard Hughes; xorg at; hal at
>Subject: RE: Using HAL for X Server Config Properties?
>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
>> 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
>> 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,
>> one for the desktop systems themselves to worry about (though so far,
>> 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
>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
>> 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
>> processes to handle remote input devices.  Ideally, a new device of a
>> manufacturer can get added without having to touch the X server (or
>> 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
>> I'm less familiar with HAL than D-BUS...  but certainly the above
>> a lot like HAL's wiki page or Havoc's manifesto.  But I have no clue
>> 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 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.
>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
>> 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
>invokes this API and all is good. Only later I would consider hotplug.
>xorg mailing list
>xorg at

More information about the hal mailing list