dynamic driver configuration idea...

[Egbert Eich]

Dave Airlie writes:
 > I've been thinking about this and recently after using Thomas
 > Winischhofer's sisctrl application wondered why we don't have a
 > standard method for driver configuration...
 > 
 > I'm thinking something like driconf does for DRI 3D drivers, but maybe
 > a bit more network aware, (btw driconf just writes a local .drirc
 > file, and it gets the config options from the actual driver binary and
 > this is read by the 3D client library at startup so you can have
 > differnet settings for different apps... etc..)
 > 
 > it would probably be like a super xrandr, the driver could return an
 > XML description of what if wants to offer, a GUI app could build a GUI
 > from those options and could then send the results dynamically back to
 > the driver to reconfigure itself.. as every driver would have
 > different options I wouldn't feel the need to limit it through some
 > interface hence XML or something like that...
 > 
 > Mainly I would think of CRT configurations, desktop size, driver
 > acceleration tweaks, like you see on Windows drivers .... also it
 > might have the option to write the X config file but that may not be
 > necessary...
 > 
 > I can see security issues as well with what clients can access it .. 
 > 
 > btw I probably won't write this at all, just throwing the idea around
 > as that sisctrl panel doth rock when messing with TV-OUT on an SIS
 > laptop...

I had a similar idea a while back. Starting from the attributes for Xv
which depend on the capabilities of the driver/chipset. There the driver
can provide some information on the properties of the attributes it accepts.

My idea was to provide enough information so that a gui application can
provide a meaningful interface even without knowing about the specific
property. 
Additionally I wanted to cerate a registry for 'well known properties'
so that their behavior can be uniform across drivers.
My idea was to create an extension which would eventually have replaced
the ill designed xf86misc extension (and the xf86vidmode extension).
Also some functionalities of Xrandr (the screen resolution reconfig
part, not the event notofication part) could have been placed there.
Also a lot of the static config options from the drivers could have
been made dynamic thru this mechanism.

In short it would have consolidated most of the DDX specific extensions
having to do with DDX configuration.

Since then paradigms have changed as people explained that there is no 
need to craft an extension as it doesn't make sense to push this over 
the wire.
This may be true to some extend - on the other hand thinking of thin
clients with absolutely no local X client running there may be exceptions.

Anyway, I kind of have abandoned that idea.

Egbert.