Re: protocol enhancements

Around 10 o'clock on Mar 24, David Dawes wrote:

> Xinerama with enough high-res screens can come close today (I can never
> remember if the limit is 32767 or 65535).  I'm sure that there'll be other
> issues exposed as we start working towards this.  I'd like to see at a
> minimum that the X server internals, and any proposed re-writes thereof in
> the context of 5.0, are prepared for this and for deeper and non-integer
> pixel types.

I've been thinking of several schemes for supporting larger screens.  The 
problem is how to get existing applications to work with root windows that 
are larger than 32767 in size.  I can imagine a segmented architecture 
with base/offset pairs so that the window manager can change the base 
value for an entire client while the existing 16-bit value is treated as 
an offset.  That might make it possible for applications to keep their 
menus and windows together.  I'm not very comfortable with this scheme 
though, perhaps others will have better suggestions.

Support for deeper/non-integer pixel formats are easy at the protocol 
level as we can easily translate between the two pixel formats.  I 
envision 32bpp core visuals mapped to extended visuals; core requests 
would always deal with pixels in 32bpp form while extended requests can 
handle the new format.  Render already has support for 64 bit integer 
pixels, but it will need extensions to handle non-integer values.

> I also think that bumping the protocol minor revision should be explored as
> a backward-compatible mechanism for enhancing the core protocol.

A minor revision would be necessary if we were to change any of the 
behaviour of the core requests.  As we would have to provide for cross 
compatibility in both directions, it will probably be safer to enhance
the protocol through the extension mechanism.  

The reason is that the protocol revision is global, so every part of the
application sharing the same X connection would have to support the new
revision while extensions permit existing code to continue working
unchanged while new code takes advantage of new functionality.

There may be compelling reasons to bump the revision number, but we should 
be very careful in doing so.

-keith