Hi, I was asked to give an overview of what Wayland-related stuff is on
the radar for the near future, so here we go:
crosvm security contexts
------------------------
The Wayland security context protocol[1] is how the compositor will know
which VM is responsible for which Wayland client, which will allow us to
make per-VM policy decisions. crosvm is the part of Spectrum's stack
that can give this information to the compositor, so we need it to
implement this protocol.
Puck previously created such an implementation[2], but it was for an
earlier draft of the protocol. It needs to be updated and submitted
upstream.
[1]: https://wayland.app/protocols/security-context-v1
[2]: https://puck.moe/git/crosvm/commit/?h=wayland-security-context&id=dbdba0bf6…
Customisable COSMIC
-------------------
I plan to use the COSMIC[3] the compositor for Spectrum. As far as I
know, it's the only serious Rust Wayland compositor, and it looks like
it's targeting a good balance between wide usability and
configurability.
But Spectrum's compositor has some requirements that wouldn't make sense
for upstream COSMIC. For example, we'll want to implement some sort of
clipboard permissions system, and we're likely to want to do some sort
of custom window decorations, maybe like Qubes does. Maintaining a fork
of cosmic-comp wouldn't be sustainable, so what we need is some way to
customize the compositor's behaviour without needing out-of-tree
patches.
The way I imagine this working is having cosmic-comp export a library
that allows inserting hooks for things we might want to customise. Then
we could write a very small program that used that library, set up
whatever hooks we wanted, and then just told the library to run the
compositor.
Quick sketch:
use cosmic_comp::{Hook, add_hook, run};
fn main() {
add_hook(Hook::Paste, |ctx| {
...
});
run();
}
I've talked to upstream about this, and they're on board with the
general concept. Doing it this way would mean the only code we'd have
to maintain would be Spectrum-specific, and we wouldn't have to worry
about running into merge conflicts forever.
Once this is done, we can do things like implement security contexts in
cosmic-comp. It wouldn't make much sense to do that first, because it
wouldn't be used anywhere.
[3]: https://github.com/pop-os/cosmic-epoch#cosmic-comp
COSMIC title bars for wayland-proxy-virtwl Xwayland clients
-----------------------------------------------------------
wayland-proxy-virtwl[4] is the program used to relay Wayland connections
from the guest to the host. It implements its own unpriveleged X11
forwarding. (Normal Xwayland requires the compositor give special
priveleges not given to normal Wayland clients.) For some reason,
cosmic-comp does not draw title bars for these clients. It's unclear so
far whether this is a cosmic-comp program or a wayland-proxy-virtwl
problem.
[4]: https://github.com/talex5/wayland-proxy-virtwl
