Tor

[Tor]

Did you try to disable the scale to window mode after changing the DPI scaling configuration on Windows? Is the quality better?

[Tor]

Hi martona. You can tell Windows to ignore the DPI scaling for a specific application by changing a compatibility flag: right click the application shortcut or binary, select Properties, Compatibility tab, click Change high DPI settings, check the box “Override high DPI scaling behavior” and select “Application” in the combo (it is the default).

[Tor]

Hi. We could reproduce the same behaviour (with some differences between multiple Android versions), but we’re still unsure about what triggers the issue. In all cases, in order to work around it we had to enable the disk access (you was right in your analysis). You can do that on One UI by opening Settings, Apps, top right dots menu, Special access, All files access, turn on NoMachine. We also noticed that the file destination panel has a wrong layout, it is too thin. Whatever happened, did break the app pretty well! I’m sorry for that, we’ll publish a fix in our next update. Disk permissions should be required only when you want to upload a file from any allowed system folder, not necessarily when you download a file (it would be saved in the app’s private storage).

[Tor]

Hi warbaker.
We confirmed that the original issue of this thread is a problem with our window not receiving events sometimes, for unpredictable reasons and without a clear events pattern to work around it. We’re still digging Apple events to find a fix.
However your case seems different, an offset can be caused by a problem in scaling the pointer coordinate. You said you run in fullscreen mode, what is the view mode: viewport (scrollbars or black area around the desktop), resize remote display or scaling?

[Tor]

Hi. From your description it seems that the desktop environment is restoring the previous resolution. Can you check if you’ve a file named monitors.xml in your home directory (usually in ~/.config/), rename it, logout from the destkop session, login and try again to change the resolution in the NoMachine iOS app?

[Tor]

A behaviour like that occurs when the option name is wrong or when it’s not passed at all to the process. Be sure that you’re writing the --session option correctly, and if you’re using scripts or programmatically starting the process, verify that arguments are configured correctly.

[Tor]

Hi. Do I understand correctly that your key does not use a passphrase? Could you share the options you use to generate the key, please?

[Tor]

We didn’t find a way to reproduce your problem despite our efforts. Would you like to sideload a debug APK and retrieve some logs from your device? If you agree, contact us via e-mail forum[at]nomachine[dot]com and use the title of this post as subject.

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

[Author]

Posts