Mouse often in wrong place

[lgerhardt]

Hi, I’m running Ventura 13.4.1 and NoMachine client 8.8.1. I frequently see behaviour where the mouse acts as if it is in a different place from where it’s displaying. The only way to fix this is to flip to a different program and then back to the NoMachine client. Then I get one correct mouse click before it starts to diverge again. Sometimes I can get several hours of clean mouse behaviour if I exit my session, but it degrades again after a while.

[Tor]

Hi, thanks for the report. I’ve some questions to help the investigation.

• What is your Mac model? If it’s a Macbook, do you use the built-in trackpad or an external mouse/trackpad?
• Do you’ve multiple screens on client and/or on server?
• What is the server side operating system?
• When you say “one correct mouse click”, do you mean exactly and only one click?
• What is the NoMachine display mode you use: viewport, scaling, or remote resize?
• Can you verify if the mouse works again correctly by just opening and closing the NoMachine player menu?
• Can you verify if the mouse works again correctly by doing a small NoMachine player window resize?
• Can you estimate more or less how big the mouse offset is, and if it is always the same? Does the offset increase as you move to the bottom-right corner of the NoMachine player window?

Thank you for your help.

[lgerhardt]

Hi,

Thanks for looking at this.

I have a macbook and am using the built-in trackpad.

I have just one screen and a single NoMachine Client that I’m using.

The server side OS is CentOS Linux release 7.9.2009.

When it’s acting up, I get exactly one correct mouse click. I use viewport mode.

I’m not sure what you mean by the player menu. If you mean the settings menu that you can bring up by clicking in the corner, the answer is no.

For some reason the size of my player window is locked (I can drag to make it bigger but it snaps back to original size. I’m pretty happy with the window size it’s stuck at so I haven’t investigated that further. I’m happy to do so if you think it’s related)

The mouse offset is usually a few lines of text. I don’t know if it gets bigger at the bottom right corner.

Thanks,

Lisa

 

 

[Britgirl]

Hi, a quick update. We were unable to reproduce the problem. Can you update to the latest version, 8.10, both sides and let us know if anything has changed?

[rkeen]

I have the same issue on Mac OS Sonoma 14.2 with NoMachine 8.10.1 on both the client and server. My server is running Alma Linux 8.8 and Gnome 3.32.2, but I’ve had the problem with CentOS 7.9/Gnome 3 in the past as well. The behavior for me is the same as the original poster. I don’t see it all the time, but the following sequence seems to cause it about 25% of the time.

1. Start with NoMachine not running on the Mac
2. Launch the NoMachine client
3. Connect to the host and the mouse will work as expected including when switching to other applications on the Mac and back
4. Put the computer to sleep without logging out from the host, quitting NoMachine, or closing the connection window
5. Wake the computer and switch to the still open NoMachine window
6. The host has automatically logged out so I log back in (all keyboard)
7. The mouse location will be the first clicked location during that session
8. Clicking another application on the Mac (e.g. Mail or Numbers) and then clicking back in the NoMachine window will register the correct click location, but it will be stuck there until the next time you click to another application on the Mac
9. The only way I’ve found to fix the issue temporarily is to quit and reopen NoMachine and then the mouse seems to work without issue until the next time I put the Mac to sleep

If it makes a difference, I am running with NoMachine in Fullscreen mode on a 4K display. It doesn’t matter if the server resolution matches the client resolution.

[Britgirl]

Thanks for the information. We’re currently investigating.

[gmhliu]

I can consistently repro this issue when:

1. NoMachine is running fullscreen on an external monitor
2. I end the NoMachine session, but the app is still open
3. I unplug the monitor and close the lid of my laptop
4. I replug the monitor, and the NoMachine window with the computer icons reappears on the external monitor
5. I start a NoMachine session, and the window appears fullscreen on the external monitor, but mouse cursor position is incorrect

[Tor]

I can consistently repro this issue when:

We’d really like to have a way to reproduce the issue, even sporadically, but so far we were unable to do it. I greatly appreciate your report, could I ask you some questions about your steps description?

1. The main NoMachine window is fullscreen as well? On what monitor is it positioned?
2. What method do you use to disconnect the NoMachine session? Disconnect menu, Command+W, etc.
3. For how long do you keep the lid closed before opening it? Minutes, hours or days? This question could seem unrelated, but the closed lid triggers different macOS states depending on the time it stays closed.
4. Do you plug the monitor before or after opening the lid?
5. Assuming the main NoMachine window goes in the external monitor, did you ever notice cursor problems when interacting with the GUI?
Additionally:
6. What is the type of session you run remotely, a virtual desktop (on Workstation/Terminal server products) or a physical desktop sharing?
7. When the issue occurs, how do you work around it to restore the cursor functionality?

Of course we’ve tried to test all the combinations I listed in my questions, to no avail. I’m sorry for all the questions, I’d really like to find a way to reproduce this because the issue is somehow related to how the window receive events from the system, and a simple static analysis didn’t help so far.
Thank you very much.

[rkeen]

I’d be happy to help debug as I can reproduce the issue on a regular basis as noted in my earlier post. To add to that, my setup is as follows:

• M2 MacBook Pro
• macOS 14.3.1 (23D60)
• Connected to two external 4K monitors, one via HDMI and the other via a Dell USB-C dock with HDMI out
• Monitors are arranged virtually with the two 4K monitors side by side and the laptop below the left hand monitor
• NoMachine runs on the monitor connected to the USB-C dock (the right monitor) on it’s own desktop
• “Displays have separate spaces” is enabled in System Settings > Desktop & Dock
• Laptop lid remains open all the time
• Invoke sleep by choosing Sleep from the Apple menu
• Wake up by pressing the space bar
• Need to login after waking (for which I use touch ID)

[gmhliu]

1. The main NoMachine window is fullscreen as well? On what monitor is it positioned?

The main nomachine window is not fullscreen, it’s in a window on the same monitor as the remote connection window

2. What method do you use to disconnect the NoMachine session? Disconnect menu, Command+W, etc.

Ctrl Alt 0 > connection > disconnect

3. For how long do you keep the lid closed before opening it? Minutes, hours or days? This question could seem unrelated, but the closed lid triggers different macOS states depending on the time it stays closed.

On the order of an hour, never with the connection established though, I always disconnect before closing the lid or locking the machine. This issue sometimes even occurs when the machine stays plugged in with the lid open, but macOS locked (Ctrl + Cmd + Q)

4. Do you plug the monitor before or after opening the lid?

The monitor is plugged in before opening the lid.

5. Assuming the main NoMachine window goes in the external monitor, did you ever notice cursor problems when interacting with the GUI?

Nope, only with the remote connection.

Additionally:
6. What is the type of session you run remotely, a virtual desktop (on Workstation/Terminal server products) or a physical desktop sharing?

A physical desktop

7. When the issue occurs, how do you work around it to restore the cursor functionality?

Exit nomachine with Cmd + Q and then restart nomachine

FWIW the external monitor is a different DPI than the built in display

[Tor]

@rkeen thank you for the additional info. I’ve a question: when you originally said you log in “all keyboard”, do you mean that also the NoMachine window is focused through keyboard (Command + Tab) and then you start using the trackpad, or do you mean you start using the trackpad immediately after logging in the macbook to click-activate the NoMachine window?

@gmhliu thanks, I appreciate your answers. Did you notice if the display mode (viewport, scaling, remote resize) makes any difference?

To anyone wishing to try this: open the Input menu and check the box “Always show remote cursor pointer”. When the issue occurs, the remote cursor stands still in a position, or does it lag behind the local cursor?

[lgerhardt]

Hi,  I’m just on my laptop when this happens. I turned on “Always show remote cursor pointer”. Today, my screen went to sleep and when I woke it back up the issue with the mouse happened again. I could see that the remote cursor was not moving as I moved my mouse around.

[rkeen]

I’ve a question: when you originally said you log in “all keyboard”, do you mean that also the NoMachine window is focused through keyboard (Command + Tab) and then you start using the trackpad, or do you mean you start using the trackpad immediately after logging in the macbook to click-activate the NoMachine window?

I click to activate the NoMachine window using the trackpad but then use the keyboard to log in (i.e. I don’t click the login button, but use the Enter key).

[rkeen]

I turned on the “show remote cursor” option and it moves to the first clicked location but then doesn’t move. If you change focus to another application on the client machine and then click back into the NoMachine window, the cursor will move to the next clicked location but then doesn’t move. However, if you go into settings via the page peel shortcut and then just back out of it using the arrow at the top left the cursor works normally again.

[Tor]

Hi everyone, quick update. Thanks to the tests you all shared we can exclude a bunch of reasons causing the issue, so we’re analysing the stream of system events generated in the cases you described (screen sleep, OS suspend, etc). We suspect a problem with window activation that could put the application in a state triggering exactly the behaviour you described. I’ll keep you updated.

[Author]

Posts