Fwd: [kdelibs/frameworks] tier1/kidletime/src: Port the native event filtering to XCB, to fix compilation with Qt5.

[Fredrik Höglund]

On Wednesday 25 July 2012, David Faure wrote:
> Hi Fredrik,
> I made progress with the port of kidletime to XCB, but I found a bug in XCB...
> 
> xcb/sync.h says (with my comments added about field size) :
> 
> typedef struct xcb_sync_systemcounter_t {
>     xcb_sync_counter_t counter; /**<  */                  // 4 bytes
>     xcb_sync_int64_t   resolution; /**<  */               // 8 bytes
>     uint16_t           name_len; /**<  */                 // 2 bytes
> } xcb_sync_systemcounter_t; // sizeof says 16 bytes due to padding
> 
> but sync.c (in the XCB sources) says:
> 
> char *
> xcb_sync_systemcounter_name (const xcb_sync_systemcounter_t *R  /**< */)
> {
>     return (char *) (R + 1);
> }
> 
> Shouldn't that be
> 
> char *
> xcb_sync_systemcounter_name (const xcb_sync_systemcounter_t *R  /**< */)
> {
>     return (char *) (R) + 14;
> }
>
> (gdb confirms that the name is after the struct, as I expected).

Yes, and the libXext sources confirm that as well.  Although I think one
could argue that it's really a bug in the sync protocol that the data isn't
padded out to 16 bytes.  Of course it's a bit late to fix that now.

> Apparently this comes from c_client.py, in the code that says
>         if field.prev_varsized_field == None:
>             _c('    i.data = (%s *) (R + 1);', field.c_field_type)
> which comes from field.type.fixed_size(), but I can't find the definition of
> fixed_size() anywhere...
> 
> Well, maybe this is fixed in a more recent XCB than 1.7?

As far as I can tell it isn't.

> Do you know XCB developers, or where to report such issues?

They use the freedesktop bugzilla, and there's also an xcb mailinglist there.

> If you want to give it a try, see the commit below (the code is commented out for now).
> 
> Also, the alarms don't trigger, so I wonder if this is another bug in xcb, or if my
> port (which mixes the use of XCB and X11) is faulty...
> 
> If you could have a look, that would be awesome ;)

The only thing I can think of is that it may be necessary to call XFlush()
after making Xlib calls.  The output buffer is automatically flushed when
XNextEvent() is called, but since Qt is using xcb to handle events it
never calls that function.  So it is quite possible that the requests to
set the alarms are just sitting in the queue.

The if (event->response_type == ...) should probably also be
if (XCB_EVENT_RESPONSE_TYPE(event->response_type) == ...),
but I don't think that's the problem in this case.

Fredrik