Re: [dev] [dwm] Conversion to XCB

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Tue, 21 Jan 2014 15:07:03 +0100

On Tue, Jan 21, 2014 at 12:45:36PM +0000, Nick wrote:
> On Tue, Jan 21, 2014 at 01:07:37PM +0100, Markus Wichmann wrote:
> > Also, maybe the majority here is unaware of what kind of a code base
> > Xlib is. I have seen OS kernels with more simplicity.
>
> I haven't used either Xlib or XCB to any significant degree, but
> isn't the XCB code generated from an XML specification? 'Cos that
> sounds rather... suspect.
>

It is leastly autogenerated, yes, but that's only because the actions are
pretty repetitive. In the end, what are these functions doing? For every
possible request (the Wayland protocol has many) there is

- a function that sends the request without expecting an answer (unchecked)
- a function that sends the request expecting an answer (checked)
- a function that waits for error or reply (reply)
- an accessor function or two if there is a reply type

For requests that typically don't get a reply, the unchecked version is
the default, for the others it's the checked version. Now where is the
difference between writing that by hand for each request and
autogenerating the code?

It does serve to highlight some peculiarities of the Wayland protocol. For
instance each request starts with an 8-bit field containing the request
type and then has an 8-bit field that's usually padding. However, for
some requests it's actually used as value. Since in XCB the function
arguments are in the same order as the fields in the request, those
fields appear directly as second argument to the request functions.
That's the case for the ChangeProperty request, where that field represents
the property mode. In Xlib, the XChangeProperty() function has the
prop_mode argument as sixth, while it is the second argument of
xcb_change_property().

Sometimes, I'd rather have an Xlib-like interface, for instance for the
ChangeWindowAttributes request. XChangeWindowAttributes() actually gets
a structure containing the changes, while xcb_change_window_attributes()
gets an array. And that array has to be in the correct order! (Which
basically means you have to look up the enum containing the XCB_CW_*
constants so you can maintain the correct order)

> I for one look forward to welcoming our new EGL X11 overlords.
>

AFAICS X11 is an alternative to Wayland, not an extension to it (i.e.
stuff that runs on Wayland won't run on X11). If that's true then the
transition from Wayland to X11 should be as smooth as the transition
from IPv4 to IPv6. Oh, wait...

Ciao,
Markus
Received on Tue Jan 21 2014 - 15:07:03 CET