Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Jim Gettys]

> > 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
that is.
> 
>    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.)
> 
> Thanks,
> - 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
> http://lists.freedesktop.org/mailman/listinfo/xorg