simple XRANDR extension proposal

[John Meacham]

Yeah, I only stated it as an RANDR extension since the RANDR event
already has all the interesting fields one would want to tell a client
about dealing with it's new root window, so clients that do something
interesting on XRANDR events will handle migrating between screens
automatically too. Within the server, I imagine, their implementation
would have little to do with each other. (unless you wanted to emulate
different bit depths between screens). 

An extension I would really like (perhaps to implement..) is a LAZYPOLL
extension, which would implement lazy polling as described in the paper
http://citeseer.nj.nec.com/gajewska90why.html (which everyone who is
interested in X development should read, it is quite good). but not just
for mouse events, but also for window attributes (such as resize events
(!!)), window properties and Xi events. this should give us the ability
to eleminate many race conditions and improve the user experience a lot.
imagine if what is displayed on screen never got out of sync with the
mouse pointer. delicious.

While on the subject of XFIXES, a couple more things which I think would
fit well in it. a 'wipeBuffer' type thing which will tell the server to
drop all outstanding drawing requests for a given window (this might be
problematic to implement on the server, since it would require
look-ahead)  and well.. heck. many of the things mentioned in the above
paper. (synchronous wm redirects would be sweet...), also, if there were
an easy way to extend the protocol such that mouse movements in XDND did
not require server round-trips all the time, that would be quite a
useful addition to XFIXES. (the need for both these things would be
mitigated by a proper LAZYPOLL extension)

        John


On Wed, Jul 23, 2003 at 11:41:29PM -0400, Keith Packard wrote:
> 
> Around 14 o'clock on Jul 23, John Meacham wrote:
> 
> > if XRANDR is present, then XReparentWindow behaves slightly differently, if
> > the new parent window is on a screen other than the one the window is
> > already on, then rather than generate a BadWindow error, the window will be
> > reparented succesfully and a RANDR event will be generated and sent to the
> > reparented window containing it's new root window information. an
> > implementation may require that a compatable visual exist on the new
> > screen. (which XReparentWindow requires on the same screen anyway)
> 
> That's a good idea, and one which I've been considering adding to XFIXES 
> as it really has no relationship with RANDR.  There are additional tricks 
> required here -- essentially all screen-specific resources (pixmaps, gcs, 
> pictures) would need to be come screen-independent within the X server 
> implementation.  I think it's all do-able, but it will take some 
> experimentation and probably cooperation from applications -- you don't 
> want to surprise them with a root change as that may break things badly.
> 
> -keith
> 

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john at foo.net
---------------------------------------------------------------------------