colby@colbyt.com writes: > Not sure why this email didn't send but trying again from my regular address! -- thanks for all the great updates - so speedy! > > On Saturday, July 11th, 2026 at 1:32 AM, CCT wrote: > >> Thank you for posting this. Since our last conversation, I’ve been further prototyping a COSMIC-based downstream of Spectrum for PolymerOS, so there is useful overlap here. >> PolymerOS currently replaces the standard panel and dock with custom surfaces and carries several small cosmic-comp changes for trust decorations, presence attestation, and compositor readiness. I’ve attached screenshots from two stages of the prototype. >> >> A few notes and questions: >> >> - Immutable configuration: COSMIC’s configuration code attempts to write defaults when loading. Because our /etc/xdg is immutable, we currently seed a writable runtime copy from an administrator-owned immutable baseline. Is there an intended COSMIC location or pattern for this? From what I've saw in my work with it, COSMIC stuff only *requires* an empty configuration directory to exist, e.g. etc/xdg/cosmic/com.system76.CosmicComp/v1, so I just created some empty directories in the Makefile. None of the files within need to exist, and it doesn't seem to mind if it can't write those files when it's running. I'd be interested to hear if you see otherwise. >> - Socket and readiness: Our separately supervised services need a stable Wayland socket path and an explicit signal that the compositor is ready. Is the intended long-term API an absolute socket path supplied to cosmic-comp, potentially followed by service-manager socket activation? Would COSMIC accept a service-manager-neutral readiness signal, such as writing once to an inherited file descriptor, so s6-based systems do not need a downstream patch? This is also already addressed in my series. s6 now comes with a program that translates systemd readiness notification into s6 readiness notification, so we use that. It only required a small bug fix that has now been accepted by s6 upstream. As for the Wayland socket, I aim to get cosmic-comp upstream to either support creating the Wayland socket on a given absolute path (which is what the series currently does), or to support being started with a listening Wayland socket file descriptor. My first PR for the former has already been accepted by wayland-rs, but further progress requires a release of those libraries so Smithay can use that functionality. >> - QEMU and VNC: The desktop is usable with software rendering, without making virgl mandatory. We would prefer both software and accelerated modes to remain supported. We normally use hardware acceleration, while software rendering is valuable for testing compositor security decorations and for headless builders. I think it should be fine as long as you have Mesa's software rendering drivers available on your host. (hardware.graphics.enable on NixOS — despite the name it's not necessary to have any actual graphics hardware for that to work, the option just needs to be enabled so the drivers are installed.) If that doesn't work, let me know and we can see what can be done.