--grace 1 prevents screenlock #68
Comments
|
Have the same issue, here is my system info Logs |
|
I have the same issue. By adding |
|
I added some debug prints into the swaylock_handle_mouse [1] function and it seems like this is called even if the mouse is not moved. Line 96 in 496059a This could work as a quick and dirty fix: only if the pointer is moved more than 1, the function to unlock during grace is called: The real fix would be to find out why the motion function is called even though the pointer is not moved. |
even though there is none. See also: jirutka#68 Signed-off-by: Pascal Jäger <[email protected]>
even though there is none. See also: jirutka#68 Signed-off-by: Pascal Jäger <[email protected]>
|
Ok, after some fiddling with WAYLAND_DEBUG=1 I can pinpoint it to 2 function calls: Line 417 in 496059a and Line 439 in 496059a The first one is no wonder, because render_frame ultimately calls wl_surface_commit(). If I comment those, the motion function is not called periodically without pointer movement anymore. So the actual drawing of the surface by wayland triggers the motion event. |
|
This is a Hyprland issue, and I've managed to figure out the root cause there after much troubleshooting and debugging. I've made hyprwm/Hyprland#8584 there which fixes the issue for me - if anyone could test it that would be much appreciated :) |
|
Iirc in the PR you did for hyprland, swaylock still needs to check for the actual pointer movement like in my quickfix above because you did remove that one commit from your PR. Correct? |
|
Can confirm that the combination of hyprwm/Hyprland#8584 and #70 resolves the issue. Only applying the hyprland patch wasnt enough |
Yep - I've made #70 for that.
Awesome, thanks. I changed my Hyprland PR, so it doesn't fix the issue anymore. #70 should fix the issue with or without the Hyprland patch. |
|
I’ve been using swaylock-effects with
This is the problem, there’s no reason why drawing on the surface should trigger the mouse motion event and apparently Sway doesn’t to that. So it still looks like yet another hyprland bug. |
|
@jirutka This is entirely caused (on Hyprland) by pointer motion events, so it won't happen with The TL;DR is that simply ignoring "zero distance" motion events on the swaylock side fixes this issue, which is what I've done in #70. I've also been running swaylock-effects locally with my fix applied since I made that PR with no issues. |
|
I still don't see why they react so harshly. It is obviously not correct to trigger a pointer motion event when committing a surface, isn't it? |
|
@Schievel1 No, that's been fixed, as I mentioned... The issue still present is that a pointer motion event is sent when the surface is focused. And the ext-session-lock-v1 protocol specifies that the compositor is free to handle focusing for lock surfaces however it chooses, and Hyprland chooses to focus lock surfaces immediately after they are mapped. This focus results in a pointer enter event, followed by a motion event. This last motion event is sent with the same coordinates as the pointer event, making it what I'm calling a "zero distance" motion event. The spec says "Notification of pointer location change", which implies that zero distance events shouldn't be sent, but it isn't specified explicitly. I'm just trying to be pragmatic and get the issue (that is, |
Problem
The
--graceoption doesn't work as expected. The screen doesn't lock. To me it seems like the white default lock screen pops up for a split second but it never actually locks or instantly unlocks itself again without asking for a pwswaylock -C /dev/null --grace 0: screen locks as expected and I can unlock it by typing the passwordswaylock -C /dev/null --grace 1(or any val > 0): screen seems to lock for a split second and instantly unlocks itself without asking for pwAny idea why this is happening? Sth with pam maybe?
Info
Trace
The text was updated successfully, but these errors were encountered: