[Xcb] [Bug 51295] various problems with the xkb protocol bindings

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51295

Daniel Martin <consume.noise at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |consume.noise at gmail.com

--- Comment #1 from Daniel Martin <consume.noise at gmail.com> ---
(In reply to comment #0)
> The XKB extension has only a single event number. These events contain a
> xkbType field which then says which kind of event this actually is.
> The current xkb.xml describes these events as seperate events, but from the
> POV of the generator, they are just a single event.
> 
> <psychon> daniels: <event name="BellNotify" number="8"> <- doesn't the "8"
> here mean that the event is xkb-event-base + 8?
> [...]
> <daniels> so technically having them as separate <event>s is wrong i think
> <daniels> but i'm not sure how to cover loads of totally disparate events
> all having the same event type
> <pharris> daniels: One event, with a giant <switch>.
> [...]
> <pharris> daniels: Or possibly a <union>, but I dislike <union> as it
> doesn't represent well in non-C languages.

That would be a switch/case. Which is no fun to add into the existing code
generator.

I could think of a workaround/hack:
- transform the existing events into structures
- add one event with the structure like xkbAnyEvent
With that one could cast the incoming sub events into the appropriate
structures and we would just have one event.

But, one day we'll have a switch/case (I promise, just a matter of [spare]
time). If we're going to replace the workaround with the switch/case we'll have
an API break.


> The second issue is:
> 
> <enum name="EventType"> [...] <item name="BellNotify"> <bit>8</bit> </item>
> 
> This causes a #define XCB_XKB_EVENT_TYPE_BELL_NOTIFY 256 to be generated,
> but this actually wants a define with value 8.

That's easy to fix, i.e. with the following attachment. Well "easy to fix" with
the assumption: The generated event structures are incorrect and therefor the
SelectEvents request hasn't been used by anyone. Because, that patch replaces
XCB_XKB_EVENT_TYPE_BELL_NOTIFY, which potentially has been used to select
events. The old one is renamed to XCB_XKB_EVENT_TYPE_MASK_BELL_NOTIFY.
So, if the assumption is wrong, then this is an API break and another name for
the enum with the BellNotify=8 has to be choosen.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20130806/3cb0da2d/attachment.html>