hyprlock Contents of the desktop bleed through the lockscreen

Regression?

Yes

Hyprlock Info and Version

Hyprlock version v0.9.2

Hyprlock config

input-field {
  monitor =
  fade_on_empty = false
}

background {
  color = rgb(23, 39, 41)
}

Compositor Info and Version

System/Version info

Hyprland 0.51.1 built from branch  at commit 71a1216abcc7031776630a6d88f105605c4dc1c9  ([gha] Nix: update inputs).
Date: Mon Sep 22 20:54:03 2025
Tag: v0.51.1, commits: 6436
built against:
 aquamarine 0.9.5
 hyprlang 0.6.3
 hyprutils 0.10.0
 hyprcursor 0.1.13
 hyprgraphics 0.2.0


no flags were set


System Information:
System name: Linux
Node name: localhost
Release: 6.12.41-gentoo-default
Version: #1 SMP PREEMPT Wed Aug 27 12:26:01 EEST 2025


GPU information: 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1) (prog-if 00 [VGA controller])
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] [1002:1638] (rev c5) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX x86_64 Kernel Module  580.95.05  Tue Sep 23 10:11:16 UTC 2025


os-release: NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.18"


plugins:
  hyprshell-hyprland-plugin by h3rmt ver 4.6.4

Explicit sync: supported
GL ver: 3.2
Backend: drm

Monitor info:
	Panel eDP-1: 2560x1600, eDP-1 California Institute of Technology 0x1609  -> backend drm
		explicit ✔️
		edid:
			hdr ✔️
			chroma ✔️
			bt2020 ✔️
		vrr capable ✔️
		non-desktop ❌
		
	Panel HDMI-A-1: 1280x1024, HDMI-A-1 Eizo Nanao Corporation S1931 33457076 -> backend drm
		explicit ✔️
		edid:
			hdr ❌
			chroma ✔️
			bt2020 ❌
		vrr capable ❌
		non-desktop ❌

Description

Parts of the underlying desktop content bleed through the lock screen on wake up from DPMS suspend. It's very faint, but still can leak sensitive data. Also those are not parts of the current desktop contents so it's not predictable what will leak out.

How to reproduce

Set up a listener to turn of the screen and another to lock the session, in that order. On waking up the screen parts of prior content of the screen will bleed out through the lock screen.

Crash reports, logs, images, videos

You can see faint images of Firefox tabs at the top:

Jul 21 '25 11:07 logrusx

So you don't mean a bad frame like in https://github.com/hyprwm/hyprlock/issues/780 right?

This looks weird. Hyprland 0.50.1's session-lock is slightly broken. See https://github.com/hyprwm/Hyprland/commit/91d8a629ebfffaa46290331a74a54e249dec64fe

Could be that. Try latest git if you can. Could also be related to the new screenshot fade.

Please post your hyprlock config though. You posted hypridle.

Jul 21 '25 11:07 PointerDilemma

So you don't mean a bad frame like in #780 right?

No, it stays like that, but might be related.

This looks weird. Hyprland 0.50.1's session-lock is slightly broken. See hyprwm/Hyprland@91d8a62

It doesn't break on 0.8.2 and that's why I decided to post it here instead of in Hyprland's repo.

Could be that. Try latest git if you can. Could also be related to the new screenshot fade.

I don't think so but I'll test it.

Please post your hyprlock config though. You posted hypridle.

Thanks for pointing that out.

Jul 21 '25 11:07 logrusx

Can't reproduce.

No idea how this can happen. I mean yes, hyprlock's fade in could be stuck maybe, but then no way it stays stuck like that as long as hyprlock is still interactive (which it is right?)

I don't think so but I'll test it.

Thanks, I would just like to have the confidence that Hyprland is not involved.

Could also be an nvidia issue. But it sort of reminds me of some frames in the video I posted in #780

@logrusx please post some logs. (you should be able to repro with this too: sleep 1 && hyprctl dispatch dpms off && sleep 1 && hyprlock --config ~/.config/hypr/hyprlock_test_minimal.conf & sleep 6 && hyprctl dispatch dpms on. Let me know if not)

Jul 21 '25 13:07 PointerDilemma

Can't reproduce.

No idea how this can happen. I mean yes, hyprlock's fade in could be stuck maybe,

I'm not sure if it's the fade in because as I said those are not current contents.

but then no way it stays stuck like that as long as hyprlock is still interactive (which it is right?)

It is but that reminds me of another problem. When waking up the system from S3 sleep, the external monitor does not always wake up and I have to plug it out and back in. After that, very often, the first key press is lost.

Thanks, I would just like to have the confidence that Hyprland is not involved.

Could also be an nvidia issue. But it sort of reminds me of some frames in the video I posted in #780

I see why you could think it's related, it's similar but not necessarily related.

@logrusx please post some logs. (you should be able to repro with this too: sleep 1 && hyprctl dispatch dpms off && sleep 1 && hyprlock --config ~/.config/hypr/hyprlock_test_minimal.conf & sleep 6 && hyprctl dispatch dpms on. Let me know if not)

I'll test all of this but can't do it right now, I'll update you when I have the time and energy.

Thank you!

Jul 21 '25 13:07 logrusx

@logrusx please post some logs. (you should be able to repro with this too: sleep 1 && hyprctl dispatch dpms off && sleep 1 && hyprlock --config ~/.config/hypr/hyprlock_test_minimal.conf & sleep 6 && hyprctl dispatch dpms on. Let me know if not)

Yes, I can reproduce it with that, still haven't got to compile the git version. I added the --no-fade-in option mentioned in #780 and it didn't make a difference.

Here are some logs

hyrplock.log

Jul 21 '25 13:07 logrusx

I just tested it with git version, still happens.

However I noticed something interesting. It only shows contents from my first desktop which is on my laptop's integrated display which also happens to be my primary display. Nothing bleeds on my external monitor and it doesn't matter what I have on my integrated display. It always shows parts of what's on my 1st workspace, no matter what workspace I have currently on the integrated display.

And last but not least, this is AMD/NVIDIA hybrid graphics system. AMD VEGA iGPU + NVIDIA 3070. The Nvidia only drives the MUX chip.

hyprlock.log

Jul 21 '25 14:07 logrusx

Yoo thanks a lot. This line is at least something that shouldn't happen in that situation (cause no monitor, no background image either). Idk if it's related to the cause though.

[WARN] Gathering resources timed out after 2000 milliseconds. Backgrounds may be delayed and render background:color at first.

Just to confirm. You used the minimal config you put in the description right?

Jul 21 '25 15:07 PointerDilemma

Just to confirm. You used the minimal config you put in the description right?

Yes, I just commented out the general.grace option as the logs indicated it was invalid:


input-field {
  monitor =
  fade_on_empty = false
}

background {
  color = rgb(23, 39, 41)
}

And added the --no-fade-in option to hypridle.conf (and forgot to remove it after I saw it didn't change anything). But then using your way of reproducing I'm not using hypridle config, am I?

p.s. this is my actual config and I didn't even remember I had hyprlock config. I don't even know where I took it from. I searched the README and the wiki, couldn't find examples and I doubt I read all the documentation to produce it.

Jul 21 '25 15:07 logrusx

There is an example in this repo: https://github.com/hyprwm/hyprlock/blob/main/assets/example.conf

Yes, I just commented out the general.grace option as the logs indicated it was invalid

Yeah we removed the option. Now only hyprlock --grace <number> works.

And added the --no-fade-in option to hypridle.conf

I recommend using --no-fade-in whenever either you screen is already off, or you are launching before sleep. But yeah both are not related to this issue anyways.

Jul 21 '25 17:07 PointerDilemma

So you don't mean a bad frame like in #780 right?

I just saw that too, but it's not on a different display. It happened on my main display. It might be related to having more than one displays.

And it might be related to this issue but I can't tell.

Jul 24 '25 18:07 logrusx

Just an outside thought — could there be any chance this is hardware-related, like pixel burn-in or temporary ghosting on the laptop display? It might be worth testing with a solid color (like black or white) to see if the ghosting persists independently of Hyprlock. Totally understand if this has already been ruled out, just tossing it in case it's useful...

Aug 06 '25 12:08 Neitex

I already started it didn't happen with 0.8.2.

It might still be hardware related though. There are all sorts of issues with different implementations of NVIDIA Optimus.

Aug 06 '25 15:08 logrusx

Is this still happening?

Sep 17 '25 07:09 PointerDilemma

Yes, to a lesser extent though. It's now much more faint. This time I don't think I'll be able to capture it with my phone camera.

System/Version info

Hyprland 0.51.0 built from branch at commit 46174f78b374b6cea669c48880877a8bdcf7802f (version: bump to 0.51.0). Date: Wed Sep 10 12:41:05 2025 Tag: v0.51.0, commits: 6418 built against: aquamarine 0.9.4 hyprlang 0.6.3 hyprutils 0.8.4 hyprcursor 0.1.13 hyprgraphics 0.1.5

no flags were set

System Information: System name: Linux Node name: joro-lt Release: 6.12.41-gentoo-default Version: #1 SMP PREEMPT Wed Aug 27 12:26:01 EEST 2025

GPU information: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1) (prog-if 00 [VGA controller]) 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] [1002:1638] (rev c5) (prog-if 00 [VGA controller]) NVRM version: NVIDIA UNIX x86_64 Kernel Module 580.82.09 Fri Aug 29 17:44:50 UTC 2025

os-release: NAME=Gentoo ID=gentoo PRETTY_NAME="Gentoo Linux" ANSI_COLOR="1;32" HOME_URL="https://www.gentoo.org/" SUPPORT_URL="https://www.gentoo.org/support/" BUG_REPORT_URL="https://bugs.gentoo.org/" VERSION_ID="2.17"

plugins: hyprshell-hyprland-plugin by h3rmt ver 4.6.4

Explicit sync: supported GL ver: 3.2 Backend: drm

Monitor info: Panel eDP-1: 2560x1600, eDP-1 California Institute of Technology 0x1609 -> backend drm explicit ✔️ edid: hdr ✔️ chroma ✔️ bt2020 ✔️ vrr capable ✔️ non-desktop ❌

Panel HDMI-A-1: 1280x1024, HDMI-A-1 Eizo Nanao Corporation S1931 33457076 -> backend drm
	explicit ✔️
	edid:
		hdr ❌
		chroma ✔️
		bt2020 ❌
	vrr capable ❌
	non-desktop ❌

Hyprlock config

input-field { monitor = fade_on_empty = false }

background { color = rgb(23, 39, 41) }

Sep 17 '25 07:09 logrusx

That seems impossible.

Can you post a hyprlock -v log?

Sep 17 '25 07:09 PointerDilemma

This is with maximum brightness and my laptop display has 500 nits maximum brightness.

Sep 17 '25 08:09 logrusx

hyprlock.log

Sep 17 '25 08:09 logrusx

There's an interesting new development I'm struggling to connect to a particular component, but since it arises in relationship to actions wrt this issue I'll report it here:

After yesterday's tests using sleep 1 && hyprctl dispatch dpms off && sleep 1 && hyprlock & sleep 6 && hyprctl dispatch dpms on, hyprlock(I guess?) started hanging in an interesting way on wake up from S3 sleep:

The external monitor wakes up but it's completely blank black screen. Usually the password input field appears but it never refreshes until I plug out and in again the monitor or I make changes to its configuration so it gets reinitialized (and then I need to reinitialize it once more because the scaling is wrong the first time around). Then the password input was frozen. I thought Hyprland hung but then I unplugged the monitor and all of a sudden the input was full of starts corresponding to my previous attempts to type in something.

The next time it happened I just typed in my password and pressed enter and it unlocked.

EDIT: I did some more testing and I'm pretty certain hyprlock and I think only the input hanging is hyprlock's fault.

Sep 18 '25 05:09 logrusx

System information, hyprlock version and configuration updated in the top post.

Lockscreen: Actual image underneath:

This happened after the following packages were updated/recompiled:

U hyprutils-0.10.0 r hyprlang-0.6.4 U hyprland-protocols-0.7.0 r hypridle-0.1.7 r aquamarine-0.9.5 r hyprpicker-0.4.5 r hyprgraphics-0.2.0 r hyprlock-0.9.2 r hyprpaper-0.7.5 r hyprland-qtutils-0.1.4 r xdg-desktop-portal-hyprland-1.3.10 r hyprland-0.51.1

Legend: U - updated; r - rebuild due to dependence on the updated ones.

I can't tell for sure this update worsened the situation but my subjective feeling is before that whatever was on the lockscreen was barely noticeable.

Another thing to add is this stays on the lock screen even if I close the browser and leave an empty workspace. When I noticed that I decided to suspend the computer and see if something changes. ~~Nothing. Neither another tab that's not a "New Tab", nor suspending on empty workspace changes that.~~ It actually changed to the title of the current tab I'm writing in which is the title of the bug, but I don't know how it happened. Yet. Also pay attention it's not only the new tab, but there's more text layered on it from other tabs.

Oct 08 '25 15:10 logrusx

I really don't know how this can happen. But thanks for documenting this @logrusx.

Can you past a new -v log with the versions you currently use? Also could you attach a hyprland log when that happens? Could you try to reproduce it on sway or niri?

Oct 08 '25 16:10 PointerDilemma