Elektrified X.org released (was: X configuration paradigm, and a proposal)

Erik Harrison erikharrison at gmail.com
Wed Dec 1 04:07:33 EET 2004

On Tue, 30 Nov 2004 13:23:42 -0500, Jim Gettys <jim.gettys at hp.com> wrote:
> David,
> I agree with you and Kristian and I have started work, specifically on
> the input system side to do exactly what you suggest.  Similar
> work ought to be done someday for the screens themselves (hotplug being
> a reality even for screens; today with PCMCIA and PCI express is just
> beginning to ship).
> And yes, everything needs to be dynamic, rather than static, to the
> extent possible.
> However, we'll still probably need some sort of configuration system
> for "non-standard" situations.  It may be something other than the
> current config file will be desirable for this...

While pulling out the config from the server itself, and making the
server respond to events on the fly through that mechanism, still
leaves the design and policy of the config program up in the air.

I always envisioned something like the existing getconfig system,
except not sucking (ie, no Perl needed for what are essentially config

The config client iterates over a few directories containing bits of
config data, which pair settings to pci IDs and event types. Vendors
can specify create these little mini config files and ship them with
drivers. For example, for a bogus chip, called the Bogart3D, we have a

#PCI ID's that match the various Bogart chips
VendID: 12345
DevID:   98765
#xorg.conf style settings for the chip, foreach event
RenderAccel "True"
Modes: 1024x768x85

And similar files for input devices, monitors, etc, with event
sections for plugging and unplugging. The system hooks into the
underlying OS's device system, simulating plug events for all hardware
on X startup, and passing through hotplug events when they occur
(either by installing an appropriate hotplug helper, in the case of
the Linux kernel, or polling the hotplug device, like in OpenBSD).

As config files go, the current xorg.conf isn't bad in format - it's
pretty readable and writable - it's just too big, and can't be taught
about hardware that isn't necessarily always installed.

>                                 - Jim
> On Tue, 2004-11-30 at 12:43 -0500, David Zeuthen wrote:
> > Hey,
> >
> > I'm all for improving the situation with around auto configuration of
> > hardware, but with all due respect, I think you guys are trying to solve
> > the symptom, not the real problem. In my view you really want the X
> > server to be able to export an API for software higher up the stack
> > (GNOME, KDE, etc.) to configure the X server. You also want to
> > reconfigure it while it's running. It seems to me, that putting in an
> > mediator, for basically writing out configuration files, is not the best
> > API for doing this. I could be wrong though. Ideally the X server
> > wouldn't even touch hardware before someone used that API to say "Add
> > monitor, Add input device, blah blah".
> >
> > Anyway, with the right API in the X server (which would probably be
> > exported through D-BUS), I should be able to write a daemon, let's call
> > it gnome-input-manager, that runs in the desktop session as user davidz.
> > This would also allow said daemon to disable the touchpad when I connect
> > an external mouse or, for more fun, to disable it around intervals where
> > I'm punching the keys. The reason you want this in the desktop session
> > is that you want to query the locally logged in users preferences from
> > e.g. gconf or whatever.
> >
> > Just what I personally think.
> >
> > Have fun,
> > David
> >
> >
> > _______________________________________________
> > xorg mailing list
> > xorg at freedesktop.org
> > http://freedesktop.org/mailman/listinfo/xorg
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg


More information about the xdg mailing list