Revient sur 3d01a219. La feature "tokio" de libcosmic-yoda activait
zbus?/tokio, ce qui imposait un Handle::current() ambiant alors que la
boucle de cosmic-comp n'est pas async ; d'ou le garde de runtime dans
main(). La feature est retiree de la dependance libcosmic, zbus n'a donc
plus besoin de reacteur Tokio et le garde n'a plus lieu d'etre.
Cargo.lock perd tokio et toute la chaine qui venait avec la feature :
ashpd, rfd, atspi, accesskit_unix, zbus_xml, tokio-stream.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
32 commits amont, aucun conflit de code : seul le lockfile divergeait,
il est regenere. Les 9 commits yoda sont preserves, dont le patch des
onglets de piles suivant WindowControlsPosition.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
populate_modes() now selects the mode with the highest refresh rate at
the preferred (native) resolution instead of blindly using the EDID
PREFERRED flag. This ensures high-refresh panels (120 Hz, 144 Hz, …)
are used out-of-the-box, including in the greeter session.
Also fix libcosmic → libcosmic-yoda package reference.
Move logind-zbus to a dedicated 'logind' feature that is independent
of the 'systemd' feature. This allows non-systemd users (e.g., OpenRC
with elogind) to access lid switch inhibition and lid status detection
without requiring the full systemd stack.
The 'systemd' feature now depends on 'logind' to maintain backward
compatibility, so existing users are unaffected.
Feature configuration:
- default: ["systemd"]
- logind: ["logind-zbus"]
- systemd: ["libsystemd", "logind", "tracing-journald"]
Resolves#2473
Coding-Agent: OpenCode
Model: claude-sonnet-4-5
A fix for the issue reported in
https://github.com/pop-os/cosmic-comp/pull/2450.
Using `block_on` in some places for zbus calls is fine (that's what
zbus's blocking API does; it has its own executor for background tasks),
but this is problematic with `async_once_cell`. If we also use that in
the calloop async executor.
I think ideally we should avoid blocking the main thread on any async
tasks, but for now we can just block in initialization here.
We should avoid creating more than one session connection or more than
one system connection. We should also ideally avoid blocking the main
thread.
For now this still uses blocking in a couple places, but wrapping async
code (which is how `zbus::blocking` is implemented anyway).
This moves the `NameOwners` creation out of `A11yKeyboardMonitorState`,
so it can be shared with other things. We will likely want that for
https://github.com/pop-os/cosmic-comp/pull/465 to define a secured
protocol to pass an fd to the portal, and potentially any other
sensitive DBus protocols implemented by the compositor.
Fixes#2081
This also reverts commit 0f7e53b, because the upstream commit (2e00119)
that introduced this thing was reverted
(https://github.com/Smithay/smithay/pull/1941).
There was also change in the cursor_capture_constraints signature in
smithay 7d992793f.
If we want to use the `org.freedesktop.a11y.KeyboardMonitor` protocol on
Pop!_OS, there is no need to support the Cosmic-specific protocol that
requires an `at-spi2-core` patch.
If we need to use simple async code in a few places, a single executor
may be better than having several threads blocking on async code.
This should probably use the calloop executor, but that's had issues in
cosmic-workspaces, though that may not apply here.
This seems for an SDL XWayland client to restore fullscreen after
unminimize, it needs to see the `_NET_WM_STATE_HIDDEN` state get set
and unset.
In general `_NET_WM_STATE_HIDDEN` does not seem to cover all the
cases covered by waylands "suspended" state, so let's not equate them.
https://github.com/pop-os/cosmic-comp/issues/1510
