Re: Cosmic Progress

Re: Cosmic Progress

[colby]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

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 <cct@protonmail.com> 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?
>
> - 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?
>
> - 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.

[-- Attachment #2: Type: text/html, Size: 4698 bytes --]

Re: Cosmic Progress

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 3234 bytes --]

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 <cct@protonmail.com> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Cosmic Progress

[colbyt]

Following up on the read-only config question from earlier in this
thread: you were right — my July 7 message conflated two things.

cosmic-config never requires XDG_CONFIG_HOME to be writable. The only write in Config::new is a create_dir_all on $XDG_CONFIG_HOME/cosmic/<AppID>/v<N>, which is a no-op when the
directory already exists. With the empty per-component directories
pre-seeded on a read-only mount, Config::new succeeds, reads behave
identically to a writable setup, and writes fail with a plain Err
rather than a panic. The panic we saw was create_dir_all returning
EROFS when those directories were *absent*, unwrapped by the caller
(cosmic-comp 1.2.0, src/config/mod.rs:172).

Verified with a minimal harness against cosmic-config at the libcosmic rev cosmic-comp 1.2.0 pins (0bb006c5) and against current master (dc1cf9f0) — same behavior on both, with the read-only mount
both as a bwrap ro-bind (real EROFS) and as chmod 555.

Two details from that may be useful for the empty-dir seeding in your cosmic-comp series:

1. Seeding a bare cosmic/ isn't enough — the full
   cosmic/<AppID>/v<N> path has to exist for every component/version pair the session constructs, or that component's Config::new fails the same way.
2. Config::new_state does the identical create_dir_all under
   XDG_STATE_HOME, so state directories want the same seeding as
   config.