thomas at winischhofer.net
Tue Oct 25 09:09:34 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
Waldo Bastian wrote:
> On Thursday 29 September 2005 16:44, Thomas Winischhofer wrote:
>>Alan Hourihane wrote:
>>>Why do you need to reinitialize the extension ?
>>>For RandR it works off the modepool. There's nothing stopping a driver
>>>ripping the modepool apart and revalidating it. Thus forcing RandR to
>>>export new supported resolutions.
>>I stand corrected. Don't know why I was under impression that these
>>extensions only read-out the available modes during initialisation. Both
>> allow adding/removing modes anytime in fact.
> Would it be a good idea then to extend RandR with an option that asks the
> driver to do just that (rip the modepool apart and revalidate it)? That would
> be a useful step towards a more adaptable X server IMHO.
The sis driver already does this. (Will be committed to CVS after the
release). Although it's the other way round - the driver initiates the
modelist regeneration upon detection of a new output device (or if
output devices are changed). Don't see why this would be the task of
RandR - quite the opposite, display modes are none of RandR's business IMHO.
Haven't tested too many applications yet with this "dynamic modelist",
but at least vmware chokes on a change of available DGA modes (seems to
query DGA only once at start and then never again). But DGA is dying out
Now if someone adds a hook to reallocate the root window (and reinit the
fb layer with a new fb stride, and taking care of DRI clients which need
to get informed about the new stride as well), we're all set for dynamic
MergedFB mode enabling/disabling. I think Aaron Plattner is/has been
playing with this (the first issue, that is).
thomas AT winischhofer DOT net *** http://www.winischhofer.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the xorg