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

[Andy Ritger]

On Mon, 6 Dec 2004, Jim Gettys wrote:

> On Tue, 2004-11-30 at 15:52 -0500, Alex Deucher wrote:
> > On Tue, 30 Nov 2004 19:44:08 +0000, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
> > > On Maw, 2004-11-30 at 18:23, Jim Gettys wrote:
> > > > David,
> > > >
> > > > I agree with you and Kristian and I have started work, specifically on
> > > > the input system side to do exactly what you suggest.  Similar
> > > > work ought to be done someday for the screens themselves (hotplug being
> > > > a reality even for screens; today with PCMCIA and PCI express is just
> > > > beginning to ship).
> > > 
> > > Mobility Electronics have been shipping cardbus hotplug video for about
> > > 5 or 6 years now (E1000V). They make fun toys for this sort of testing
> > > and are cheap on ebay generally 8)
> > > 
> > > 
> > 
> > For that matter, AGP and even PCI video cards have been able to change
> > resolution, colordepth, type and number of outputs, etc. on the fly
> > for even longer.
> > 
> 
> 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?)

   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.

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

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
>