April 12, 2021 at 09:25 #32860
Client machine is windows 10. Primary (laptop) display is 1920×1080. Secondary display is 4K. NoMachine 7.4.1
Server is Linux mint 19.3, fully up to date. Primary display is 2560×1600. NoMachine 7.3.2
Before connecting, I drag the NoMachine application window to the secondary 4K display
When I connect to the server, I choose: “Show the remote desktop at it’s resolution using the scrollbars“, and “Don’t resize the remote display“. It opens the connection window on the primary 1920×1080 display. As soon as the connection window opens, I drag that to the 4K display, and maximize it. (why doesn’t it remember which screen it was last used on, or at least open on the same screen as the NoMachine app window? This is basic stuff.)
What it then displays on my 4K display is the remote desktop, at 1920×1080 resolution. I must then edit the settings and change it to 2560×1600. Every time. If the connection is interrupted at any point, it will revert to 1920×1080. 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.
I don’t understand why it won’t remember what display to open on, and what resolution it was using for a connection. (as I said, if the connection is interrupted at all, it changes back to 1920×1080, and then I need to manually change it back to 2560×1600).
Is it getting confused because the clients primary display is 1920×1080?April 14, 2021 at 18:40 #32911TorContributor
Hi. 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.April 15, 2021 at 09:59 #32915
Yes, I am connecting to the Linux physical desktop. (The same desktop and open windows I would see if I was physically sitting at the machine)
(Linux displays settings dialog screenshot attached) I disabled the 4K secondary display on the Linux system, so that I don’t need to worry about windows opening on the wrong monitor, and having to switch monitors in NoMachine to see them.
The NoMachine window on my Windows 10 client often opens at the right size (2560×1600) on the right-hand 4K monitor, but after entering the password for the Linux system, it immediately shrinks to 1920×1080 before showing me the remote desktop.
(Windows 10 display settings screenshot attached). The primary display on this system is 1920×1080.
Attachments:May 4, 2021 at 08:25 #33222
After resizing NoMachine to 2560×1600 to match the physical Linux desktop I’m connecting to, any momentary interruption to the connection (eg work VPN connects/disconnects or random network glitch – I’m connecting from Australia to Canada) causes NoMachine to revert to 1920×1080 again, every time.
It’s not asking me to log in again – the NoMachine session gets restored, but the resolution changes.
It seems like it should be able to remember the resolution it was working at _10 seconds_ previously.
You must be logged in to reply to this topic.