[Xcb] [PATCH x2] Add protocol descriptions for GE and XFree86VidMode

[Peter Hutterer]

On Mon, May 25, 2009 at 09:41:11PM -0400, Peter Harris wrote:
> On Mon, May 25, 2009 at 6:02 PM, Mariusz Ceier wrote:
> > Peter Harris pisze:
> >> Mariusz Ceier wrote:
> >>> Peter Harris pisze:
> >>>> These two patches add protocol descriptions for Generic Event Extension
> >>>> and XFree86VidMode.
> >>>>
> >>> Shouldn't Generic event be also defined in ge.xml ?
> >>
> >> Good question.
> >>
> >> From my perspective, xcb_genericevent_generic_event_t shouldn't be
> >> defined in XML any more than xcb_generic_event_t should be[1]. For that
> >> matter, xcb_ge_event_t is already defined in libxcb/xcb.h.
> > Current xcb_ge_event_t have some meaningless members like pad1 ...
> 
> pad0 should be renamed to "extension", but even the generated version
> would have to have the rest of the padding.
> 
> > What about:
> >  * changing extension-name to GE - so we don't have ridiculously long
> > names ...
> 
> For an extension with only one request? That would be poor Huffman
> coding. (I think I've been reading too much Larry Wall :-) )

FWIW, I don't expect XGE to get a large number of requests in the future (if
any). The reason for it's existance is simply to announce the possibility of
GenericEvents. It's also not an extension that will be actively used by
applications other than that they receive events that match the template.

> >  * removing xcb_ge_event_t structure from xcb.h
> 
> The generated event structure wouldn't include the full_sequence field...
> 
> >  * including ge.h header generated from ge.xml
> >  * adding "typedef xcb_ge_generic_event_t xcb_ge_event_t;" - for
> > compatibility with current apps that could already use this struct
> > ?
> 
> ...and this would cause core xproto to depend on a library that not
> everybody will want to build or install.

core xcb must be able to handle GenericEvents, otherwise the protocol goes
out of sync. This applies also if you're using the libX11 wrappers (hence
the current implementation).

> >> I don't see a really compelling reason not to also define it in the XML.
> >> It just feels redundant.
> >>
> > I think it would be better to have xcb_ge_generic_event_t only in XML,
> > so we could keep all protocol definitions in one place ( xcb-proto ).
> > That will be important when we would like to generate server-side code,
> > from those descriptions.
> 
> Normally I'd agree, but Generic Events are going to want their own
> syntax eventually anyway. See Xinput2 (and other future extensions).
> Generic Events are fundamentally a new datatype, and not really the
> same thing as traditional events.

Think of GenericEvents as a template for events, with the extension, evtype
and length fields being the only mandatory ones. No other extension relies
on GenericEvents directly, they all have their own types that match the
template.
In the same way that xcb_generic_event_t is a generic wrapper for any event,
xcb_ge_generic_event_t is a generic wrapper for any XGE event.

> >> [1] Ugh. Feels like a namespace collision. But there was no way to know
> >> that someone would come up with "Generic Events" years after this name
> >> was chosen.
> > Huh, I thought that xcb_generic_event_t is Generic Event ... :)

When I implementd the server-side of XGE I didn't know about xcb's
internals. And the name "generic events" for, well, generic events seemed
somewhat appropriate.

Cheers,
  Peter