AvengeMedia / AvengeMedia/DankMaterialShell
Lock screen turns solid red when pressing a physical keyboard key (regression in 1.6.0)
- Dominant language
- QML
- Stars
- 8.1k
- Forks
- 515
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 102
Description
## Summary
On the lock screen, pressing a **physical hardware keyboard** key turns the entire display **solid red**. Using the on-screen keyboard, touchscreen, or touchpad does not trigger it, and once you reach the desktop everything is normal. Regression introduced in **1.6.0**; **1.5.3** does not have this problem.
## Environment
- dms-shell / dms-shell-niri: **1.6.0-2** (bug present) — downgrade to **1.5.3-1** fixes it
- quickshell: 0.3.1
- Compositor: niri 26.04 (hybrid GPU: Intel + NVIDIA, desktop driven by Intel)
- lockBeforeSuspend: true
## Steps to reproduce
1. Lock the screen (`Mod+Alt+L`, `dms ipc call lock lock`, or via lock-before-suspend).
2. Press **any physical keyboard key** (e.g. start typing the password).
3. The whole lock screen turns solid red.
## Expected
Lock screen shows the password field normally while typing, as it does with on-screen/touch input.
## Actual
Pressing a physical key makes the entire screen red. This makes password unlock effectively unusable on a physical keyboard.
## Additional observations
- Red only occurs for **physical keyboard key events**. Touchscreen / on-screen keyboard / touchpad input on the lock screen is fine.
- "First" lock after boot/resume is the one that triggers it; after unlocking via the on-screen keyboard the session is healthy and subsequent locks are fine — suggesting a re-render/capture path hit only by physical-key events.
- The earlier misattribution to kernel/suspend/driver was wrong; it is purely this lock-screen input path. Downgrading dms-shell to 1.5.3 confirms it.
## Workaround
Run dms-shell/dms-shell-niri 1.5.3 until a fix is released.
Contributor guide
Research direction
Reproduce the issue on dms-shell 1.6.0-2 using a physical keyboard, then compare the lock-screen behavior with 1.5.3-1. Trace the physical-key input and lock-screen re-render path described in the report; done means the password field remains visible and the display no longer turns solid red on the first lock.
Written by the indexing model from the issue text.
Assessment
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100