mirror of https://github.com/outbackdingo/hyprcosmic.git synced 2026-08-25 14:53:21 +00:00

Files

T

gitops b8b5ce546d Check the IPC from outside, and write down the input bug we did not solve

tools/verify-hypr-ipc.py exercises the fork's Hyprland IPC the way a client
reaches it, which the compositor's own log cannot show you. It checks the
socket names, that the five read commands answer JSON, that `bogus`,
`dispatch exec rofi`, `dispatch killactive`, `dispatch workspace +1` and
`dispatch workspace 0` are all refused, and that a real switch returns `ok`.
It moves the focused workspace, so it returns to the one you started on.

It is a validated negative test, not a hopeful one: run against the old
compositor before the socket rename was installed, it failed on the names and
exited 1.

docs/unreproducible-dead-input-2026-08-10.md records the session that came up
with no keyboard or pointer at all, and did not come back after a reboot. It
is closed deliberately rather than fixed, and most of its value is the list of
things it is not -- the fork's patches, `seats.for_device()` returning None,
the modifier-only Super binding, a shortcuts-config race, and two scary log
lines that stock COSMIC prints too. The one suspicious fact is that it was the
fourth compositor start on that boot. If it recurs, there is a list of what to
collect before rebooting destroys it.

The design spec said `.socket` and `.socket2`; corrected to the names clients
actually open.

cosmic.conf's bare-Super binding gets a comment saying why the key field is
empty, since an empty field in a `bind` line reads like a typo. COSMIC
supports modifier-only bindings and Hyprland's `bind` cannot express one.

2026-08-10 12:59:04 +07:00

4.3 KiB

Raw Blame History

A session that came up with no input, once, on 2026-08-10

Status: not root-caused. Not reproduced since. Closed deliberately, not fixed.

This is written down because the next person to hit it -- probably us -- will otherwise start the same investigation from scratch, and because most of the value here is the list of things it is not.

What happened

One HyprCosmic session came up with a working bar and a blank desktop below it, and no keyboard or pointer input reached the compositor at all. No binding fired. The session had to be left via a VT switch.

After a reboot, the same configuration and the same binaries came up fine. Super+Return, Super+A and a bare Super tap were all confirmed working by the user, with independent evidence from a watcher process:

12:07:48 SPAWN pid=6264 exe=/usr/bin/rofi cmd=rofi -show drun
12:07:50 SPAWN pid=6433 exe=/usr/bin/rofi cmd=rofi -show drun
12:07:51 EVENT activewindow>>com.system76.CosmicTerm,dingo@fedora:~ - COSMIC Terminal

Super+Return shows as a window event rather than a spawn because cosmic-term is single-instance: the binding fired, the existing process took the request.

Ruled out, with the evidence

Each of these was a live hypothesis that turned out to be wrong. They are listed so nobody re-runs them.

The fork's own patches. The blank screen was a separate bug entirely (a missing awww img call in autostart -- the daemon was running and drawing nothing, so nothing reported a wallpaper missing). Patch B's IPC answered queries correctly throughout. Neither patch touches input.
Events dropped by seats.for_device() returning None. This does drop input silently (src/input/mod.rs:208-215), which made it an attractive theory. But input demonstrably works on the same build, so whatever the fault was, it was not a permanent property of this code.
The modifier-only Super binding swallowing Super+Return. It cannot. The match loop at src/input/mod.rs:1915-1955 sets modifiers_shortcut_queue on press and fires on release, and critically it does not early-return, so a modifier-only binding cannot consume a normal binding sharing its modifier.
A shortcuts-config race at login. The config's mtime was 08:49; the session started at 09:59:46. Nothing was being written during startup.
Error reading from session socket and Unable to become drm master. Both appear in the log. Both also appear in stock COSMIC logins on this machine, so neither is a fork symptom. (An earlier claim in this project that the DRM message was absent post-reboot was wrong; it is present twice, for PID 1609.)

The one thing that is suspicious

The broken session was the fourth compositor start on that boot: 08:06 (from target/debug), 08:08, 08:19, and 09:59. Every other session on that boot, and every session since a reboot, has been fine.

That points at accumulated per-boot session/seat state -- a previous compositor not having fully released its seat, or logind still holding devices for a session that had gone away -- rather than at anything in the configuration or the code. It is a guess. It was not confirmed, and confirming it would mean deliberately cycling compositors on a live desktop.

If it happens again

Collect before rebooting, because a reboot destroys the only evidence:

loginctl list-sessions and loginctl session-status for each -- look for more than one active session, or a session in state closing.
ls -l /dev/input/by-path/ and whether the compositor's PID holds any of them open (ls -l /proc/<pid>/fd | grep event).
The session log with RUST_LOG=cosmic_comp::input=trace. The logger honours RUST_LOG via EnvFilter::try_from_default_env() before adding its own cosmic_comp={warn|debug} directives, and those are less specific, so the trace directive wins.
Whether libinput debug-events (as root, on a VT) sees the devices at all. That splits the fault cleanly: if libinput sees nothing, it is below the compositor and nothing in this repo can be the cause.

Do not try to clean up by name-matching processes. pkill cosmic-* and friends have twice killed this user's live desktop. Kill by a PID captured at spawn, or a process group after setsid, and confirm with readlink /proc/<pid>/exe first.

4.3 KiB Raw Blame History