[Xcb] Working on RandR 1.2 proto

[Jamey Sharp]

On Tue, Nov 28, 2006 at 11:47:11AM -0800, Ian Osgood wrote:
> OK, I've hit the first XSLT limitation.
> 
> RandR 1.2 defines one new event ("Notify") which has three subCodes  
> (specified using the CARD8 hole between event type and sequence  
> number). Unfortunately, the remainder of the event structure is  
> completely different between these three subcodes. Currently, our  
> XSLT doesn't allow us to overload event numbers with different event  
> structures like this.

Well, sort of. We have the ClientMessage event, which contains the
ClientMessageData union. The caller has to figure out which element of
the union to use based on the atom "type" in the event. We might just
want to model the Notify event the same way.

Question: what code should this generate? Since the XML tagset isn't
frozen, we can fix the way we describe this later; but at this point we
get basically one chance at the C API. So I think working backwards
makes sense.

If it makes the most sense to treat this event as a tagged union, then
we don't need anything new in the XSLT.

> Is this a useful enough pattern in extensions for us to extend our  
> XML descriptions with an optional subcode?

Someone correct me if I'm wrong, but I don't think this sub-event code
pattern appears in any other extension. And unfortunately, I don't see
how we could usefully expose the information to C applications, which
already have to check the response_type and cast to the appropriate
event structure. Later we may add support for a conditional construct in
the XML: search for "grrrr" in glx.xml for a motivating example. :-)
That may or may not turn out to help C clients, but should at least
prove useful for higher-level language bindings.

> Or should we ask Keith to use standard event numbering, introducing  
> three new events instead of one event with three subcodes?

We can ask, but I'm not betting on it helping. :-) The X protocol
reserves event numbers 64 through 127 for extensions (see section 1,
under "Event Format"). My X server has events up through number 115, and
there are plenty of extensions I don't have enabled. If randr1.2 adds
three new events, I'll only have room for nine more extension events.
I'm guessing this is why Keith did this wacky sub-event thing.

It's frustrating that the range from 35 through 63 isn't also available
for extensions. The client isn't allowed to hardcode the event numbers
anyway, so why not just let the server allocate any legal number?

Also, I think the server could allocate event numbers on a per-client
basis: only allocate an event base for an extension when a client calls
QueryExtension on it.

Oh well...

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061128/38a40f90/attachment.pgp