Skip to content

fix: redraw wallpaper after DMS lock screen is dismissed#2037

Merged
bbedward merged 1 commit intoAvengeMedia:masterfrom
Dimariqe:fix/wallpaper-refresh-after-unlock
Mar 20, 2026
Merged

fix: redraw wallpaper after DMS lock screen is dismissed#2037
bbedward merged 1 commit intoAvengeMedia:masterfrom
Dimariqe:fix/wallpaper-refresh-after-unlock

Conversation

@Dimariqe
Copy link

After unlocking the screen (startup lock or wake from sleep), the desktop showed Hyprland's background color instead of the wallpaper.

WallpaperBackground disables QML updates via updatesEnabled after a 1-second settle timer. While WlSessionLock is active, Hyprland does not composite the background layer, so when the lock is released it needs a fresh Wayland buffer — but none is committed because the render loop is already paused.

The previous attempt used SessionService.sessionUnlocked, which is unreliable for the startup lock case: DMSService is not yet connected when lock() is called at startup, so notifyLoginctl is a no-op and the loginctl state never transitions, meaning sessionUnlocked never fires.

Fix by tracking the shell lock state directly from Lock.qml's shouldLock via a new IdleService.isShellLocked property. WallpaperBackground watches this and re-enables rendering for 1 second on unlock, ensuring a fresh buffer is committed to Wayland before the compositor resumes displaying the layer.

After unlocking the screen (startup lock or wake from sleep), the desktop
showed Hyprland's background color instead of the wallpaper.

WallpaperBackground disables QML updates via updatesEnabled after a 1-second
settle timer. While WlSessionLock is active, Hyprland does not composite the
background layer, so when the lock is released it needs a fresh Wayland buffer
— but none is committed because the render loop is already paused.

The previous attempt used SessionService.sessionUnlocked, which is unreliable
for the startup lock case: DMSService is not yet connected when lock() is
called at startup, so notifyLoginctl is a no-op and the loginctl state never
transitions, meaning sessionUnlocked never fires.

Fix by tracking the shell lock state directly from Lock.qml's shouldLock via
a new IdleService.isShellLocked property. WallpaperBackground watches this and
re-enables rendering for 1 second on unlock, ensuring a fresh buffer is
committed to Wayland before the compositor resumes displaying the layer.
@bbedward bbedward merged commit 9efbcbc into AvengeMedia:master Mar 20, 2026
1 check passed
bbedward pushed a commit that referenced this pull request Mar 20, 2026
After unlocking the screen (startup lock or wake from sleep), the desktop
showed Hyprland's background color instead of the wallpaper.

WallpaperBackground disables QML updates via updatesEnabled after a 1-second
settle timer. While WlSessionLock is active, Hyprland does not composite the
background layer, so when the lock is released it needs a fresh Wayland buffer
— but none is committed because the render loop is already paused.

The previous attempt used SessionService.sessionUnlocked, which is unreliable
for the startup lock case: DMSService is not yet connected when lock() is
called at startup, so notifyLoginctl is a no-op and the loginctl state never
transitions, meaning sessionUnlocked never fires.

Fix by tracking the shell lock state directly from Lock.qml's shouldLock via
a new IdleService.isShellLocked property. WallpaperBackground watches this and
re-enables rendering for 1 second on unlock, ensuring a fresh buffer is
committed to Wayland before the compositor resumes displaying the layer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants