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 less complexity.
>
> 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 mostly 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 X11 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 X11 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 Wayland overlords.
>

AFAICS Wayland is an alternative to X11, not an extension to it (i.e.
stuff that runs on X11 won't run on Wayland). If that's true then the
transition from X11 to Wayland 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