Ignoring, because I can, this whole Ubuntu Mir thing completely, I
have begun to learn stuff about the Wayland protocol (and about
Clojure, with which I am still at the
constantly-having-to-google-stuff stage). Some random notes on what I
have learnt so far

First off: Java has no builtin support for talking to unix-domain
(AF_FILE) sockets. And nobody seems to make a Maven-packaged library
that does it either. This is a shame because Leiningen makes Maven
manageable, but anything unmavened involved tedious mucking around.
Eventually I did

and watched it hang. After some time looking at documentation and
mucking about with strace to see if it was trying to read the full
buffer instead of doing the dhort read I wanted it to, I eventually
thought to use socat instead of clojure. It turns out that the
client is expected to make the first request before the server sends
anything, and with the use of strace weston-info I was able to find
out what.

Time to start writing some code to parse
wayland.xml
so we can actually find out what this means. The usual way to do XML parsing in clojure seems to be using
zippers and the easy examples seem to be somewhat lacking or slightly
ungooglable. You need a project dependency on org.clojure/data.zip
and a bunch of package requires, then you call clojure.zip/xml-zip on
the return value of clojure.xml/parse and that gets you a zipper

where I have conveniently left out the definition of parse-protocol
and everything it calls because it’s longwinded and tedious (but the
code will be on github as soon as I’m not ashamed of it) but it might
hypothetically do things like

(x/xml-> my-zipper :protocol :interface :request)

to descend the tree through <protocol> <interface> <request>
and return all the elements. Use the similarly named x/xml1-> to
get the first matching element. The return values from these things
are themselves zippers and you can call up, down etc – or xml->
again – to traverse the tree further, then eventually call node when
you want to get the element itself. So e.g.

So let’s handwave over the details and take it on trust that I have
parsed the whole file. There are two other things I discovered -
mostly thanks to the #wayland IRC channel participants – about the
wayland wire protocol that the docs don’t mention:

where it says “The first word is the sender’s object id (32-bit)”,
when it’s describing a message sent from client to compositor, what it
means is “The first word is the target object’s id (32-bit)”.

object id 1 is special: it refers to the core global singleton
object, which implements the interface wl_display

Given which, we can attempt to parse that first client→compositor message

Next up, some code to create messages. And something, which may
involve an atom, to map object ids to their corresponding interfaces
as we learn them. After that, we find out what the Wayland FAQreally means by “shareable buffer”