AvengeMedia / AvengeMedia/DankMaterialShell

Lock screen turns solid red when pressing a physical keyboard key (regression in 1.6.0)

Open
#3,304 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.