[Xcb] Working on RandR 1.2 proto

[Ian Osgood]

On Nov 28, 2006, at 12:53 PM, Jamey Sharp wrote:

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

Ah. I'll start with a union then. That ought to work nicely.

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

Damage, Screensaver and Shape all have events that contain a subcode,
but it doesn't affect the rest of the event structure.

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

Wow, only 64 events available?! That is a good argument for *always*  
having only one event per extension.

> 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