Status update, June 2018
A lot happened this month. I’m usually used to focus on a single project for extended amounts of time, but this month was different. While continuing to frequently review and send patches to my “big projects” (such as wlroots), I also started a bunch of little side projects. I’m going to try to sum up all of this in this post, I feel like stepping back could help driving me forward next month.
First, what’s up with wlroots? I’ve been working on a new type,
wlr_buffer
.
It offloads some complexity off of wlr_surface
, fixes some bugs that caused
glitches and enables new use-cases. I won’t be able to go into details, because
buffer and surface management on Wayland is complicated: you have different
buffer types (shared memory in RAM vs. zero-copy buffers in the GPU) which
have different semantics (some need to be uploaded to the GPU, with damage
tracking support), and on top of that you also need to handle synchronization
(which also depends on the buffer type) and cleanup (when the buffer is
removed). Anyway, wlr_buffer
allows for atomic layout and animations when
closing windows (used by Wayfire). I’m still
continuing this work and improving the wlr_surface
API.
Another Big Thing is the export-dmabuf
protocol. We’ve been
working with atomnuker, who has a ffmpeg background, to design an efficient
protocol to capture your screen. It’s using DMA-BUFs under the hood, which means
that clients can directly read the screen contents without needing to copy
anything. This will be useful for screen recording and screencasting, we already
have a working — even if somewhat arcane — screen recorder (which is able to use
hardware-accelerated video encoding!). I’m still working on
another protocol to cover the cases where export-dmabuf
either
doesn’t work or is overkill.
I’ve also sent another iteration of the xdg-decoration
protocol for inclusion in wayland-protocols. This protocol allows the compositor
and clients to negociate server-side decorations for better system integration.
Getting a protocol right takes an insane amount of time, even for a very simple
one like this one!
Outside of the sway world, stuff happened too. vil has been working on mako, my Wayland notification daemon, to add criteria support. This means you can now style differently notifications depending on the app they come from, their urgency, or even their category.
A new contributor, freemountain, has started to work on my Twitter → Mastodon bridge project, emuarius. The goal of this project is to be able to follow Twitter accounts from Mastodon, and to be able to interact with them seamlessly. The “follow Twitter users from Mastodon” part isn’t too far from working, but still has bugs. It’s also using the legacy OStatus standard, we’ll eventually need to migrate to ActivityPub.
Now to the new projects. I’ve started mrsh, a new shell. I want to build a simple and minimal library for POSIX shells. Existing projects, even dash, aren’t cut for this job. My workflow so far has been to get a subset of each feature working, to prove that the approach is viable, and organically grow the feature set when the full chain is operational. So far I’ve got a subset of the parser/AST and a subset of the command handling working. My next focus will be job control and variable expansion. I’m not yet happy with the parser, I’ll try to make it nicer (the POSIX standard doesn’t help with that).
Another project I’ve been working on is emailthreads. My friend sircmpwn is
working on sr.ht, an open-source collection of services to manage
software projects. We’ve been discussing about the best way to submit patches
and review them. We’ve been wondering if it’d be possible to design an
easy-to-use interface for git-send-email
. emailthreads’ job is to parse
replies to emailed patches into a tree of comments to allow them to be displayed
in a web interface. To my own disappointment, it has been working
pretty well so far on real-world test cases. I
still think it won’t ever be perfect because there are too many edge cases, but
I’m looking forward to testing it on more discussions!
Last, I’ve bootstrapped wleird, a collection of weird Wayland clients that use obscure Wayland features in counter-intuitive or uncommon ways. Test clients are lacking when implementing the compositor side of Wayland protocols. There are only two test clients so far, one using subsurfaces and the other buffer positions, but they both don’t work (yet) on wlroots. We also have ideas for more weird clients!
What a busy month! And I’ve not even mentionned the few patches I’ve pushed or reviewed for matcha, slurp, grim and go-imap. Anyway, I’m looking forward to even more awesome stuff next month. If you’re interested in any of these projects, make sure to drop me an email or ping me on IRC!