hyprlock
hyprlock copied to clipboard
red screen on wake when path = screenshot
The red screen issue seems to only be happening when the path is set to screenshot. It seems sometimes hyprlock tries to update the screenshot, but when already locked, it fails. Or something like that. I can't find any relevant logs. But when I set an actual image, everything seems to work as expected.
It seems this patch fixes the issue
https://github.com/hyprwm/hyprlock/commit/307e473759d1268b50a087095cc005c941f3bb0d
I haven't seen a red screen for 2 days. I let this open for other to comfirm, but it's seems to be working for me now.
Still having the issue using latest revision 8658386f212f29447874fe62fa665c5864cdcc41
EDIT: actually it's not even on wake up but right when activating it. Might not be the same issue, you can close this one if so
Same for me. On activation it just goes red
Edit: Now its not red, and follows fractional scaling, but being a bit blurry (previously it ignored fractional scaling and was sharp) Edit2: A short red flash can occur then it sets the blurred background properly
Seems to be fixed. I dont have any problems anymore. Thank you Hyprlock
with latest commit, the red screen may happen on lock
I was messing around and found this...
If run sleep 10 && killall hyprlock and lock screen after that, then, after time will expire, screen will be red
Seeing the red screen when activating after setting background to image path.
It's working with screenshot.
Same issue occurs using the image widget.
Using Arch package v0.4.1-1
for me this is consistent. empty config except path = screenshot. just launching from terminal. big tomato flash in my face with no way to avoid it except killing hyprland from other tty
I still have the same issue with the new hyprland debug screen for when the screenlock is killed.
@feelamee
I was messing around and found this...
If run sleep 10 && killall hyprlock and lock screen after that, then, after time will expire, screen will be red
This is expected. Hyprland locks itself if the screenlock is killed externally.
A guess to what the issue could be is that hyprlock registers as a lock screen before it can present an image to the user. During that time the screenshot is taken and blurred the hyprland "no lock provider" error is displayed. Though that's just a guess. Not registering to be a lock provider until screenshot taking & blurring is done would solve it.
Also, often I see a "ghost" image of the hyprland screenlock killed screen.