dynamic driver configuration idea...

[Andy Ritger]

On Wed, 13 Apr 2005, Egbert Eich wrote:

> 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.

FWIW, the NVIDIA X driver advertises the NV-CONTROL X extension,
and I have been very happy with it.

The most common NV-CONTROL client is nvidia-settings
(ftp://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-1.0.tar.gz),
though the API is documented (see NV-CONTROL-API.txt in the above
tarball), and we've had customers and assorted end users write
their own NV-CONTROL clients.

Most of the configurability we've exposed through NV-CONTROL thus
far have been simple integer attributes, where clients can query
whether the attribute is available on the given X screen, what the
current value is of the attribute, what the valid values are for
the attribute, and set new values for the attribute.

Extending the API then just consists of adding new attributes.

Of course, we've run into plenty of strange cases that forced us
to add additional entry points and protocol to NV-CONTROL, but
the majority of the functionality remains in the simple integer
attribute manipulation.

This might be a useful architecture to mimic for other projects,
though I do believe so much of the functionality is vendor-specific
that it would be hard to provide something generic, especially on
the gui side.

- Andy


> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>