I really, *really* like the way the Rust library is built and managed. It does a
really good job of emulating the XCB RandR macro found in KDE's Plasma and
libkscreen. The port was straightforward and my worries about memory management
were completely unfounded.
This is just that I added a lot of comments to each new command in the CMakeList
file, because if I ever have to re-use this obscure and infrequently used skill,
I'll have a record written in my own words.
This matches the learning process that I describe in rigged_regex. Step by
step, recording everything multiple times and in multiple ways, so that all the
learning that I care about is preserved. There's XCB in here, and some C++
(mostly around `unique_ptr`).
reliable as a source of truth about which monitors and screens are
actually in use. Each one comes with its own collection of `crtc`,
but you can just skip the ones that return `null`, giving you a
reliable list of the "active and visible" screens that the user is
currently looking at. Excellent! This means that I'm one step closer
to having a viable solution!
I also discovered the [xcb_util](https://xcb.freedesktop.org/XcbUtil/)
library of helpful utilities has a function called
`xcb_aux_get_screen` for getting the root screen because everyone was
weirded out by that list traversal algorithm.
The source code to [xedgewarp](https://github.com/Airblader/xedgewarp)
was invaluable in revealing these secrets to me.
So far this little toy compiles down to only 35KB, and that includes
using `std::cout` and `std::vector`! I wonder how big the Rust
version will be. Yeah, yeah, I know, it cheats by having lots of
itself hidden in the kernel.
Next up: Actually knowing what the rotation status is.
monstrous things allocated in memory that you just have to "know" are
of a certain structure. In this case, we used `xcb_screen_next` to
say that we want the first (and all) screens attached to our current
X11 session. And we used
`xcb_setup_roots_iterator(xcb_get_setup(connection))` to initialize
our iterator to our connection object in local memory.
Other things we've learned along the way: the file description that
represents our connection can be a TCP/IP socket or a Unix Domain
socket (a filesystem socket, named or not), and the only way to know
which is to find if there's a hostname before the colon ':' in the
display name of the server. Not sure how that's going to work.
Also, found a really good reference: [Basic Graphics Tutorial with
XCB](https://www.x.org/releases/X11R7.6/doc/libxcb/tutorial/index.html).
It doesn't cover our specific use-case, but it's worth looking into.
Elf M. Sternberg