[GH-ISSUE #199] MacOS Client: Globe Modifier sometimes gets sent / stuck

gitea-mirror commented

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

Owner

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

Hello, I'm having pretty good luck with using lan-mouse between KDE (Wayland) and MacOS, however when I'm typing quickly, it sometimes it seems like the Globe modifier gets sent/stuck somehow. I have a regular US keyboard layout. I'm not sure what key is triggering that.

Server:
KDE Plasma: 6.1.5
KDE Framework: 6.5
Qt Version: 6.7.2
Kernel: 6.10.9-arch1-2
Graphics: Wayland

Client:

M3 MBP

Originally created by @dimenus on GitHub (Sep 12, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/199 Hello, I'm having pretty good luck with using lan-mouse between KDE (Wayland) and MacOS, however when I'm typing quickly, it sometimes it seems like the Globe modifier gets sent/stuck somehow. I have a regular US keyboard layout. I'm not sure what key is triggering that. Server: KDE Plasma: 6.1.5 KDE Framework: 6.5 Qt Version: 6.7.2 Kernel: 6.10.9-arch1-2 Graphics: Wayland Client: M3 MBP

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Sep 12, 2024):

Seems to be related to #198.
It would be helpful, if you could send a trace log when the key gets stuck from both devices.

To do this, run lan-mouse via

LAN_MOUSE_LOG_LEVEL=trace lan-mouse

@feschber commented on GitHub (Sep 12, 2024): Seems to be related to #198. It would be helpful, if you could send a trace log when the key gets stuck from both devices. To do this, run `lan-mouse` via ```sh LAN_MOUSE_LOG_LEVEL=trace lan-mouse ```

gitea-mirror commented

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

Author

Owner

@dimenus commented on GitHub (Sep 12, 2024):

Restarting the linux side does not seem to fix the issue.

macos.log
linux.log

@dimenus commented on GitHub (Sep 12, 2024): Restarting the linux side does not seem to fix the issue. [macos.log](https://github.com/user-attachments/files/16981065/macos.log) [linux.log](https://github.com/user-attachments/files/16981080/linux.log)

gitea-mirror commented

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

Author

Owner

@Jacoby6000 commented on GitHub (Sep 23, 2024):

This doesn't only happen with the globe/fn key. It also does it with caps lock and probably other modifiers too. I'm using NixOS with Gnome as my server with an M1 Mac as the client.

I've been seeing this issue a lot and it makes lan-mouse nearly unusable for me... I have to turn it off any time I'm doing a presentation or anything important because it happens so frequently.

It seems to happen more often when typing quickly, though that could just be coincidence.

@Jacoby6000 commented on GitHub (Sep 23, 2024): This doesn't only happen with the globe/fn key. It also does it with caps lock and probably other modifiers too. I'm using NixOS with Gnome as my server with an M1 Mac as the client. I've been seeing this issue a lot and it makes lan-mouse nearly unusable for me... I have to turn it off any time I'm doing a presentation or anything important because it happens so frequently. It seems to happen more often when typing quickly, though that could just be coincidence.

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Sep 23, 2024):

I have a suspicion what is going on here, could someone check if #206 fixes this problem?

Let me know, if you need help with testing that branch, you can download a debug build from https://github.com/feschber/lan-mouse/actions/runs/10999236745?pr=206

@feschber commented on GitHub (Sep 23, 2024): I have a suspicion what is going on here, could someone check if #206 fixes this problem? Let me know, if you need help with testing that branch, you can download a debug build from https://github.com/feschber/lan-mouse/actions/runs/10999236745?pr=206

gitea-mirror commented

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

Author

Owner

@Jacoby6000 commented on GitHub (Sep 23, 2024):

Running commit 196d0f on the client device I still get this issue... Running it on my Linux host as well made my mac client infinitely repeat some characters (though I'm fairly sure running it on linux didn't change anything. AFAIK changes to the mac input emulation only runs on the mac. I just hadn't run in to the issue before deploying the version to my linux server), and I couldn't make it stop even after closing lan-mouse. I had to forcibly restart the mac. 😅

I made another comment over here: https://github.com/feschber/lan-mouse/issues/198#issuecomment-2368810598

I wonder if that'd provide some more useful context?

@Jacoby6000 commented on GitHub (Sep 23, 2024): Running commit 196d0f on the client device I still get this issue... Running it on my Linux host as well made my mac client infinitely repeat some characters (though I'm fairly sure running it on linux didn't change anything. AFAIK changes to the mac input emulation only runs on the mac. I just hadn't run in to the issue before deploying the version to my linux server), and I couldn't make it stop even after closing lan-mouse. I had to forcibly restart the mac. :sweat_smile: I made another comment over here: https://github.com/feschber/lan-mouse/issues/198#issuecomment-2368810598 I wonder if that'd provide some more useful context?

gitea-mirror commented

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

Author

Owner

@Jacoby6000 commented on GitHub (Sep 23, 2024):

Reproducing this a second time, I can see that console on the client device gets repeatedly spammed with

WARN lan_mouse::server::ping_task: device not responding, releasing keys!

And the key is never released, even after terminating lan-mouse. Pressing the key that's held down on the client device does nothing to release it either.

@Jacoby6000 commented on GitHub (Sep 23, 2024): Reproducing this a second time, I can see that console on the client device gets repeatedly spammed with ``` WARN lan_mouse::server::ping_task: device not responding, releasing keys! ``` And the key is never released, even after terminating lan-mouse. Pressing the key that's held down on the client device does nothing to release it either.

gitea-mirror commented

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

Author

Owner

@Jacoby6000 commented on GitHub (Sep 23, 2024):

I just realized this point was never clarified: Caps-lock, fn/globe and other modifiers are being sent and stuck even when we never press them

@Jacoby6000 commented on GitHub (Sep 23, 2024): I just realized this point was never clarified: Caps-lock, fn/globe and other modifiers are being sent and stuck even when we never press them

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Sep 23, 2024):

@Jacoby6000 could you test the log-keypress branch
and send another log from both sides?

This would tell me whether or not its a problem with the emulation or capture code.

In any case, thank you for your detailed reports!

@feschber commented on GitHub (Sep 23, 2024): @Jacoby6000 could you test the [log-keypress](https://github.com/feschber/lan-mouse/tree/log-keypress) branch and send another log from both sides? This would tell me whether or not its a problem with the emulation or capture code. In any case, thank you for your detailed reports!

gitea-mirror commented

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

Author

Owner

@Jacoby6000 commented on GitHub (Sep 23, 2024):

Alright, here's a detailed session reproducing some funkiness

Here are the exact keystrokes I entered

Typing some text<CR>
<CR>
Now copying the above text<UP><LeftShift+UP><LeftMeta+C><DOWN><DOWN><DOWN><CR>
<CR>
Now pasting the text<CR>
<CR>
<LeftMeta+V>

And here's the actual text output from those inputs:

Typing some text

Now copying the above text

Now pasting th txt

The <CR> inputs at the end did not register, and the <LeftMeta+V> input pasted nothing. Unsure if the lack of paste is because it failed to even copy in the first place.

You can see the e inputs get dropped on the last line as well. This is likely because <Fn (Globe)+e> = open emoji menu on a mac.

lan-mouse-linux-server.txt
lan-mouse-macos-client.txt

Before the copy/paste test, I did a long test typing normally without any modifiers besides shift, and it worked fine. So something strange is happening with cmd (Meta) inputs I think. In normal use I suspect I run in to the issue often because I (and probably most programmers) use cmd hotkeys for a lot of stuff. Cmd-tab always seems to work Okay initially, but sometimes might act a little funky. Copy and paste has never been consistent for me but works sometimes.

@Jacoby6000 commented on GitHub (Sep 23, 2024): Alright, here's a detailed session reproducing some funkiness Here are the exact keystrokes I entered ``` Typing some text<CR> <CR> Now copying the above text<UP><LeftShift+UP><LeftMeta+C><DOWN><DOWN><DOWN><CR> <CR> Now pasting the text<CR> <CR> <LeftMeta+V> ``` And here's the actual text output from those inputs: ``` Typing some text Now copying the above text Now pasting th txt ``` The `<CR>` inputs at the end did not register, and the `<LeftMeta+V>` input pasted nothing. Unsure if the lack of paste is because it failed to even copy in the first place. You can see the `e` inputs get dropped on the last line as well. This is likely because `<Fn (Globe)+e>` = open emoji menu on a mac. [lan-mouse-linux-server.txt](https://github.com/user-attachments/files/17104255/lan-mouse-server.txt) [lan-mouse-macos-client.txt](https://github.com/user-attachments/files/17104278/lan-mouse-client.txt) Before the copy/paste test, I did a long test typing normally without any modifiers besides shift, and it worked fine. So something strange is happening with cmd (Meta) inputs I think. In normal use I suspect I run in to the issue often because I (and probably most programmers) use cmd hotkeys for a lot of stuff. Cmd-tab always seems to work Okay initially, but sometimes might act a little funky. Copy and paste has never been consistent for me but works sometimes.

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Sep 24, 2024):

okay this definitely seems to be an issue with the MacOS emulation code, presumably something to do with modifier keys.

@feschber commented on GitHub (Sep 24, 2024): okay this definitely seems to be an issue with the MacOS emulation code, presumably something to do with modifier keys.

gitea-mirror commented

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

Author

Owner

@Jacoby6000 commented on GitHub (Oct 8, 2024):

@feschber I saw that #206 got merged. Just a reminder that when I was testing on that branch, my mac got in to a state where it would hold down a key and I could not make it stop no matter what I did. I had to restart the machine to make the key stop repeating. Closing lan-mouse did not fix the issue. My previous comment about it may not have made that clear

@Jacoby6000 commented on GitHub (Oct 8, 2024): @feschber I saw that #206 got merged. Just a reminder that when I was testing on that branch, my mac got in to a state where it would hold down a key and I could not make it stop no matter what I did. I had to restart the machine to make the key stop repeating. Closing lan-mouse did not fix the issue. My previous comment about it may not have made that clear

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Oct 8, 2024):

That's weird, it should functionally be identical. Could you test this on the latest commit?

@feschber commented on GitHub (Oct 8, 2024): That's weird, it should functionally be identical. Could you test this on the latest commit?

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Oct 25, 2024):

In my testing this resolves the issue at least with the command and option keys. I am however unsure about the globe modifier.

From my testing on the input-capture side, the globe modifier does not get picked up at all, (there seems to be no keycode associated with it atm) so it technically should not even work at all right now.

Would be great, if you could test this PR (#219) @Jacoby6000 @zhurai

@feschber commented on GitHub (Oct 25, 2024): In my testing this resolves the issue at least with the command and option keys. I am however unsure about the globe modifier. From my testing on the input-capture side, the globe modifier does not get picked up at all, (there seems to be no keycode associated with it atm) so it technically should not even work at all right now. Would be great, if you could test this PR (#219) @Jacoby6000 @zhurai

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Oct 25, 2024):

And in case you notice: I'm aware that caps lock does not work correctly. Will have to fix that as well

@feschber commented on GitHub (Oct 25, 2024): And in case you notice: I'm aware that caps lock does not work correctly. Will have to fix that as well

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Oct 27, 2024):

I will merge this for now, as it definitely fixes some of the problems with modifier keys in my testing.
Feel free to reopen if something does not work!

@feschber commented on GitHub (Oct 27, 2024): I will merge this for now, as it definitely fixes _some_ of the problems with modifier keys in my testing. Feel free to reopen if something does not work!

gitea-mirror referenced this issue

2026-05-05 22:15:37 -06:00

[PR #92] [MERGED] fix duplicate creation of wl_pointer / wl_keyboard #272

Rows
Columns

[GH-ISSUE #199] MacOS Client: Globe Modifier sometimes gets sent / stuck #91