Can't interact with hyprlock after login #7391
Comments
|
bisect bogus, can you bisect properly xd |
|
nvm, this doesn't line up with the conditions of this issue |
|
@PaideiaDilemma this is not fixed on my end |
|
Ahh shit you are right Reverting the offending commit fixes it. @vaxerski can you reopen this pls? |
|
btw it's still better as I can interact with hyprlock now, the mouse is just visible, which is waaaay nicer |
|
Still happens for me too. Moving mouse is required to interact with hyprlock after startup via |
|
Wouldn't it be possible to reintroduce 4fdc0d5 at least on Linux like for example this (or something similar, depending on where the limitation applies): #if !defined(__DragonFly__) && !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__)
fd->onSignal();
#endifuntil someone comes up with a solution that works on bsd? As I understand it, the problem currently is that input devices are only added after some interaction is made on them (because of that commit). This means keyboards will be absent for when programs run through exec-once (or similarly before inputs occur) are mapped, which causes keyboard focus to fail. So even if the devices are added later on (e.g. after the first keydown), these surfaces don't have keyboard focus. The focus will be recalculated on mouse move though. I have tried to find an easy workaround to the focus issues here and in #7568 by redoing the keyboard focus after keyboards have been added, but that doesn't seem to fully do the trick, as the first keypress is missed. Because there are no keyboards on startup, the surfaces' seats do not get the keyboard capability advertised, so they don't subscribe to keyboard events (at least on gtk). As devices are added just before the first keydown, the seats can't be quick enough to subscribe and won't catch that first keydown. We can again attempt to "work around" this by trying to resend the keydown later, but that's a fragile and horrendous "fix". So I think a good workaround on this regard is difficult to achieve. (Also note that I might've gotten something wrong here, I don't know much about wayland dev.) Considering that there seem to be other, non focus-related issues (like switchxkblayout on startup) caused by the absence of input devices, it would be nice if that change was partially reverted for the time being, until someone finds some other method to get the devices earlier. |
|
there is no way in hell the linked commit causes any issue like this |
|
As I said, I don't know much about wayland dev, so there might be something completely different at play here too. All I know is that in my testing I can consistently reproduce these issues without that To clarify what I mean, here are some logs from main with and without that
Again, I might've missed something crucial, so let me know if there's anything wrong about these logs or my other observations. |
|
The problem occurs with all surfaces that get focused before an input device receives an event. I looked into it and |
|
I think we need to manually dispatch libinput events at startup to fix it.
|
|
2 is what I was thinking bout. |
|
hyprwm/aquamarine#86 pls test |
|
doesnt seem to work |
Regression?
Yes
System Info and Version
System/Version info
Description
I have
exec-once = hyprlock [...]in my config. The issue is, in newer hyprland versions, after logging in I can see the cursor and can't interact with hyprlock. After moving the mouse slightly, the cursor disappears and I can interact with the lockscreen againHow to reproduce
Log into hyprland and have hyprlock in an exec-once
Crash reports, logs, images, videos
The first bad commit appears to be 4fdc0d5
Likely unrelated, but in this and similar commits, however, the cursor appears in the top-left corner and not in the middle (like it does in more recent commits)
The text was updated successfully, but these errors were encountered: