mirror of
https://github.com/feschber/lan-mouse.git
synced 2026-05-15 14:15:52 -06:00
[GH-ISSUE #79] Sometimes all the keys are not released #25
Labels
No labels
Xorg
documentation
enhancement
macos
pull-request
question
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/lan-mouse#25
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ICE-GB on GitHub (Jan 17, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/79
I use hyprland to control win10
@feschber commented on GitHub (Jan 17, 2024):
What exact version are you using? I tried but could not reproduce the issue. Also, are the keys actually not released or is it just the warning?
@ICE-GB commented on GitHub (Jan 17, 2024):
e2c47d3096this commit@ICE-GB commented on GitHub (Jan 17, 2024):
actually not released
@feschber commented on GitHub (Jan 17, 2024):
It's a bit weird because there are three cases where keys are released:
In the red marked instances it can really only be the second case because otherwise it would also print
device not responding.What might be happening is, that one of the KeyReleaseEvents arrives before the
Disconnectevent. This would explain why there are Keys missing from the log.To see exactly whats going on, you could run LanMouse with
LAN_MOUSE_LOG_LEVEL=traceas an environment variable (I believe in windows you would run$env:LAN_MOUSE_LOG_LEVEL=trace) and paste the output here when the issue occurs.@feschber commented on GitHub (Jan 17, 2024):
I noticed another issue with hyprland in particular, where the cursor is released by hyprland when I have two monitors connected (which is out of my control and likely a bug in Hyprland).
Maybe that is related as well. I will see if I can bisect that ...
@ICE-GB commented on GitHub (Jan 17, 2024):
Yes, it's the second case, press the key combination to release it, thanks for the answer, I'll try to change the log level when I have time
@ICE-GB commented on GitHub (Jan 17, 2024):
The last thing I pressed was win, and after releasing the first three buttons, the log looks like this.
Sorry, my use of
>>to redirect to the log file doesn't seem to work@ICE-GB commented on GitHub (Jan 17, 2024):
before disconnect log
@feschber commented on GitHub (Jan 17, 2024):
Okay that is interesting. The Key press event is received after the modifier event.
Wayland docs say: "If this event produces a change in modifiers, then the resulting wl_keyboard.modifiers event must be sent after this event."
So this could be either a bug in Hyprland or packet reordering because of udp.
Could you also attach a trace from the Hyprland side so that I can see whats going on?
And maybe attach the exact version of Hyprland you are using so I can try to reproduce.
I should probably update the code to use the pressed keys instead of the modifier state regardless.
@ICE-GB commented on GitHub (Jan 17, 2024):
Hyprland version: https:github.com/hyprwm/Hyprland/releases/tag/v0.34.0
By the way, when I was using the latest commit a few days ago the mouse could only move in one direction after moving to the windows.
So I went back to the release version.
@ICE-GB commented on GitHub (Jan 17, 2024):
What should I do? I'm not sure how to get the hyprland trace logs.
@feschber commented on GitHub (Jan 17, 2024):
Same as in windows
(or
lan-mouseif you are using the binary version)@feschber commented on GitHub (Jan 17, 2024):
Are you talking about hyprland or lan-mouse? Because I noticed that, too
@ICE-GB commented on GitHub (Jan 17, 2024):
Sorry, I made a mistake, I thought it was hyprland's log. My English is terrible
@ICE-GB commented on GitHub (Jan 17, 2024):
hyprland version
@ICE-GB commented on GitHub (Jan 17, 2024):
lan-mouse is this with https://github.com/feschber/lan-mouse/pull/78
@feschber commented on GitHub (Jan 17, 2024):
Found the offending commit, I will open a bug report on the Hyprland repo:
c4da4b026d@ICE-GB commented on GitHub (Jan 17, 2024):
Regarding this log, I will try again tomorrow when I have time.
@feschber commented on GitHub (Jan 17, 2024):
Sure, no problem!
@ICE-GB commented on GitHub (Jan 18, 2024):
It looks like 77 was sent first and then 125 was sent?
@feschber commented on GitHub (Jan 18, 2024):
No it seems like the order is correct here. Then the only explanation is that packets are reordered.
@ICE-GB commented on GitHub (Jan 19, 2024):
Ok, I've temporarily added a 1 second sleep before sending the disconnect and it seems to be working fine for me now, looking forward to your solution!
@feschber commented on GitHub (Jan 19, 2024):
Yeah I've been thinking about that. Probably best to ignore anything that comes after a disconnect until another enter event arrives
@xf- commented on GitHub (Mar 9, 2024):
I have sometimes this issue (especially with a lot of network activity) as well with only wired connections. Also, annoying the mouse always double clicks. I'm on latest git commit, and it worked before/was better.
Looked for an issue that was mouse related and ended up here, but I guess I open a new one.
@feschber commented on GitHub (Mar 10, 2024):
Do you have a specific version where it was better?
In any case this is somewhat expected until I put some mechanism in place to handle packet loss / duplication / reordering which is currently simply ignored.
@xf- commented on GitHub (Mar 10, 2024):
I used Plasma 5 Wayland connected with Plasma 6 alpha/beta/rc Wayland before
and now I run both systems with Plasma 6 Wayland. That was the point the click issue started. EVERY click is doubled and not related to current network usage.
That was the reason I thought it is maybe a different issue.
@feschber commented on GitHub (Mar 10, 2024):
Ah yeah that is definitely a different issue then and may also be an issue with plasma.
@feschber commented on GitHub (Mar 21, 2024):
@ICE-GB can you check if the latest version still has this issue? There has been a bug with duplicated input devices that I fixed.
@ICE-GB commented on GitHub (Mar 22, 2024):
I currently have the key combination set to
asdfand everything seems to work fine!@feschber commented on GitHub (Mar 22, 2024):
I still should fix the theoretical race condition but good to hear it seems less likely now