I spread the coding effort needed for protocols and 3rd party software compatibility out over longer periods of time because the underlying work is mundane, tedious and very very repetitive. The QEmu backend is by far the more interesting and potent one – in terms of which Arcan capabilities that can be bridged, but it is also more experimental with frequent failures – it’s not for everyone.

While I was working on the Wayland Server parts, it became clear to me that there are quite a few technical details involved which makes the balance between time spent, progression and possible gains quite unfavorable – though I won’t elaborate on that now. (There’s a big page on the wiki tracking status, limitations and my own, possibly flawed, notes and observations)

Therefore, I came to the conclusion that I needed (for the time being) another model and feature-set for compatibility with X, than what is currently offered by XWayland.

Gulp, that means I have to deal with the Xorg codebase,  hmm what to do. 

Digging around in there, I found one dusty part that felt out of place, but in a somewhat good way: ‘Kdrive’. At first glance, this seemed like it would lessen some of the boilerplate coding needed to stitch together a working minimal Xserver, compared to a full DDX implementation.

Added bonus: less Xorg exposure to rinse off in the shower later (however, it still requires a prescription shampoo, body scrub and medevac team on standby).

Results: Github:XArcan

Before going into more details and technical jibberjabber, here’s a demo video of it running in some weird window manager, along with early signs of Wayland life.

(No, the Arcan scripts for this particular window manager are not public, yet).

The biggest motivation hurdle was, as it almost always is, digging through autotools-hell and patching myself into the build system. At least it wasn’t a custom configure shell script (QEmu) or both automake and cmake (SDL2).

Desired features:

• Containment – I didn’t want to have a 1:1 ratio between an X client window and a logical window in the Arcan scripts I was using for window management (XWayland model). I would much rather imitate a dumb ‘display’ confined to one logical window in Arcan. That approach blends more easily with both the tiling window management scheme and the one used in the video.
• Compartmentation – To be able to spin up multiple Xservers and control which clients belong to which group in order to separate between privileges and to tag with visual privilege-level markers so that I know which ones that currently gets to snoop on my keyboard input and therefore should get the ‘special’ credit card numbers, gmail accounts and phone-numbers. My honeypots, they hunger.
• Clipboard – The clipboard model in Arcan is quite different from anything else, and is practically similar to how screen sharing is implemented. The model does allow for opt-in bidirectional global clipboard sharing and the Durden set of scripts will get a feature that can be toggled to set a client as global clipboard monitor and auto-promotion of new clipboard entries to global state. This should be able to bridge old xsel- scripts and similar tools.
• Gamma Controls – There is bidirectional gamma table synchronisation between Arcan and its clients, though no scripts around that actually make use of them (that I know of). In Durden, this will be added as an advanced client video toggle to allow it to act as a gamma controller for the monitor it is currently bound to. When activated on an Xarcan window, things like redshift-xrandr should start to work.
• Retain Input Tools – (your hotkey manager) The problem is comparable to gamma and clipboard, though this might take some more aggressive patches to the Xserver in order to find the right hooks. The Input- multicast group and global receiver feature hidden in Durden can be used to this effect, but something better is probably needed.
• Controlled Screen Recording – With the way output segments work in the arcan-shmif API, I can extract and manipulate the subset of data sources that are being forwarded to an external ‘screen’ recorder. There is fundamentally no difference between a video camera, youtube video feed, or periodic screen snapshots in this regard even if they potentially live in different colour spaces. It seems possible to map a received output segment to the hooks used by X clients to record screen content, though you don’t reach 4k@60fps this way.

I also, of course, need some controls to be able to configure the compartmentation to decide if the very very scary GPU access should be allowed to an untrusted client or not.

Status and Limitations:

I haven’t spent that many hours on it about 1:1 between arcan-wayland and xarcan, but progression is quite decent – and it’s definitely usable.

• Containment / Compartmentation – there by design
• Gamma Controls – not yet
• Clipboard – soon, the X server does not provide easy access to selection buffers etc. Need to fork/popen into separate clipboard process.
• Input Tools – injection: not yet (internationalization input is doable through some clipboard hacks), broadcast: yes

Some other limitations:

• You really want to run a normal window manager with the X server, though I consider that a feature. For the other use cases, there will eventually be XWayland support too.
• Glamor and GLX are working in a primitive state, there will be glitches.
• 1 Display:1 Screen (so no stretched multiscreen) – spin up more servers on more displays, if needed. This constraint makes synchronisation and performance tricks easier and the codebase less painful.
• It’s still X, synchronisation between WM, Xorg, Displays and clients will be bad forever.
• No way of reliably pairing audio source to a window, so something more hack:y is needed for that. Got PA in the sniper scope though, looks like he’s grazing at the moment – filthy beast.
• Keyboard Layout management synchronisation cannot really be fixed (I’m not building a dynamic translator between the internal keyboard layout state and XKB unless I restock with considerable amounts of alcohol and got a good suicide hotline on speed dial).

I also got a crazy idea or two in the process that’ll showcase some obscure Durden features, but that’s for another time.