- This topic has 3 replies, 2 voices, and was last updated 3 days, 3 hours ago by
.
-
Posts
-
I see three problems, reproducible with the i915 driver, the mode-setting driver, and the ATI/AMD driver. I see them under XOrg and Wayland. I am using Debian 13.
Repro (1): open a remote xterm. Open a remote Visual Studio Code window and maximise it on the same monitor, so it hides the xterm window. Resize some of the panes in vscode. Note that the area over the xterm stops being updated, e.g. when a pane that overlaps that area scrolls.
Repro (2): open a remote instance of vscode and maximise it. Open a remote instance of meld, and maximise it on the same monitor. Click on the cross that would normally close the meld window (that is in the foreground and hiding the vscode window). Observe that the hidden vscode window is closed instead. Clicking some distance under the cross in meld works correctly.
Repro (3): open a remote instance of vscode, noting there is no border that could be used to move its window. Press Alt-space to adjust its position. Observe that afterwards the window thinks the Alt key is still pressed. This can be fixed by pressing Alt a few more times.
I can avoid the first two problems by having at most one NoMachine window per monitor.
What am I doing wrong, please? Many thanks.
Forgot: Remote NoMachine is 8.10.1 under Alma 9.7. Local version is 8.14.2 under Debian 13, Gnome shell 48.7.
Are these rootless sessions? We aren’t aware of similar issues and it would need a thorough investigation, something that is probably best done through the traditional support channel. It would be wise to update to a more recent version of NoMachine 8 first, if updating to version 9 is not possible, and see if that helps.
> Are these rootless sessions?
Yes.
(TBC, I connect by asking for an xterm if one is not running already. It then behaves like it was a local window, including that I can move it between local monitors, except it corrupts other windows that overlap it. I do not get a copy of a physical screen that would show one remote monitor at a time but allow me to switch between them.)
> We aren’t aware of similar issues and it would need a thorough investigation,
I suppose that is good news, though it is also surprising given that the screen corruption is immediately reproducible with multiple display drivers and implementations of X, and then on a distribution known for its stability.
> something that is probably best done through the traditional support channel. It would be wise to update to a more recent version of NoMachine 8 first, if updating to version 9 is not possible, and see if that helps.
Many thanks. I’ll ask our IT to try both.