Using HAL for X Server Config Properties?

David Zeuthen david at fubar.dk
Fri Oct 7 07:56:17 PDT 2005


Hi,

I'm not sure it's really a good idea to involve HAL in the X.org server
configuration process. I remember talking to krh and ajax about X and
dynamic reconfiguration at the DDC a few months ago. The thinking was
somewhat like this

 1. The X server starts up without configuring any hardware. It listens
    on an IPC interface that is not the X protocol (it makes sense to
    use a secure system message bus here, e.g. D-BUS) [1]

 2. When your display manager (e.g. gdm) and desktop session (e.g.
    GNOME) starts it looks for X servers that are not yet configured

 3. A suitable unconfigured X server is configured. The settings (e.g.
    resolution, color depth, multiple monitors etc.) is read from the
    users settings (e.g. gconf). After a while the desktop session
    can connect to the X server through the X protocol

 4. For on-the-fly reconfiguration the desktop session can connect
    to the IPC D-BUS interface and reconfigure the X server.

The key point here is this: it is paramount that the X server doesn't
read a system-wide configuration file. Actually, the departure from
using a configuration file and instead provide an API that enables some
program running in the desktop session to configure the X server
provides this. This program might even fall back and try other options.

So, I think this is the ideal way to go about it. I don't think we want
to include the HAL project in this :-)

Cheers,
David

[1] : this interface would offer this like fingGraphicsCards(),
findMonitorsByGraphicsCard() etc. though probably slightly more complex
(also include input devices etc.)


On Thu, 2005-10-06 at 10:48 -0700, Johnson, Charles F wrote:
> Actually the X Server has to have quite a bit of knowledge of the
> underlying hardware, particularlly on the display side if you  want to
> take advantage of such things as HW Accelerated 3D.  The question of
> multiple X servers is an interesting aspect that I hadn't considered.  
> 
> One question however, why would adding a x11 properly any different that
> what has already been done in HAL for ALSA ??  
> 
> My real goal here is to investigate what should tbe the proper approach
> so that the X server can make use of the hot plug infrastructure of the
> underlying Linux system so that we can move away from manually
> re-configuring the X server every time a hardware change is made.    
> 
> I've CC'd this onto the xorg mailing list also.
> 
> Thanks.
> 
> --Charles Johnson
> Intel Corp.
> charles.f.johnson at intel.com
> 
> >-----Original Message-----
> >From: Pierre Ossman [mailto:drzeus-list at drzeus.cx]
> >Sent: Thursday, October 06, 2005 6:47 AM
> >To: Richard Hughes
> >Cc: Johnson, Charles F; hal at lists.freedesktop.org
> >Subject: Re: Using HAL for X Server Config Properties?
> >
> >Richard Hughes wrote:
> >>> A paritial example could be:
> >>>
> >>> x11.type = 'pointer'
> >>> x11.driver = 'mouse'
> >>> x11.protocol='IMPS/2'
> >>> x11.pointer.emulate3buttons='yes'
> >>
> >> IMO, makes sense. You could use a prober to populate this.
> >>
> >
> >Is leaking information from the X server into hal such a good idea? An
> X
> >server does not have very strong ties to hardware and we could in fact
> >be running several X servers.
> >
> >If this is pursued it should probably manifest itself as subnodes of
> the
> >hardware, one for each X server.
> >
> >Also, if you're a bit paranoid you probably don't want user specific
> >information, like X server configurations, leaking into what is
> >essentially a system specific database. ;)
> >
> >Rgds
> >Pierre
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal



More information about the hal mailing list