hyprlock icon indicating copy to clipboard operation
hyprlock copied to clipboard

An application hyprlock is trying to capture your screen.

Open rrevi opened this issue 4 months ago • 5 comments

Hello,

hyprlock version: 0.9.0-1.1

hyprlock on my system seems to be requesting to capture my screen. See attachment below.

Is this normal/intended? and if so, can I/we get some insight what it is used for, etc.

Image

rrevi avatar Jul 28 '25 06:07 rrevi

https://wiki.hypr.land/Configuring/Permissions/

fufexan avatar Jul 28 '25 15:07 fufexan

Just as context, if you don't use background:path=screenshot, since hyprlock 0.9.0, hyprlock uses a screenshot for fade-in and fade-out.

PointerDilemma avatar Jul 29 '25 13:07 PointerDilemma

Not sure why this was closed with a link to permissions docs. The question isn't what the popup is but why hyprlock is trying to take a screenshot.

@PaideiaDilemma is there a way to disable this behavior completely without using background:path=screenshot? You mentioned this is for fade-in and fade-out but disabling fade or animations altogether have no effect.

Using the --no-fade-in cli option doesn't do anything neither. I'm still getting the [LOG] Starting fade in log line and a black screen (because I denied the permission). Although it also says [LOG] Skipping screencopy before that too.

I do not want to allow hyprlock to take screenshots. Just need it to display a transparent background. However, all I get now with below config is a black screen (with widgets drawn over it if I add them to the config).

version: 0.9.1

animations {
    animation = fade,0
    # enabled = false
}

background {
	monitor = 
	color = rgba(0, 0, 0, 0.0)
}

Hyprlock does not automatically create a config, and without one, hyprlock will not render anything, meaning you will just see your screen, but it will be locked and require a password followed by an enter to unlock.

This warning from the wiki suggests removing the background widget should give me a transparent background but that's also a black screen.

caferen avatar Aug 11 '25 23:08 caferen

This confused me a bit.

First of all, with the config you posted what you get is a black screen and no fade in. Which in fact works without any screenshot. The log [LOG] Starting fade in should probably be omitted when there is no fade in. But that log is not accurate. It doesn't take a screenshot on my machine with it and it also doesn't fade in. I would say it works as expected.

So I am a bit confused about what you mean by this:

However, all I get now with below config is a black screen

Furthermore

This warning from the wiki suggests removing the background widget should give me a transparent background but that's also a black screen.

is not accurate anymore for Hyprland >0.50 (can be enabled with the misc:session_lock_xray option). I will make sure to update that in the wiki. Edit: (here: https://github.com/hyprwm/hyprland-wiki/pull/1228) Thanks for mentioning that.

BUT then there is actually a annoying bug which we need to fix: When you do need a screenshot and the popup appears without a timely completion, Hyprland sort of locks up when locking the screen. (=ALSO A BLACKSCREEN)

Hope some of this makes sense to you.

I am keeping this open to serve as tracking for generally making sure hyprlock works smoothly in combination with hyprland's permission system.

PointerDilemma avatar Sep 15 '25 17:09 PointerDilemma

Thanks for reopening @PaideiaDilemma.

Yes, I had the issue you noticed as well but it is different than what I was reporting.

Details on that one

Before I added a permission entry for hyprlock I was getting a black screen and would be greeted with multiple permission popups when I unlocked. Moreover, vertical monitors aren't fully covered by that black screen: it's more of a strip of black background the height of the primary monitor spanning across the monitors.

Onto my issue with the different black screen:

Without setting any Hyprland settings, I was able to get a transparent background with the config posted above (note the 0 alpha channel). Setting misc:session_lock_xray to true restored the behavior (when there's a permission entry allowing/denying screencopy to hyprlock - otherwise the popup messes things up again). Given hyprlock v0.9 and Hyprland v0.50 released very close to each other, I think my issue was related to newly added Hyprland option rather than the screenshot hyprlock was trying to take.

Unless fade is disabled in hyprlock, there's still a brief black screen with 'permission denied to share screen' on it so it looks like hyprlock can't detect whether it has the permission.

caferen avatar Sep 15 '25 18:09 caferen