Niri loses input randomly after loading some time on my laptop #72

New issue

Open

opened 2026-10-02 17:27:36 +01:00 by Vylpes · 2 comments

Vylpes commented

2026-10-02 17:27:36 +01:00

Owner

Also seems to very quickly some back after waiting from sleep

Vylpes added the

bug

niri

labels

2026-10-02 17:27:36 +01:00

Vylpes self-assigned this

2026-10-02 17:52:31 +01:00

Vylpes started working

2026-10-02 17:52:32 +01:00

Smithy-bot commented

2026-10-02 17:55:38 +01:00

Investigation notes (from desktop session + synced dotfiles)

I can't reproduce on this machine (desktop), so this is config + symptom analysis for the laptop.

Symptom pattern

Works for ~1 minute → keyboard and trackpad die → sleep/wake briefly restores input → dies again.

That pattern usually means something re-applies a bad state on a timer (idle lock / monitor power-off / input grab), not a one-shot startup race.

Strongest suspect: DMS idle / lock / DPMS

You're running DankMaterialShell (dms.service) on niri. DMS owns idle → lock → monitor-off via IdleMonitor. There are known DMS+niri issues around lock + powered-off monitors not waking cleanly, and stuck input after sleep.

On the synced settings.json here, idle timeouts are unset (defaults to Never / 0). Please check on the laptop under DMS Settings → Power & Sleep whether Lock / Turn off monitors is set to ~1 minute on battery.

Quick checks when it next dies (from a phone SSH / another TTY):

dms ipc call lock isLocked
journalctl --user -u dms.service -u niri.service -b --since "5 min ago"
# also try:
systemctl --user restart dms

If restarting DMS restores input → it's DMS grab/lock related.
If Ctrl+Alt+F3 still works but niri doesn't → seat/compositor input path.
If TTY switch also dead → kernel/libinput/hardware.

Config smells in the current niri setup

spawn-at-startup "waybar" is still enabled while DMS is the shell/bar. That should be removed so only DMS runs.
dms/outputs.kdl only defines DP-4 / DP-5 (desktop monitors). Fine if ignored on laptop, but laptop should have its own eDP-1 profile (yadm class/hostname) so DMS doesn't keep rewriting desktop outputs onto the laptop.
dms/input.kdl exists but is not included in config.kdl.
Dual lock paths: default swaylock bind still present + DMS Super+Shift+Z lock.

Next experiments on the laptop

Temporarily systemctl --user stop dms (or mask) and see if input still dies after ~1 min.
In DMS Power & Sleep: set all timeouts to Never; disable "Power off monitors on lock".
Remove spawn-at-startup "waybar" and retest.
Capture dms doctor -vC + the journal snippet above when it happens.

Happy to turn the config cleanups into a PR once we confirm which experiment fixes it.

## Investigation notes (from desktop session + synced dotfiles) I can't reproduce on this machine (desktop), so this is config + symptom analysis for the laptop. ### Symptom pattern Works for ~1 minute → keyboard **and** trackpad die → sleep/wake briefly restores input → dies again. That pattern usually means something **re-applies a bad state on a timer** (idle lock / monitor power-off / input grab), not a one-shot startup race. ### Strongest suspect: DMS idle / lock / DPMS You're running **DankMaterialShell** (`dms.service`) on niri. DMS owns idle → lock → monitor-off via `IdleMonitor`. There are known DMS+niri issues around lock + powered-off monitors not waking cleanly, and stuck input after sleep. On the synced `settings.json` here, idle timeouts are unset (defaults to Never / `0`). **Please check on the laptop** under DMS Settings → Power & Sleep whether Lock / Turn off monitors is set to ~1 minute on battery. Quick checks when it next dies (from a phone SSH / another TTY): ```bash dms ipc call lock isLocked journalctl --user -u dms.service -u niri.service -b --since "5 min ago" # also try: systemctl --user restart dms ``` If restarting DMS restores input → it's DMS grab/lock related. If Ctrl+Alt+F3 still works but niri doesn't → seat/compositor input path. If TTY switch also dead → kernel/libinput/hardware. ### Config smells in the current niri setup 1. **`spawn-at-startup "waybar"` is still enabled** while DMS is the shell/bar. That should be removed so only DMS runs. 2. **`dms/outputs.kdl` only defines `DP-4` / `DP-5`** (desktop monitors). Fine if ignored on laptop, but laptop should have its own `eDP-1` profile (yadm class/hostname) so DMS doesn't keep rewriting desktop outputs onto the laptop. 3. **`dms/input.kdl` exists but is not `include`d** in `config.kdl`. 4. Dual lock paths: default `swaylock` bind still present + DMS `Super+Shift+Z` lock. ### Next experiments on the laptop 1. Temporarily `systemctl --user stop dms` (or mask) and see if input still dies after ~1 min. 2. In DMS Power & Sleep: set all timeouts to Never; disable "Power off monitors on lock". 3. Remove `spawn-at-startup "waybar"` and retest. 4. Capture `dms doctor -vC` + the journal snippet above when it happens. Happy to turn the config cleanups into a PR once we confirm which experiment fixes it.

Vylpes stopped working

2026-10-02 18:02:07 +01:00

9 minutes 35 seconds

Smithy-bot commented

2026-10-02 18:46:52 +01:00

Update: switched from DMS to Noctalia

I've moved the shell from DankMaterialShell to Noctalia (noctalia 5.2.1) to test whether DMS idle/lock/DPMS was causing the input freeze.

niri now starts Noctalia via spawn-at-startup "noctalia"
dms.service is no longer in use

If the keyboard/trackpad stop responding after ~1 minute was DMS-related, this should fix it. Will retest on the laptop and report back.

Note: Noctalia also has its own idle/lock handling — if the issue persists, check those timeouts next before assuming it's niri itself.

## Update: switched from DMS to Noctalia I've moved the shell from DankMaterialShell to **Noctalia** (`noctalia` 5.2.1) to test whether DMS idle/lock/DPMS was causing the input freeze. - niri now starts Noctalia via `spawn-at-startup "noctalia"` - `dms.service` is no longer in use If the keyboard/trackpad stop responding after ~1 minute was DMS-related, this should fix it. Will retest on the laptop and report back. Note: Noctalia also has its own idle/lock handling — if the issue persists, check those timeouts next before assuming it's niri itself.