maxim-nomachine

[maxim-nomachine]

Operating System: openSUSE Tumbleweed 20241222
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.6-1-default (64-bit)
Graphics Platform: X11

[maxim-nomachine]

ping 192.168.88.1
ERROR: ld.so: object ‘/usr/NX/lib/libnxegl.so’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=1.63 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=1.11 ms

I use openSUSE Tumbleweed…

I tried to look at AppArmor and generate logs via:

journalctl -g apparmor > apparmor.log

But latest message was logged 2 days ago.

So either it is not logged or it is not related to AppArmor.

[maxim-nomachine]

Yes, I tried and it does not work in Wayland.

But VMWare Workstation can successfully grab keyboard input for its window in any DE.

So grab in VMWare works even for updated KDE >= 6.1.x

I do not know what other can be considered as a test.

I will wait version 6.2.0 to check fixed KDE issue: Version Fixed In: 6.2.0

 

[maxim-nomachine]

OK, I will check with KDE if you think nothing should be made on NoMachine side.

Just one question. Should grab work in Wayland session?

[maxim-nomachine]

Can you start the player from a terminal instead like this?
/usr/NX/bin/nxplayer –activegrab

Check what’s configured in your nxs file because this setting will override your global setting (configured in Player). You can check what’s in the .nxs file by locating it in the directory defined in the ‘Connections and recordings’ field from the Settings -> Player -> Folders panel of the User Interface.

What is the reason to do that?

I wrote:

I assigned custom shortcut Meta+R in System Settings | Shortcuts The app executed in both systems: local and remote (if grab is enabled, if not then only local system).

Obviously it says that I have the way to confirm if grab was really enabled or not.

/usr/NX/bin/nxplayer –activegrab

It was tested before I created this issue. It does not have any effect.

[maxim-nomachine]

What is the OS on the nxplayer side?

The version provided is nxplayer side. Version of the remote one is OpenSUSE Leap 15.6.

Did you try a reboot on the openSUSE side?

Yes, both sides. All updates are installed, systems are rebooted.

Is the issue just the Alt F4 key or other Alt+ combinations?

I assigned custom shortcut Meta+R in System Settings | Shortcuts

The app executed in both systems: local and remote (if grab is enabled, if not then only local system).

Please describe the steps you take to reproduce the behaviour.

Nothing specific most likely it started to happen after update of local side. Maybe some incompatibility with fresh rolling libs.

I just tested another environment and it works fine:

Operating System: openSUSE Tumbleweed 20240621
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-1-default (64-bit)
Graphics Platform: X11

After updating to latest version (zypper dup) it has the same grab input issue. Updated system the same as originally tested one:

Operating System: openSUSE Tumbleweed 20240625
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.6-1-default (64-bit)
Graphics Platform: X11

[maxim-nomachine]

I just made setup on 2 Linux PCs. Both openSUSE.

Behaviour is the same.

I created connection (myself, discovery is disable), so it is saved NXS file, I connected to server, chosen full screen icon, then disconnected by Alt+F4. Next time window will not be full screen after connection to server (it will be maximized but not full screen).

If I manually change NXS file here from:

<option key=”Session window state” value=”normal” />

to:

<option key=”Session window state” value=”fullscreen” />

It reverts value to normal back, even if on close NoMachine client was in full screen.

Operating System: openSUSE Tumbleweed 20231123
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
Kernel Version: 6.6.2-1-default (64-bit)
Graphics Platform: X11

[maxim-nomachine]

I was able to workaround it only by KDE itself via “Edit Windows-Specific Settings”.

I set Force for Full Screen property for nxplayer.bin.

 

[maxim-nomachine]

How many displays are connected to the client and to the server machines?

Are you connecting to the physical desktop of a Linux server?

I can be wrong, but in my opinion it is client settings and not related to server.

Client simply does not remember windows size.

But if that matters I tried 2 different machines, 1 headless with [removed], 2nd one with 1 physical monitor, but it is not used and connection is made to VNC session.

 

As for your second question, the client doesn’t normally close the window with the list of connections while other client windows are running, so I’m not sure about what you’re seeing on Windows.

On Windows I used previous version of NoMachine, probably 7.x, now I updated to latest one 8.8.1 and situation is the same as on Linux. I think you changed that behaviour. So is it possible to close window with connections automatically after I connection to some server is established?

 

[maxim-nomachine]

How to disable such notifications?

I tried: DisplayMonitorNotifications 0

It does not help.

 

 

[maxim-nomachine]

But I do not have problem with LXQt desktop. And I workarounded it that way.

And setting up system auto-login on physical machine is not very secure concern.

[maxim-nomachine]

I think it is not a screen-saver. It is a lock screen.

[Author]

Posts