Tweet
Lookie at the wonderful mail sent to xorg@freedesktop.org:
Getting the big picture from config file for driver configuration & validation
From: Michel Hubert <mhubert@matrox.com> (Matrox Graphics Inc.)
To: xorg@lists.freedesktop.org
Date: Today [EDIT: 15.3.2005] 00:45:52
Hello,
I am working at Matrox on a new driver architecture for our graphics
cards. One problem we have encountered since the introduction of our
multi-heads products is that we do not have access to the big picture in
the PreInit() phase where we are supposed to validate the requested
configuration. Each Screen is validated independantly.
The fact is that hardware is not always symmetric. Some ressources are
best used in some configurations. Hardware constraints may limit some
functionnality and so on. In fact, under the current conditions, it is
very difficult to guarantee users that the partially validated
configuration they requested, will in fact work seamlessly during the
ModeInit() phase.
For example, let's take a triple head configuration in Xinerama. 3
ScrnInfoRec are created, and PreInit() is called for each one. Using
Entity Private Data, each one can know how many outputs have been
requested up to now and to some degree, what are the requested
features. But this implies that the complete config validation has to
be reperformed each time a new pScrn is added and that adds a lot of
unncessary complexity.
A simple solution would be for the driver to have access to a variable
like xf86NumScreens per device. That way, we could do minimal testing
in each PreInit() and knowing the last instance call to PreInit(), we
would validate the entire config. But that would mean that some PreInit
were successfull, might be rejected in the end anyway.
A better solution would be for the driver to have access to a variable
like xf86configptr. That way we can really get the big picture and
validate according to our hardware constraints.
We have even been thinking of creating our own configuration files based
on xorg.conf files, or to write our own parser to solve this problem.
We recognized that would not be very well accepted and that it would be
difficult for us to support parameters passed on the command line to the
Xorg Server in a clean way for every platfroms.
Of course, we would highly prefer a cleaner solution and an endorsement
of our proposal from Xorg. The bottom line is that would make a more
robust driver and would allow us to offer more functionnality to our
users.
By the way, what's up with the Elektra project ? Are you committed to
adopt such a technology ? What is your roadmap about it ? Maybe our
proposal to allow a video driver to get the "big picture" would fit with
the required changes to the Xorg parser...
Looking forward to your constructive comments,
Michel Hubert
Linux Video Driver developper
Matrox Graphics
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
From: Michel Hubert <mhubert@matrox.com> (Matrox Graphics Inc.)
To: xorg@lists.freedesktop.org
Date: Today [EDIT: 15.3.2005] 00:45:52
Hello,
I am working at Matrox on a new driver architecture for our graphics
cards. One problem we have encountered since the introduction of our
multi-heads products is that we do not have access to the big picture in
the PreInit() phase where we are supposed to validate the requested
configuration. Each Screen is validated independantly.
The fact is that hardware is not always symmetric. Some ressources are
best used in some configurations. Hardware constraints may limit some
functionnality and so on. In fact, under the current conditions, it is
very difficult to guarantee users that the partially validated
configuration they requested, will in fact work seamlessly during the
ModeInit() phase.
For example, let's take a triple head configuration in Xinerama. 3
ScrnInfoRec are created, and PreInit() is called for each one. Using
Entity Private Data, each one can know how many outputs have been
requested up to now and to some degree, what are the requested
features. But this implies that the complete config validation has to
be reperformed each time a new pScrn is added and that adds a lot of
unncessary complexity.
A simple solution would be for the driver to have access to a variable
like xf86NumScreens per device. That way, we could do minimal testing
in each PreInit() and knowing the last instance call to PreInit(), we
would validate the entire config. But that would mean that some PreInit
were successfull, might be rejected in the end anyway.
A better solution would be for the driver to have access to a variable
like xf86configptr. That way we can really get the big picture and
validate according to our hardware constraints.
We have even been thinking of creating our own configuration files based
on xorg.conf files, or to write our own parser to solve this problem.
We recognized that would not be very well accepted and that it would be
difficult for us to support parameters passed on the command line to the
Xorg Server in a clean way for every platfroms.
Of course, we would highly prefer a cleaner solution and an endorsement
of our proposal from Xorg. The bottom line is that would make a more
robust driver and would allow us to offer more functionnality to our
users.
By the way, what's up with the Elektra project ? Are you committed to
adopt such a technology ? What is your roadmap about it ? Maybe our
proposal to allow a video driver to get the "big picture" would fit with
the required changes to the Xorg parser...
Looking forward to your constructive comments,
Michel Hubert
Linux Video Driver developper
Matrox Graphics
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I'd love to hear if there's anything else to this story, especially as to why nobody seems to have put together a legal challenge to it if it's really as bad as it sounds.
Comment