Forum Replies Created
-
AuthorPosts
-
May 14, 2021 at 18:51 in reply to: MacOS remote – special keys never get forwarded even with grab keyboard/mouse #33454TorParticipant
I tried it in fullscreen, windowed, another monitor, virtual desktop, with grab and without grab.
You NEED keyboard grabbing if those shortcuts are being used by the local system. 🙂
You’re probably using Wayland, this is the reason why it is not working. The problem is documented here:https://www.nomachine.com/TR10P08952
Since you’re using GNOME you can try the following workaround:
1. Enable input grabbing in Wayland
gsettings set org.gnome.mutter.wayland xwayland-allow-grabs true
2. Print the whitelisted applications
gsettings get org.gnome.mutter.wayland xwayland-grab-access-rules
3. Append ‘nxplayer.bin’ to the existing application classes. “App A” is an example, your whitelist could be empty so you just need to add the player
gsettings set org.gnome.mutter.wayland xwayland-grab-access-rules "['App A', 'nxplayer.bin']"
4. Launch the player by enabling the active window grabbing
/usr/NX/bin/nxplayer --activegrab
May 11, 2021 at 09:19 in reply to: MacOS remote – special keys never get forwarded even with grab keyboard/mouse #33374TorParticipantHi. Can you please verify if shortcuts are correctly forwarded when NoMachine client window is fullscreen? Don’t forget to enable keyboard grab option, it is required to catch also shortcuts used by your Linux system.
TorParticipantHi.
NX 7.4.1 as many other 7.x release binaries shows problematic reliability on Linux.
We’re not aware of reliability issues on Linux, so it would be great if you can share your experience.
On this machine [ ubuntu 20.04 LTS ] there is a consistent high CPU load for /usr/NX/nxclient.bin –monitor –tray
Ubuntu 20 is one of our most common Linux testing environments, we would have noticed an obvious problem. Do you mind collecting the following information and sending it to forum[at]nomachine[dot]com :
– Directories with prefix “M-” in $HOME/.nx directory of the machine where nxclient.bin takes too much CPU
– File top.txt created with the commandtop -b -n 5 -H -p $(pgrep nxclient.bin) > top.txt
(it’ll require a few seconds to dump the data)
– File strace.txt created with the commandsudo strace -o strace.txt -tt -p $(pgrep nxclient.bin)
If you’ve multiple nxclient.bin instances but only some of them have high CPU load, replace the “pgrep nxclient.bin” command with the PID of one of those instances.
Looking at the binary there may be issues with dependencies for yet unclear reasons.
The NoMachine libraries path is not in the default search path for dynamic linker, so if you want to print all dependencies you need to run
LD_LIBRARY_PATH=/usr/NX/lib ldd /usr/NX/bin/nxclient.bin
.TorParticipantHi. The crash you reported is pretty weird and occurs in an unexpected call, so since you can easily reproduce it could you verify if there are other crash reports under /var/crash and extract also those stacks?
Reading logs would be very helpful as well, you can compress your $HOME/.nx folder and send everything (logs and stacks) to forum[at]nomachine[dot]com.
Thanks.TorParticipantHi. You could be using a NoMachine server discovered in LAN. In such a case connection settings are stored in a cache and there is not a connection file in the Documents/NoMachine folder.
You could Edit such server entry, copy the IP and the Port, then go back and click the Add menu button to create a new connection with those same IP and Port. After you create this new connection file you can either use the Machines context menu to create a copy in another location, or create a shortcut to that file with Finder (right click, Make Alias).TorParticipantHi. Version 7 introduced a big overhaul of the graphical user interfaces, and among those changes the proxy settings were moved from connection to client configuration. We understand your need, however adding also the configuration of the proxy in connection settings would be slightly confusing and impact the usability improvements we did to cover the most generic user needs.
You could try a different solution not requiring to edit connection files, by using the client command line option--config
to select a custom configuration file. Configure the proxy and rename the file %USERPROFILE%\.nx\config\player.cfg (Windows path) for every configuration you need. Create a shortcut by copy-pasting the one created by default on desktop, edit properties of the new shortcut and add the option--config C:\Users\<username>\.nx\config\<config filename>.cfg
to the Target field. You can name the shortcut to identify the proxy configuration and use it. This is the procedure for Windows, but on Linux and Mac it’s very similar.TorParticipantUnfortunately there is something not working as expected, and as a result the list is ignored. Thank you for the report! We’ve documented it here:
TorParticipantHi. Did you try to enable the Resize remote screen option? If the MacBook can apply the iPad’s resolution it’ll look better for sure.
TorParticipantThe NX protocol is the default, so you could create a new connection and add just the hostname to be ready. However you can modify an existing connection by selecting it in the connections list, by clicking the Edit button in the top menu and by using the Protocol combo to switch to NX.
Besides this, do you mind sharing what was the tricky part of the install process? It would be helpful to improve it.
TorParticipantHi Steve. It looks like the client has problems to interact with the remote shell when connecting through SSH. Is using NX protocol an option for you? In that case you would bypass the remote shell usage, because the server side process is executed by the NXD daemon.
TorParticipantHi. Are you connecting to the Linux physical desktop? I suspect in that case we’re not correctly restoring the previous resolution, we’ll check it but your confirmation would be useful.
As for the window screen position and geometry, could you please send a screenshot of your displays layout from Windows “Screen resolution” settings panel? The client window saves its position and geometry when closing, but when it fails to restore them it falls back to a different position, so checking your layout might help to reproduce the issue.It actually appears to be changing the server resolution, despite my startup option to “Don’t resize the remote display”, as if I open a spreadsheet, and then change to 2560Ă—1600, it definitely updates to display more rows and columns.
When you select “Don’t resize the remote display” you’re only deciding to not resize it in that right moment, but if you change the geometry later from Display settings or by enabling the remote resize option, then desktop is resized accordingly. Basically that panel optionally sends a single resize when the connection to the desktop starts, which is useful for many users not wishing to change the geometry afterwards.
TorParticipantHi. Could you tell us what is the VM software, Windows and macOS versions? We’d like to run a test.
The grab keyboard input on Windows is always “active” and we’re not aware of such difficulties in using keyboard shortcuts, so we need to understand what is interfering with the input catching. I’ve some questions:- Are all shortcuts ignored in the same way, or some of them pass through?
- When a shortcut is ignored, does it trigger an action on Windows?
March 18, 2021 at 20:13 in reply to: NoMachine app doesn’t rotate when on high dp settings, low res screen #32464TorParticipantHi Gato. 🙂
I’ve set the UI on my Android to dpi 600 dp, this forces NoMachine into horizontal mode only, the app thinks I’m on a tablet.
Physical screen size detection is based on screen pixel’s density, so changing the DPI value affects the result. This is normal and the application behaviour is expected. When running in tablet mode the user interface needs a wide horizontal space, that’s why it doesn’t allow the portrait orientation. We’ve experimented multiple solutions but none of them was good enough to unlock the orientation, so unless we change the interface to be the same on all devices (something we’re actually evaluating, anyway) I’m afraid I can’t offer a quick solution for your configuration.
My feature request would be that the NX player resizes when you open the OSK.
Yes, this change is definitely on our road map. We didn’t want to reduce the viewport size because we’re unaware of the current remote cursor position and movements to reach it could be pretty narrow, but your experience is clear and we want to improve it, no doubts.
Thank you for your feedback!TorParticipantI have the same problem. My server always has “Desktop not shared” in the server status page and the toggle in the lower right is greyed and not clickable.
Hi mymachines, and welcome!
The control is greyed out when your desktop can’t be shared or when there is no way to change the status, but I guess you already knew this! 🙂 Let’s see why this can happen.1. Your server is not running. You can easily verify this by opening the Settings > Server > Status.
2. Your server is configured to not allow the desktop sharing. You can confirm it by checking the status of the box “Share the desktop at server startup” in the Server Status panel.
3. Your NoMachine client is running in a Windows Terminal Server. In such a case NoMachine can’t access to the RDP desktop, thus the client can’t change the sharing configuration. I suppose this is not your case, I’m listing it only to give complete information.If you confirm you’re not in any of the above cases then you could have an unexpected issue, so let’s debug it!
Please open the command prompt and run the command"%ProgramFiles(x86)%\NoMachine\bin\nxserver" --status
(binary path between double quotes), what’s the output?
Open a file browser and enter the folder%ALLUSERSPROFILE%\NoMachine\var
(you can paste the path in the address bar), then compress the folder “log” and send it to forum[at]nomachine[dot]com by using the topic title as subject.TorParticipantIf you are sure that the server configuration is correct, I’d say something in your network or firewall configuration is dropping your packets by causing a timeout. Try to run the command
nc -v <hostname> 4000
and confirm that you receive the message “Connection to … succeeded!”. If you do not, then you should try to debug your firewall or VPN. -
AuthorPosts