Tor

[Tor]

Hi Phil. We’ve tested both Samsung models running on One UI 6.0 (Android 14) and could not find any issues.
Can you type normally in the app interface, for example to set the user name logging in?
When your keys are being shown slowly on the remote desktop, did you notice if also the desktop screen updates in the app are slow (you could run a video on the desktop while typing)? If you’ve physical access to the server, did you notice if the letter is slow to appear on screen also on the physical display (not only through the app)?
Is there something you can say about the virtual keyboard? Do you use a particular configuration? Do you have bluetooth or USB devices attached to the phone/tablet?
Thanks.

[Tor]

Hi. The problem started when you updated from Ubuntu 20.04 to 22.04, or you tried that as an attempt to solve the issue? What are you device models and kernel versions?

[Tor]

We’ve similar configurations with no issues. Some questions:

1. Do you see in the client Display menu the button to select the current display on the remote desktop?
2. What display driver are you using?
3. On the client get the output of the command xdpyinfo | grep -A1 "screen\|XINERAMA"

Thanks.

[Tor]

Hi. Please send the output of the command xrandr -q executed on client and server machines, it’ll be useful to know your screens configuration and layout.

[Tor]

Hi Adam, sorry for the late answer. We’ll include the fix in our next maintenance, which should be quite close (within a couple of weeks if all goes as planned).

[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.

[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?

[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.

[Tor]

Hi. I can think to a couple of reasons:

• CFG file is edited while a player is running, so on saving current process overwrites your manual editing

This is easy to check, and honestly I think you verified it already, but it’s better to be sure.

• CFG file gets corrupted and the player creates a new one with default values

This would require more investigations, but we can start by doing two things: check if you see segmentation faults reported for nxplayer process in your system log, and try to edit more key values in the CFG so you can verify if they all change when the “overwrite” occurs (assuming you excluded the first possible issue I listed above). Also, check if in the $HOME/.nx/config folder you see files with extension .BCK or .RECOVER

[Tor]

Hi. Sorry for the late answer. We’re doing some tests in our lab with that keyboard model, as the problem is strictly related to it. We’ll keep you informed.

[Tor]

Interesting, pointer mode would explain the cursor centered in the screen, but since it’s not enabled I’ve no idea why it is there.
The application is not really doing anything with the trackpad, it’s ChromeOS converting the gestures you do to well known input events like scrolling. We’ll run some tests in our environment, do you mind sharing your ChromeOS version and Chromebook model? How did you install the NoMachine application, store or sideloading?

[Tor]

You probably enabled the pointer mode, try to turn it off and check it again. The pointer mode is useful mostly for the touch interface. You can turn it off with the icon in the side toolbar, or in the Input menu.

[Tor]

That TmUmEvt64.dll crashing is related to Trend Micro (AMSP UMH module), but the stack you pasted is about nxserver binary, so from the info you supplied I can’t confirm Trend Micro is also having problems with the NoMachine client.
Do you have a way to add a temporary exception for nxplayer.bin and nxplayer.exe, or a way to check a log of Trend Micro to look for messages related to NoMachine binaries?

[Tor]

Can you check if you’ve a file called nxtrace.log in %PROGRAMDATA%\NoMachine\var\log and send it to forum[at]nomachine[dot]com?
If this file doesn’t exist, after you try to start the Player check if there is a NoMachine Player process running in your task manager.

[Tor]

The feature is still there and working correctly, so we should just understand why it is not working for you. By the way your preference is perfectly legit! I keep the value set to 10 for a similar reason.

First of all we’ve to verify if the problem is caused by some unexpected values in the CFG and NXS files.
The NXS can be reset to default values by creating a new connection to your server. Don’t worry about your other custom settings, you can set them later.
The CFG can be reset with the “Restore default player settings” link in the settings window. Once you do that, close the player from the tray menu, and edit the CFG like I said in my previous answer.

If also this solution doesn’t work, try to set a value slightly bigger than 0, for example a number between 1 and 5, and confirm that the automatic scroll starts when you’re very close to the window edges. This test could be helpful to verify whether the problem is in the setting value reading, or in the logic of the automatic scrolling.

[Author]

Posts