Elektrified X.org released (was: X configuration paradigm, and a proposal)
Jim.Gettys at hp.com
Mon Dec 6 07:18:11 PST 2004
> > Resolution we now can handle using randr.
> Sort of. RandR falls short in several ways:
> 1) video memory is always allocated for the largest size root
> window (maybe there is already a way for a driver to
> know when the amount of video memory can be freed and
> reallocated at the current resolution?)
This is an implementation detail ;-).
Yes, we have to fix the implementation. I'm not sure how painful
> 2) the list of possible root window sizes is fixed at server
> start; this prohibits the NVIDIA driver, for example, from
> dynamically enabling TwinView.
> I've been thinking that 1) could be easily addressed by passing
> a flag through the (currently unused?) ScrnInfoPtr->SwitchMode()
> flags parameter, to indicate that it is safe to resize the allocated
> root window to the new mode's size.
Sounds like a plausible approach for the time being.
> 2) is particularly interesting if we want to support hotplugging
> of display devices (eg: plug your laptop into a CRT, and then grow
> your X screen to span across the CRT and the internal panel).
There is another approach to this problem by ignoring Xinerama, and
relying on compositing managers to do the work.
> I've been planning on putting together a proposal for an updated
> version of the XRandR spec, but haven't had the time, yet. If anyone
> else is interested, I'd be willing to collaborate on this.
> (Also, note that refresh rate, like DPI, is a pretty meaningless
> property of an X screen once you start talking about multiple
> physical display devices scanning out portions of one X screen.)
> - Andy
> > Depth has been a real problem: we believe it would break most existing
> > applications (particularly Xt or Motif applications, if we had tried to
> > do it the way we first envisioned in randr, and then backed away from.
> > But composite makes depth switching easy: the applications don't have
> > their depth changed out from under them, and only the compositing
> > manager has to do anything. So we should be able to handle this pretty
> > well once composite is the "normal" way most people use X.
> > We have lots of work to do for handling outputs and for mode setting in
> > general. But this should be (mostly) something that most applications
> > don't have to care about.
> > - Jim
> > _______________________________________________
> > xorg mailing list
> > xorg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xorg
> xorg mailing list
> xorg at lists.freedesktop.org
More information about the xorg