[Xcb] Next Release?

Daniel Martin consume.noise at gmail.com
Fri Aug 16 13:57:27 PDT 2013


On Fri, Aug 16, 2013 at 12:20:38PM -0400, Peter Harris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2013-08-16 11:04, Uli Schlachter wrote:
> > On 06.08.2013 19:55, Uli Schlachter wrote: [...]
> >> Also, I just remembered that there is a bug against xcb-xkb: 
> >> https://bugs.freedesktop.org/show_bug.cgi?id=51295
> > 
> > It seems like the general consensus here is that this can be
> > ignored for now. I don't have any strong opinions about this,
> > mostly because I have not much clue about xcb-xkb.
> 
> Yeah, the protocol description of the XKB event (singular) is buggy
> (there are multiple <event>s).

We could:
- comment out the current events (to have the fields at hand when the
  issue is fixed) and
- add an generic event (number=0?) having the fields as in xkbAnyEvent,
  see /usr/include/X11/extensions/XKBproto.h.
When the issue gets fixed we just add the switch to the AnyEvent.


> I'd like to see an enum with all the XKB sub-event numbers in it, so
> authors using libxcb/xkb have a chance to use constants that will stay
> around, rather than the event #defines that will disappear once the
> xml is fixed.

I had attached such a patch to the bug.


Then there's the GetGeometry request, which is known to be broken atm.
Here we could comment it and related structures too. And readd them when
the code generator is able to handle it properly.

Commenting stuff out might not be the prettiest way, but it prevents us
from having API breaks later. If no one has a better plan, I could write
the patches tomorrow.


> > P.S.: We want new libxcb and xcb-proto releases, right? We need
> > libxcb to enable xcb-xkb by default and xcb-proto for lots of
> > random fixes? Does this mean, that the new libxcb should depend on
> > thw new xcb-proto release?
> 
> Yes, there are some changes to xcbgen since 1.8, so libxcb won't build
> properly without the new xcb/proto.

In detail that is:
    xcbgen: Handle multiple <enumref> in a <bitcase>
in xcbgen, which breaks c_client.py and requires
    c_client.py: Handle multiple expr. in a bitcase.
And for X Generic Event support it's the other way around (patch in
c_client.py relies on attributes that have been add to xcbgen).


Cheers,
    Daniel Martin


More information about the Xcb mailing list