Isaac Freund's Bloghttps://isaacfreund.com/blog/feed.xmlIsaac Freundmail@isaacfreund.com2022-05-23T00:00:00ZMay 2022 Status Updatehttps://isaacfreund.com/blog/2022-05/2022-05-23T00:00:00Z2022-05-23T00:00:00ZWelcome back to my blog, it’s been a while. Over the past few months I’ve been busier with other aspects of my life than expected, hence the lack of status updates. Despite that, I’ve made progress on various fronts.
Waylock 0.4.0 and Rewrite Yesterday I finally released waylock 0.4.0 which has been rewritten in Zig. It now uses the ext-session-lock-v1 protocol, which I worked on earlier this year and discussed in my February 2022 update.<p>Welcome back to my blog, it’s been a while.
Over the past few months I’ve been busier with other aspects of my life than expected, hence the lack of status updates.
Despite that, I’ve made progress on various fronts.</p>
<h2 id="waylock-040-and-rewrite">Waylock 0.4.0 and Rewrite</h2>
<p>Yesterday I finally released <a href="https://github.com/ifreund/waylock/releases/tag/v0.4.0">waylock 0.4.0</a> which has been rewritten in <a href="https://ziglang.org/">Zig</a>.
It now uses the <a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/131">ext-session-lock-v1</a> protocol,
which I worked on earlier this year and discussed in my <a href="https://isaacfreund.com/blog/2022-02/">February 2022</a> update.
Unfortunately, <a href="https://github.com/riverwm/river">river</a> itself does not yet support this protocol.
The work is already done and there’s been a <a href="https://github.com/riverwm/river/pull/497">pull request</a> implementing it open for quite some time,
the only thing I’m waiting on is a wlroots release including the session lock implementation.
I intend to spend some more time working on upstream wlroots to help tie up various loose ends before 0.16.0 and further develop the scene graph API.</p>
<p>Rewriting waylock from Rust into Zig has made me think once again about the different trade-offs made by the two languages and their ecosystems.
Looking at the Rust code I wrote several years ago I am rather appalled by how many dependencies it has.
If I’ve managed to use the cargo tooling correctly, I count 48 crates that waylock 0.3.5 depends on in addition to linking the system libxkbcommon and PAM libraries.
That is a <em>lot</em> of code running inside my application that I never read let alone seriously audited.</p>
<p>To compare, waylock 0.4.0 depends only on libwayland, libxkbcommon, and PAM as well as thin Zig bindings I have written to make their APIs a bit more type safe.</p>
<p>This is also reflected in the binary size of waylock 0.3.5 vs 0.4.0.
A stripped release build of the Rust version weighs in at 1.7MiB or, if the native Rust Wayland implementation is replaced by linking libwayland, 1.6MiB.
A stripped “release-safe” build of the Zig version with all runtime safety checks and assertions enabled is just 69KiB.</p>
<p>If this makes you wonder what all that extra code in the Rust version was doing, waylock 0.3.5 did have a few more features than 0.4.0 such as reading a config file.
However, even after removing the config file feature out of curiosity, the Rust version was still 1.5MiB.</p>
<p>The only real answer I have to this question is that the Rust version and its dependencies do a lot of abstraction,
and that abstractions are seldom “zero cost” in practice despite what people may tell you.</p>
<h2 id="zig-wayland-improvements">zig-wayland Improvements</h2>
<p>Rewriting waylock in Zig also led me to rexamine some aspects of <a href="https://github.com/ifreund/zig-wayland">zig-wayland</a>,
particularly regarding its usage in client applications.
The scanner (which generates zig bindings from xml protocol specifications) now requires the user to explicitly request
code generation for each global Wayland interface used.
For example, the application must now call e.g.</p>
<pre tabindex="0"><code>scanner.generate("wl_compositor", 4);
</code></pre><p>as part of its build process,
passing the global interface name and the version for which to generate code.
In this example the wl_surface.offset request would not be generated as it is only available since version 5.</p>
<p>(If you’re not familiar with Wayland, wl_surface is created through wl_compositor and inherits its version,
see the Wayland <a href="https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Versioning">docs on protocol versioning</a> for more information.)</p>
<p>This solves the outstanding forward compatibility issue and allows building against newer system Wayland protocol versions than the application supports.</p>
<p>The knowledge of what maximum version a client application supports at compile time allows us to make another improvement as well.
One of the most common Wayland client bugs I’ve seen in clients using libwayland is passing the interface version received from the server
in the wl_registry.global event straight to wl_registry_bind().
A forwards compatible client must check the version advertised by the server against the maximum version the client supports, otherwise
the client will be terminated when the server sends events unknown to the client.</p>
<p>This is a particularly nasty bug because everything will work fine until your software is around long enough for Wayland protocols to evolve.
For example, Chromium <a href="https://chromium.googlesource.com/chromium/src/+/dd4c3ddadbb9869f59cee201a38e9ca3b9154f4d">recently fixed</a> this bug.
I’ve also written this bug a few times myself, including in previous Rust versions of waylock.</p>
<p>That’s why it’s pretty cool that zig-wayland now makes this bug impossible.
Since we know the maximum version the client supports at build time, it’s trivial to insert the required version check into the generated code
for zig-wayland’s wl_registry_bind() equivalent as a safeguard.</p>
<h2 id="river-progress">River Progress</h2>
<p>River has also gained some nice new features recently:</p>
<p>Automatic cursor hiding after a timeout or when typing was contributed by Duncan Overbruck.
On moving the cursor after it has been hidden it will be shown again.</p>
<p>Initial support for the idle-inhibit protocol was contributed by dfangx.
No longer shall swayidle put your monitor to sleep while watching a movie in mpv!</p>
<p>Mapping of lid and tablet switches was contributed by Peter Kaplan.
Now you can have a command run when you close the lid of your laptop!</p>
<p>Peter Kaplan also contributed a very nice feature for people switching between multiple keyboard layouts: layout independent mappings.
The riverctl map command has gained a -layout option taking an index into the list of layouts set with XKB_DEFAULT_LAYOUT.
If passed, keyboard input will always be interpreted using the given layout, ignoring the currently active xkb layout.</p>
<p>Note that these features are not yet available in a released version of river, only on the git master branch.
I plan to release river 0.2.0 shortly after wlroots 0.16.0 is released.</p>
<p>Thanks for reading and till next time!</p>
February 2022 Status Updatehttps://isaacfreund.com/blog/2022-02/2022-02-11T00:00:00Z2022-02-11T00:00:00ZHello again! It’s been nearly a month and a half since my last status update. Since I hope to fall into a monthly rhythm with these this is a decent start, look for the next one around the middle of March. I’ve also gotten a proper Atom Feed set up for this blog now for those of you using feed readers of some kind.
I spent a fair bit of time over the past month an a half working on a better screenlocking protocol for Wayland.<p>Hello again!
It’s been nearly a month and a half since my last status update.
Since I hope to fall into a monthly rhythm with these this is a decent start, look for the next one around the middle of March.
I’ve also gotten a proper <a href="https://isaacfreund.com/blog/feed.xml">Atom Feed</a> set up for this blog now for those of you using feed readers of some kind.</p>
<p>I spent a fair bit of time over the past month an a half working on a better screenlocking protocol for Wayland.
This resulted in the ext-session-lock-v1 protocol which was merged into the upstream <a href="https://gitlab.freedesktop.org/wayland/wayland-protocols/">wayland-protocols</a> repository three weeks ago.
This marks the first upstream Wayland protocol I have written and the first protocol in the ext- namespace to be accepted into wayland-protocols!</p>
<p>The ext-session-lock-v1 protocol makes it possible for lockscreens implemented outside of the Wayland compositor to be far more secure, compared to the status quo wlr-input-inhibitor-v1 plus wlr-layer-shell-v1 solution that has been used by <a href="https://github.com/swaywm/swaylock">swaylock</a> and <a href="https://github.com/ifreund/waylock">waylock</a> thus far.
Currently if, for example, swaylock crashes while the session is locked then the session will no longer be locked.
With ext-session-lock-v1, the session does not unlock if the client crashes.
Furthermore, hotplugging outputs is inherently racy with the current solution which means that a few frames of the unlocked session may be visible if a monitor is plugged in while the session is locked.
Again, with ext-session-lock-v1 this problem is solved.</p>
<p>Many thanks to <a href="https://emersion.fr">Simon Ser</a> for the excellent code reviews of the protocol and <a href="https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3414">wlroots implementation</a>, as well as for <a href="https://github.com/swaywm/swaylock/pull/219">updating swaylock</a> to use ext-session-lock-v1.
I’ve <a href="https://github.com/riverwm/river/pull/497">implemented</a> ext-session-lock-v1 for river but am waiting for the 0.16.0 wlroots release to merge it as river tracks the latest wlroots release not the master branch.
I’ve also started rewriting <a href="https://github.com/ifreund/waylock">waylock</a> from the ground up in Zig with a much higher focus on security and benefiting from the experience I’ve gained over the past 2 years of doing this stuff.
Until that work is complete I recommend using swaylock instead.</p>
<p>The goal of this work is to ensure, to the best of my ability, that <a href="https://www.jwz.org/">jwz</a> doesn’t have to say <a href="https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/">“I told you so”</a> about screen locking on my Wayland compositor.
Once the security problem has been satisfactorily solved I want to explore making fun graphics possible without compromising security, but that may take me a long time to get around to.</p>
<p>I <a href="https://github.com/riverwm/river/releases/tag/v0.1.3">released</a> river 0.1.3 about a week ago.
It includes quite a few bug fixes, so if you’re not yet using river 0.1.3 and wlroots 0.15.1 I’d highly recommend upgrading.
I also decided to change river’s license from GPL-3.0-or-later to GPL-3.0-only with this release,
primarily because I decided that I do not feel comfortable licensing software under a hypothetical future license version which is outside my control.
What if I disagree with the changes made?
I’m happy with locking in on version 3 of the GPL for river as there’s no real need to worry about the compatibility benefits of the “or later” clause as river is not a library.</p>
<p>That’s all for now, see you all in March!</p>
2021 Year's End Status Updatehttps://isaacfreund.com/blog/2021-years-end/2022-01-01T00:00:00Z2022-01-01T00:00:00ZHello all! This is my first ever status update so I’ve ambitiously decided to cover all of 2021. In the future I intend to write these updates on a monthly basis and provide a bit more detail. Since so much has happened in the past year I’ll be leaving out a lot, but here are some of the highlights.
In January I spent most of my time on river, fixing bugs and implementing an experimental river-options protocol.<p>Hello all!
This is my first ever status update so I’ve ambitiously decided to cover all of 2021.
In the future I intend to write these updates on a monthly basis and provide a bit more detail.
Since so much has happened in the past year I’ll be leaving out a lot, but here are some of the highlights.</p>
<p>In January I spent most of my time on <a href="https://github.com/riverwm/river">river</a>,
fixing bugs and implementing an experimental <a href="https://github.com/riverwm/river/pull/202">river-options protocol</a>.</p>
<p><a href="https://archive.fosdem.org/2021/">FOSDEM 2021</a> took place online during first weekend of February and
I gave a <a href="https://archive.fosdem.org/2021/schedule/event/zig_wayland/">talk</a> on my type safe <a href="https://ziglang.org">Zig</a> bindings for wlroots/libwayland.
Around the same time I got sucked into Andrew Kelley’s work applying data oriented design principles to Zig’s Abstract Syntax Tree.
I collaborated with him on the data structure that became <a href="https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-in-userland-40m0">std.MultiArrayList</a>
and contributed a significant amount of code to his <a href="https://github.com/ziglang/zig/pull/7920">PR branch</a>.
Andrew gave a <a href="https://media.handmade-seattle.com/practical-data-oriented-design/">talk</a> on this subject at Handmade Seattle later on in November which I highly recommend checking out if you haven’t seen it yet.</p>
<p>In March I joined the team working on <a href="https://www.tigerbeetle.com">TigerBeetle</a> and got paid to write Zig code for the first time.
I also contributed to Andrew’s further application of data oriented design to the <a href="https://github.com/ziglang/zig/pull/8266">ZIR memory layout</a>.</p>
<p>In April my stalwart collaborator <a href="https://leon_plickat.srht.site">Leon Plickat</a> and I finally got the <a href="https://github.com/riverwm/river/pull/112">river-layout protocol</a> merged to master branch.
We’d been discussing and working on this off and on for ~6 months at that point so it was really great to get it merged and start daily driving it.
As is normal with such large changes, there were still some rough edges to be smoothed out and I <a href="https://github.com/riverwm/river/pull/274">bumped the protocol to version 2 and removed the river-options protocol</a> shortly afterwards.</p>
<p>One of the critical missing features for river at this point in time was damage tracking support to improve performance and save battery life.
To remedy this I <a href="https://github.com/riverwm/river/pull/296">implemented</a> basic yes/no damage tracking in May.</p>
<p><a href="https://ziglang.org/download/0.8.0/release-notes.html">Zig 0.8.0</a> was released in the first week of June, which included several improvements I made to Zig’s handling of linking libc.
These improvements directly affected users building river, solving a few long-standing issues on that front.
Around this time I also started to think about a first river release and resumed my effort to <a href="https://github.com/void-linux/void-packages/pull/29288">properly package zig software for void linux</a>.
This lead to a series of zig patches to allow for cross compilation while linking system libraries and integration into void linux’s build system.</p>
<p>In July I focused on stabilizing and simplifying river’s behavior, aiming for consistency and predictability.
As part of this, I <a href="https://github.com/riverwm/river/pull/359">further simplified our layout protocol</a> and cleaned up all of river’s user-facing interfaces.
The goal was to get a first release out the door, but unfortunately exams got in the way.</p>
<p>Throughout August and September I had relatively little time for my open source work as I was busy with exams at my university.
I did however manage to keep up with bug reports from river’s small but steadily growing number of users fairly well.
In retrospect, it was nice to allow bug reports to trickle in for another couple months before tagging the first release as the end result was much more polished.</p>
<p>I ended up changing domains for my personal website and email from ifreund.xyz to isaacfreund.com after reading <a href="https://www.spotvirtual.com/blog/the-perils-of-an-xyz-domain/">this post</a> in October.
It makes me sad that this is the way things are, but I’d rather die on a different hill.
I set up <a href="https://github.com/sponsors/ifreund">GitHub Sponsors</a> and <a href="https://liberapay.com/ifreund">Liberapay</a> around this time and was pleasantly surprised to immediately see some support.
Thank you to all my current sponsors, you are helping make my open source work sustainable in the long term!</p>
<p>On the river front, I spent October fixing every bug I could and finally tagged the <a href="https://github.com/riverwm/river/releases/tag/v0.1.0">river 0.1.0 release</a> on November 2nd.
If you haven’t yet seen my <a href="https://isaacfreund.com/blog/river-intro">blog post introducing river</a> you may want to check that out.
Later in November my focus shifted to helping push the new wlroots scene graph API forward, <a href="https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3250">getting tinywl using it</a>
as well as <a href="https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3398">other</a> <a href="https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3403">improvements</a>.</p>
<p>This wlroots work carried on into December, when <a href="https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.15.0">wlroots 0.15.0</a> was released.
As it so happened, <a href="https://ziglang.org/download/0.9.0/release-notes.html">Zig 0.9.0</a> was released only a few days later.
Thus, <a href="https://github.com/riverwm/river/releases/tag/v0.1.1">river 0.1.1</a> and <a href="https://github.com/riverwm/river/releases/tag/v0.1.2">river 0.1.2</a> were released in quick succession,
fixing several bugs and updating the wlroots and Zig version requirements.</p>
<p>I also ended up starting and finishing a tiny new project in December, <a href="https://github.com/ifreund/dumb_runtime_dir">dumb_runtime_dir</a>,
to replace my older, more complex <a href="https://github.com/ifreund/rundird">rundird</a> project.
This is useful on systems that do not run logind, opting for a simpler alternative such as <a href="https://sr.ht/~kennylevinsen/seatd">seatd</a> instead.</p>
<p>2021 was an action packed year for me, I’m very happy looking back on the progress I’ve made on river and the surrounding open source ecosystem.
Here’s to another year of work towards building my ideal linux graphical environment in 2022!</p>
Introducing River, a Dynamic Tiling Wayland Compositorhttps://isaacfreund.com/blog/river-intro/2021-11-03T00:00:00Z2021-11-03T00:00:00ZIn the spring of 2020 I found myself hooked on Wayland thanks to sway but increasingly frustrated with the i3 style window management sway implements. I tried several of the other more mature Wayland compositors including hikari and Wayfire but didn’t enjoy them any more than sway. I wanted dynamic tiling window management similar to dwm but on Wayland and without dwm’s configuration through patching the source code approach.
As I had a newfound abundance of free time at home in front of my computer thanks to the global pandemic that was ramping up that spring, I decided to write my own Wayland compositor.<p>In the spring of 2020 I found myself hooked on Wayland thanks to
<a href="https://swaywm.org/">sway</a> but increasingly frustrated with the
<a href="https://i3wm.org/">i3</a> style window management sway implements.
I tried several of the other more mature Wayland compositors
including <a href="https://hub.darcs.net/raichoo/hikari">hikari</a> and
<a href="https://wayfire.org">Wayfire</a> but didn’t enjoy them any more
than sway. I wanted dynamic tiling window management similar to
<a href="https://dwm.suckless.org/">dwm</a> but on Wayland and without dwm’s configuration
through patching the source code approach.</p>
<p>As I had a newfound abundance of free time at home in front of
my computer thanks to the global pandemic that was ramping up
that spring, I decided to write my own Wayland compositor. Thus,
<a href="https://github.com/riverwm/river">river</a> was born.</p>
<h2 id="features">Features</h2>
<p>The core guiding principle in river’s design is that its behavior should
be predictable. This means keeping things as simple as possible, reducing
implicit state the user must keep in their head while using river.</p>
<p>River’s window management is based on a linear stack of windows much like
dwm. These windows are arranged by a separate program called a layout
generator. Users are encouraged to write and share their own layout
generators, they are simply Wayland clients which implement a custom
river-layout-v3 protocol. You can find links to several nice ones on this
<a href="https://github.com/riverwm/river/wiki/Community-Layouts">wiki page</a>. River
also ships with a layout generator, rivertile, that provides a few simple
layouts for those who don’t need anything custom or fancy.</p>
<p>Instead of traditional workspaces, river supports tags. Each window may be
assigned one or more tags and multiple tags may be displayed at once. Again,
this behavior is strongly influenced by dwm.</p>
<p>All configuration and control of river happens at runtime through the riverctl
tool. It can be used to create keybindings, move focus between windows,
set the border color, etc. River doesn’t have any traditional configuration
file, instead it runs an arbitrary executable on startup which is generally
a shell script invoking riverctl to setup the user’s desired configuration.</p>
<h2 id="river-010">River 0.1.0</h2>
<p>I’ve been using river as my daily driver for well over a year now, and am
happy to announce the first release today, river 0.1.0. In recent months
there has been little churn in river’s codebase and it is currently quite
stable and bug free. Because of this, people seem to have started using it.
As I plan to cause a lot more churn on the master branch in the near future
which will inevitably create new bugs and break people’s configuration,
this is the perfect time for a release.</p>
<p>I’d like to thank everyone who has contributed code, documentation
and bug reports to river. In particular, thanks to <a href="https://leon_plickat.srht.site/">Leon Henrik
Plickat</a> for his consistent, high quality
collaboration since the early days of the project. Without all of you this
release would not have been possible.</p>
<h2 id="the-future-of-river">The Future of River</h2>
<p>Although I consider river useful enough today to tag a first release, it
is not yet complete. The core functionality and standard use cases are well
supported but river is not yet nearly as flexible as I would like it to be.
I have several ideas that I plan to try out to improve river’s flexibility
and ease of customization, but this will take time. For this reason,
users should expect widely breaking changes to how river is configured
and controlled before we approach a stable 1.0 release. Fear not though,
the core functionality and spirit of river are here to stay!</p>
<p>If you’d like to contribute financially to my work on river, please consider
sponsoring me on <a href="https://github.com/sponsors/ifreund">GitHub Sponsors</a>
or <a href="https://liberapay.com/ifreund">Liberapay</a>. To those already donating,
thank you so much for your support!</p>