Broken/stale frame after resume until mouse movement

[agustux]

Hyprland version

0.56

Regression

Yes, this used to work correctly before and started happening after the 0.56 update.

Describe the bug

Hyprland version: 0.56
hyprlock version: 0.9.6
GPU: Intel iGPU for compositing, Nvidia dGPU on PRIME render offload (suspended with RTD3 when idle)
Display manager: ly
After resuming from suspend with the lid opening, my screen shows a kinda corrupted frame instead of hyprlock's actual lock screen. At higher brightness I can make out roughly two things mixed together on screen: part of whatever was on the workspace before suspend (in my case ghostty) and part of the hyprlock frame that should be fully displayed, stuck showing the time of when it suspended. It's not just an old full frame sitting there, and it's not random noise either. It looks like only part of the display is updated after resume. The image appears to be a mix of the pre-suspend workspace and the hyprlock frame, rather than a complete stale frame or random corruption. Claude told me this could be some hardware planes aren't being updated (very ignorant myself)?
Typing on the keyboard does nothing. The broken frame just sits there. But moving the mouse even slightly immediately forces a full, correct redraw of hyprlock (can tell from corrected time) and any keys typed beforehand are applied right away, as if they'd been received the whole time.
Seems to me like Hyprland isn't completing a proper repaint or "pageflip" on its own after resume. Something about cursor motion is forcing the repaint that (I think) should probably be happening automatically. Ultimately, mouse movement consistently causes an immediate redraw that does not happen on its own after resume.

Possibly related kernel log:
I also see this in dmesg, happening during suspend rather than resume. It looks related to power so I assumed it was my undervolt but even with it disabled I see the same effect:

RIP: 0010:gen9_disable_dc_states+0x2d8/0x340 [i915]
intel_power_domains_suspend+0xc3/0x1b0 [i915]
intel_display_power_suspend_late+0x1a/0xd0 [i915]
i915_drm_suspend_late+0x82/0xf0 [i915]

I'm not sure if it's related to the repaint issue or a separate problem, but it happens consistently on this machine every time I suspend, so I wanted to include it in case it matters. I can't reproduce this on an intel-only machine, both up to date. Maybe this is NVIDIA PRIME specific or something?

Possibly related observation:
I originally thought this was a hyprlock or hypridle bug related to input focus, but I thought once I confirmed keyboard input has no effect on the redraw while mouse movement does, it seems more like Hyprland is not finishing the repaint on its own after resume, rather than an input handling problem in hyprlock, because I also noticed that a single loginctl lock session call triggers the Lock dbus signal twice in hypridle's log, which spawns two hyprlock processes for the same lock event. The second one gets rejected by ext_session_lock_manager. I confirmed this happens even with only one hypridle process running, and even after removing an idle timeout listener that also called loginctl lock session, so it wasn't caused by a duplicate trigger on my end. I'm not sure if this is related to the repaint issue above or a separate thing, but it happens every time and seemed worth
mentioning in case it's connected. Here's some of those logs:

[LOG] Got PrepareForSleep from dbus with sleep true
[LOG] Executing loginctl lock-session
[LOG] Process Created with pid 17308
[LOG] Got dbus .Session
[LOG] Got Lock from dbus
[LOG] Locking with hyprlock > /tmp/hyprlock.log 2>&1
[LOG] Executing hyprlock > /tmp/hyprlock.log 2>&1
[LOG] Process Created with pid 17325
[LOG] Got dbus .Session
[LOG] Got Lock from dbus
[LOG] Locking with hyprlock > /tmp/hyprlock.log 2>&1
[LOG] Executing hyprlock > /tmp/hyprlock.log 2>&1
[LOG] Process Created with pid 17332
[LOG] Wayland session got locked

hyprlock log for the rejected instance:

Locking session
onLockFinished called. Seems we got yeeten. Is another lockscreen running?

Please let me know if this part should go separately somewhere maybe

Reproduction steps

1. Lock through hypridle using before_sleep_cmd set to loginctl lock session, then suspend on closed lid
2. Resume by opening the lid
3. Try typing right away. Nothing visibly happens, and the screen looks like a mix of the old workspace and the lock screen (with the old time).
4. Move the mouse and the screen immediately redraws correctly and anything typed before is applied

System info and config

info.txt

[JPMESRocks]

I'm experiencing the same issue and it only began after the 0.56 update. Unsure what logs of mine would be helpful to include to see a possible common cause. Let me know if you figure out a fix!

[agustux]

Glad to hear it's not an isolated issue. I've even done a clean, re-install of arch and this issue persists. I've also noticed that by pkilling hypridle before closing and suspending, it actually won't even show hyprlock at all, it's just the last frame of the workspace you were on before suspending

[JPMESRocks]

I've now noticed it actually happens even without activating hyprlock. Just whenever I suspend my system and re-open the lid or press a key (without moving my cursor). I'm going to test if this happens in another DE.

[agustux]

Any updates? I'm working on building and testing (up to) 26c0b38, because 116e636 seems to be touching this kind of stuff

[agustux]

Issue persisting on Hyprland 0.56.1

[tekstryder]

Hyprlock issues should be filed at the hyprlock repo unless you can bisect to a specific Hyprland change.

Maybe this is NVIDIA PRIME specific

Possibly this:

• Fails to complete rendering after resume from suspend hyprlock#1030

[agustux]

I really appreciate it, but after going through commits leading up to 0.56, and testing with hyprlock disabled (like @JPMESRocks), I think I can rule out hyprlock as the cause (I'm not getting the same errors from that issue).

I've been bisecting with a couple commits that seem relevant between v0.55 (clean) and v0.56(.1), with hyprlock's lock trigger disabled entirely. The issue reproduces regardless of hyprlock's involvement, which only keeps leading me to believe this is on the Hyprland side

Confirmed bad commits (stuck frame, needs mouse nudge) are 26c0b38, abc2ecf, and 0.56.1. I've also confirmed v0.55.0 as clean

A couple of commits in between (116e636, 466f6bc) shows the "lockscreen died" screen that might be masking the actual behavior, so I'm still verifying those before drawing any conclusions.

[tekstryder]

Okay, so start eliminating other suspects. Completely remove hyprlock and ly from the equation. And disable the NVidia GPU if possible. Then... can you still repro the stuck/corrupt frame on resume?

As for hyprland (and stack), a bisect is a bisect. What's the very first bad commit between v0.55.0 tag (good) and v0.56.0 tag (bad)?

[agustux]

Tried builds of hyprland and its libraries from comimts 116e636 and 26c0b38, doesn't seem to be the breaking commit

[agustux]

Strangely, the problem seems to have fixed itself? Back on up to date Hyprland for arch, the screen redraws itself on its own after aronud a second. I'll try one more time with a clean install, and provided it works I will be closing this. Thanks for all the help

[agustux]

Clean install shows old problem. Now I'm not sure where it fixed itself. Either way, these commits seemed most relevant:

1. v0.55.0 — clean
2. 26c0b38 — bad
3. 116e636 — ambiguous (overlay masked by lockscreen crashed, but took a second)
4. 466f6bc — ambiguous (overlay masked, immediately showed crashed lockscreen)
5. abc2ecf — bad
6. 0.56.1 — bad

Each of those were built against the related utilities' commits shows in its respective versioned flake.lock. I don't really have more time or effort to spare on this. Hopefully future me or someone else can come along and find this useful.