Forum Replies Created
-
Posts
-
The selected monitor is saved, but if for some reason there is a delay in the client receiving the list of monitors present on the server, it ignores the preference and selects the main monitor.
You can tell us what operating systems and versions are in use on the clients and servers, so we can investigate?
Yes, it’s a case for the nouveau developers.
In the meantime, when connecting with NoMachine you’ll be able to use software decoding instead.
You can connect to a machine with multi-monitors attached, where you have installed NoMachine, and switch between those monitors from the client using the easy-to-use Switch Monitor button. When you connect, NoMachine automatically detects that multiple physical displays are available on the server side and the Switch Monitor button will be visible in the NoMachine session menu.
See https://www.nomachine.com/switching-the-view-between-multi-monitors-during-a-remote-desktop-session
Hi,
currently with multi-monitors client side, it’s possible for virtual Linux desktop sessions (Enterprise products only) to be spanned on all monitors or to a specific monitor.
I recently wrote a response to a similar question which you can see here: https://forum.nomachine.com/topic/multiple-remote-desktops-on-multiple-local-desktops#post-43975
What you are interested in is written in the second part of my response “For a later version, we are going to implement the possibility to have multi-monitors on the server side which can be managed as separate windows on multi-monitors client side. In each of these separate windows users will be able to apply all the usual settings, like applying a different scaling factor, resizing the window to any size, sending the window to fullscreen and placing the window in any desired location.”
Unfortunately, we cannot give a definitive ETA. Development priorities are currently on NoMachine Network (www.nomachine.com/network) and v9. Work on the feature you are interested in may start after that.
Regarding your question about a link to the Feature Request, we made the decision to no longer publish our internal development roadmap. For this reason I cannot provide you with a link.
Connecting via RDP is a bit different because it connects you to a virtual Windows display, not the physical display, so on the local machine you can see the Login screen. Then if you were to move to the room where that machine is and log in locally, your connection would be disconnected. I think that’s how the Pro/Enterprise version of Windows 10 works.
The other products’ names you mentioned have been removed, but they’ve been noted 😉 We’ve studied a number of products including those you indicated, though I’m not sure whether these actually show a lockscreen/login screen instead of a blank screen.
For Linux servers, an option could be to use NoMachine Workstation from the Terminal Server range; you don’t have to use the screen blanking option at all because you could run a virtual Linux desktop and nothing about your remote session would be visible. I’m not sure whether this fits your use case of walking between rooms and being able to access the server computer physically whilst you have a NoMachine session open.
Remember that screen-blanking is a privacy feature, and an important one that does its job well. It’s there to stop users in the vicinity of the computer seeing sensitive information that the remote user (presumably the session owner) doesn’t want to show. So to change how it currently works needs careful thought since we don’t want to undermine its function. You mentioned showing a lockscreen of some sort in place of a blank screen, is there another remote desktop product that does it like that?
It could be a client-side issue. We would need full Player logs from Windows machine you are connecting from, so we can check. You can post them here or submit to forum[at]nomachine[dot]com.
You can try activating hardware encoding for higher resolutions in the node.cfg (server side) by uncommenting the following key and setting it to:
EncoderMode bitrateIt is disabled for EncoderMode by default, due to the fact that the Ryzen card doesn’t support all the optimizations necessary to make it work in that mode for the highest resolutions.
Hi,
It would still be useful to see the xev output from the Ubuntu machine (see my earlier reply).
If you login to the desktop through the NoMachine session and then you flip the monitor over to the server, do you reproduce the same behaviour using the mouse attached to the server?
This is a known issue. The following Trouble Report was opened and it includes a workaround whilst you wait for the fix to be released.
Cannot change port 4000 for nxd via UI after the upgrade to v
https://www.nomachine.com/TR10T10636Please disregard last response. I figured it out – the Windows shortcut to NoMachine app
I updated my reply to make clear what/where you are supposed to click. Let us know if you have any other questions 🙂
I’m not sure what you meant in the third item.
I meant on the Windows machine you are connecting from. Do you have a custom desktop scaling set to maybe 125%, for example?
Server side logs show nothing strange (Kath) and the client side logs are still empty.
On the machine Sophie, please open the Player, go to Player settings and tick the checkbox “Don’t delete log files…:” Then go back to the Machines tab in the Player on Sophie and start your connection to Kath. Do not close it, but keep the Player open. Then, create a compressed archive of the .nx directory (whilst the Player window is still open, you might be seeing the wheel spin like you described)
sudo tar -cvp --exclude 'cache*' --exclude 'images' --exclude 'temp' -f - PATHTOUSERHOME/.nx | gzip -c nxdir.tar.gzPlease check the following:
– if scaling mode is enabled in the Player, try to disable it.
– enable ‘Show remote cursor’ and check whether the remote cursor’s shape changes or not
– is desktop scaling set in the OS settings of the Windows machine perhaps?