[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Tue, 2004-11-30 at 13:14 -0500, Darrin Thompson wrote:
> On Tue, 2004-11-30 at 12:43 -0500, David Zeuthen wrote:
> > 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".
> > 
> Elektra does not prevent any of what you describe.

Not sure, I see that the Elektra API is key/value based and the only two
types supported appears to be UTF-8 strings and Blobs. Perhaps it would
be useful with other fundamental data types on grounds of type safety.

> The current implementation does appear to assume (I've not tried it)
> that the current X config should map to neatly to key/value pairs in a
> similarly shaped namespace. The namespace of those pairs seems to be a
> sticking point. Seems that once you separate input config from monitor
> config at the file level, keeping them together as "X" config doesn't
> make so much sense anymore.

The API I'd like to see the X server export would definitely include
methods/facilities that you cannot express in terms of 'set one more
more keys atomically'. 

For instance, shouldn't the X server expose a method Degauss() if the
hardware is capable of degaussing a monitor?

(locking down who and what is permitted to invoke Degauss() is another
matter entirely - I suggest that people take a lot at D-BUS and some of
the policy you can apply there; e.g. only allow console user to do it.
In fact, it might be too dangerous to expose such a method as repeated
use might damage the hardware, but you get the point)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]