[Xcb] [PATCH 5/7] Add event queue splitting

Eric Anholt eric at anholt.net
Thu Nov 7 01:55:45 CET 2013


Uli Schlachter <psychon at znc.in> writes:

> Hi,
>
> On 06.11.2013 20:34, Peter Harris wrote:
>> On 2013-11-05 19:41, Keith Packard wrote:
> [...]
>>> diff --git a/src/xcb.h b/src/xcb.h
>>> index f7dc6af..f99e677 100644
>>> --- a/src/xcb.h
>>> +++ b/src/xcb.h
>>> @@ -138,23 +138,6 @@ typedef struct {
>>>  } xcb_generic_event_t;
>>>  
>>>  /**
>>> - * @brief GE event
>>> - *
>>> - * An event as sent by the XGE extension. The length field specifies the
>>> - * number of 4-byte blocks trailing the struct.
>>> - */
>>> -typedef struct {
>>> -    uint8_t  response_type;  /**< Type of the response */
>>> -    uint8_t  pad0;           /**< Padding */
>>> -    uint16_t sequence;       /**< Sequence number */
>>> -    uint32_t length;
>>> -    uint16_t event_type;
>>> -    uint16_t pad1;
>>> -    uint32_t pad[5];         /**< Padding */
>>> -    uint32_t full_sequence;  /**< full sequence */
>>> -} xcb_ge_event_t;
>>> -
>>> -/**
>> 
>> This hunk doesn't appear to be related to event queue splitting. Should
>> it be in a separate commit?
>
> Thanks for CC'ing the xcb mailing list. I can see why this ended up on
> xorg-devel (xcb being the only "sub-project" with its own list), but it would
> still be nice to have patches for libxcb or xcb-proto on the xcb mailing list.
>
> With google I found the patches in question and looked at them quickly. My first
> impression is that the xcb_*_special_event() functions might need way better
> documentation.
>
> Also, this adds public API that allows to "hide" XGE events from the "normal"
> APIs for getting events. Since this seems to be written just with present in
> mind, I can see why it is done like this, but if we really want to go down that
> road, I don't see why this should be XGE-specific.
>
> Since this is public API, we should IMHO think thrice before settling on something.
>
> For all the other patches, I am too lazy to get them out of the online archive.
> I would count that as a NAK as long as it is understood that I don't have any
> veto powers. ;-)

libGL needs events from the server that are hidden from the user,
because we events to make direct rendering work, and the user's event
handling will not be ready to see one of those events, and they're
certainly unable to pass us the events because they don't even know they
exist.

We tried to do this with event queue filtering the same way we do with
xlib, and it got NAKed.  Then we came up with new events and a new
mechanism so that we could do this, and it's getting NAKed again.

Right now we're depending on xlib for event handling in GLX so we can
build a working direct-rendered GL, and EGL is broken because it's pure
XCB.  If we can get an API for this, we can move to pure XCB for GLX,
and if not, then I need to go put an xlib dependency into EGL
platform_x11.c so that I can make event handling work.  We'd really
rather be using XCB if we could.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20131106/56ac5e79/attachment.pgp>


More information about the Xcb mailing list