[GH-ISSUE #91] Double-clicking on the client

gitea-mirror commented

2026-05-05 22:05:40 -06:00

Owner

Originally created by @xf- on GitHub (Mar 12, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/91

After I start lan-mouse and move the muse to the client, every click will result in a double click.

Issue

Looks like every button click event is triggered twice on the client. (Scrolling and movement is fine)
Issue started with running two Plasma 6 (Wayland) systems. Worked with Plasma 6 and Plasma 5 (Wayland)
I switched the mouse/keyboard between both systems, behavior stays the same
Double click creates no output in the terminal
Issue happens every time and isn't traffic/connection related like stuck keys and UDP

Systems

Running as --daemon
Latest commit on main 0196cf
Using simple toml config
LAN connections

(server=send lan mouse information and has input devices/peripherals, client=uses lan mouse for inputs and no peripherals)

Originally created by @xf- on GitHub (Mar 12, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/91 After I start lan-mouse and move the muse to the client, every click will result in a double click. **Issue** - Looks like every button click event is triggered twice on the client. (Scrolling and movement is fine) - Issue started with running two Plasma 6 (Wayland) systems. Worked with Plasma 6 and Plasma 5 (Wayland) - I switched the mouse/keyboard between both systems, behavior stays the same - Double click creates no output in the terminal - Issue happens every time and isn't traffic/connection related like stuck keys and UDP **Systems** - Running as `--daemon` - Latest commit on `main` 0196cf - Using simple `toml` config - LAN connections (server=send lan mouse information and has input devices/peripherals, client=uses lan mouse for inputs and no peripherals)

gitea-mirror closed this issue

2026-05-05 22:05:41 -06:00

gitea-mirror commented

2026-05-05 22:05:42 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

Very interesting. I managed to reproduce this. The issue seems to be on the Sending side. For some reason I'm getting two button press events from the capture window.

@feschber commented on GitHub (Mar 15, 2024): Very interesting. I managed to reproduce this. The issue seems to be on the Sending side. For some reason I'm getting two button press events from the capture window.

gitea-mirror commented

2026-05-05 22:05:43 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

[2024-03-15T13:22:52Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 674, time: 15107931, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:52Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 674, time: 15107931, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:55Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 675, time: 15110332, button: 272, state: Value(Released) }
[2024-03-15T13:22:55Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 675, time: 15110332, button: 272, state: Value(Released) }
[2024-03-15T13:22:56Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 676, time: 15111647, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:56Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 676, time: 15111647, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 677, time: 15112772, button: 272, state: Value(Released) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 677, time: 15112772, button: 272, state: Value(Released) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 678, time: 15112799, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 678, time: 15112799, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 679, time: 15112868, button: 272, state: Value(Released) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 679, time: 15112868, button: 272, state: Value(Released) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 680, time: 15112895, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 680, time: 15112895, button: 272, state: Value(Pressed) }
[2024-03-15T13:22:58Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 681, time: 15112947, button: 272, state: Value(Released) }
[2024-03-15T13:22:58Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 681, time: 15112947, button: 272, state: Value(Released) }

trace looks like this. So the exact same event is emitted twice, which is very weird.

@feschber commented on GitHub (Mar 15, 2024): ``` [2024-03-15T13:22:52Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 674, time: 15107931, button: 272, state: Value(Pressed) } [2024-03-15T13:22:52Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 674, time: 15107931, button: 272, state: Value(Pressed) } [2024-03-15T13:22:55Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 675, time: 15110332, button: 272, state: Value(Released) } [2024-03-15T13:22:55Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 675, time: 15110332, button: 272, state: Value(Released) } [2024-03-15T13:22:56Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 676, time: 15111647, button: 272, state: Value(Pressed) } [2024-03-15T13:22:56Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 676, time: 15111647, button: 272, state: Value(Pressed) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 677, time: 15112772, button: 272, state: Value(Released) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 677, time: 15112772, button: 272, state: Value(Released) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 678, time: 15112799, button: 272, state: Value(Pressed) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 678, time: 15112799, button: 272, state: Value(Pressed) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 679, time: 15112868, button: 272, state: Value(Released) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 679, time: 15112868, button: 272, state: Value(Released) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 680, time: 15112895, button: 272, state: Value(Pressed) } [2024-03-15T13:22:57Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 680, time: 15112895, button: 272, state: Value(Pressed) } [2024-03-15T13:22:58Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 681, time: 15112947, button: 272, state: Value(Released) } [2024-03-15T13:22:58Z DEBUG lan_mouse::backend::producer::wayland] event: Button { serial: 681, time: 15112947, button: 272, state: Value(Released) } ``` trace looks like this. So the exact same event is emitted twice, which is very weird.

gitea-mirror commented

2026-05-05 22:05:44 -06:00

Author

Owner

@xf- commented on GitHub (Mar 15, 2024):

Nice - not the issue, but it is reproducible.
Could be serial filtered?

@xf- commented on GitHub (Mar 15, 2024): Nice - not the issue, but it is reproducible. Could be serial filtered?

gitea-mirror commented

2026-05-05 22:05:46 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

Yeah I could just filter the serial.

https://wayland.freedesktop.org/docs/html/ch04.html
I'm a bit unsure, if it is within spec to send the same serial multiple times.
So far I assumed that serials should be unique and this is also what I've seen from other compositors.
I opended an issue on the kde bugtracker (https://bugs.kde.org/show_bug.cgi?id=483667) so we'll see.

@feschber commented on GitHub (Mar 15, 2024): Yeah I could just filter the serial. https://wayland.freedesktop.org/docs/html/ch04.html I'm a bit unsure, if it is within spec to send the same serial multiple times. So far I assumed that serials should be unique and this is also what I've seen from other compositors. I opended an issue on the kde bugtracker (https://bugs.kde.org/show_bug.cgi?id=483667) so we'll see.

gitea-mirror commented

2026-05-05 22:05:46 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

Turns out, the issue is on my end. I created multiple wl_pointer instances by accident. Will fix asap

@feschber commented on GitHub (Mar 15, 2024): Turns out, the issue is on my end. I created multiple wl_pointer instances by accident. Will fix asap

gitea-mirror commented

2026-05-05 22:05:47 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

can you confirm, it's fixed?

@feschber commented on GitHub (Mar 15, 2024): can you confirm, it's fixed?

gitea-mirror commented

2026-05-05 22:05:48 -06:00

Author

Owner

@xf- commented on GitHub (Mar 15, 2024):

Yes, it is fixed. Only major issue for me.
Other things are just strange like cursor of entering and existing on same resolution and jumping around. Not breaking :)

@xf- commented on GitHub (Mar 15, 2024): Yes, it is fixed. Only major issue for me. Other things are just strange like cursor of entering and existing on same resolution and jumping around. Not breaking :)

gitea-mirror commented

2026-05-05 22:05:49 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

The cursor always exits at the position it previously entered a different client. Is that what you mean?

@feschber commented on GitHub (Mar 15, 2024): The cursor always exits at the position it previously entered a different client. Is that what you mean?

gitea-mirror commented

2026-05-05 22:05:49 -06:00

Author

Owner

@xf- commented on GitHub (Mar 15, 2024):

Ah, you are right. I used barrier before and just kept position based on exit and copied it to entrance. Happy with current state. Look screens looking my mouse and keyboard on remote system is annoying, but I can press the 4 fix keys.

@xf- commented on GitHub (Mar 15, 2024): Ah, you are right. I used barrier before and just kept position based on exit and copied it to entrance. Happy with current state. Look screens looking my mouse and keyboard on remote system is annoying, but I can press the 4 fix keys.

gitea-mirror commented

2026-05-05 22:05:50 -06:00

Author

Owner

@feschber commented on GitHub (Mar 15, 2024):

Yeah I will get to that. Should not be very hard to exit at the correct position. As for the lock screen I will need a way to detect that the screen is locked. Will need to see how that can be done in a standardized way.

@feschber commented on GitHub (Mar 15, 2024): Yeah I will get to that. Should not be very hard to exit at the correct position. As for the lock screen I will need a way to detect that the screen is locked. Will need to see how that can be done in a standardized way.

gitea-mirror referenced this issue

2026-05-05 22:09:34 -06:00

[GH-ISSUE #217] Android/Meta Quest 3 input capture/emulation #105

Rows
Columns

[GH-ISSUE #91] Double-clicking on the client #37