fra81

[fra81]

Hi,

we can’t reproduce this issue in our labs, so we would need some more info from you.

1) You say you weren’t experiencing the problem before updating. Do you mean updating the client or the server?

2) As I understand, both clients run on ARM architecture. Would it be possible to try a different client? And, if using the same two clients, do you have the possibility to connect to a different server machine and check whether the issue is present also there?

3) What is the model of your Mac?

4) Can you please try to rename this library on the server:

sudo mv /Applications/NoMachine.app/Contents/Frameworks/lib/libnxsck.dylib /Applications/NoMachine.app/Contents/Frameworks/lib/libnxsck.dylib-bak

and restart the NoMachine server? Does it help?

5) May you send us the logs from the server? See https://kb.nomachine.com/DT07S00243. You can send them to forum[at]nomachine[dot]com.

[fra81]

Hi,

this is the first time a similar issue has been reported, so we want to try and reproduce it in our lab. What is the Linux distribution and version you are using? What desktop environment?

Please also compress the nxegl log directory ($HOME/.nx/nxegl) and send us. You can attach the archive here or send to forum[at]nomachine[dot]com.

Is this library needed for client-only use of NoMachine? (e.g. I won’t ever be connecting to this Linux machine, only from this Linux machine to other Windows/macOSes).

It isn’t. You can disable the loading of this library with this command:

sudo /usr/NX/bin/nxserver --eglcapture no

[fra81]

Hi akevinge,

those logs are not relevant indeed.

In virtual desktops software rendering is normally used and it seems like the software renderer provided by the video drivers is broken. Did you install proprietary drivers on the server? Can you try to update or uninstall them? Or, if not installed already, can you try to install them?

Other possible workarounds are:

– enabling VirtualGL for 3D rendering support (https://kb.nomachine.com/AR05P00982)

– using a different desktop environment (https://kb.nomachine.com/AR04K00667)

[fra81]

Hi,

so please try this other workaround. Open the Keyboard Viewer on the Mac, then click on the three dots and select Customize. Click on Add panel and select the ‘ANSI (Large)’ panel, so that you will have the numeric key pad on the Keyboard Viewer, including the NumLock button (normally labelled with an X sign). Now you can activate the NumLock locally on the Keyboard Viewer and from now on you should be able to use the numeric key pad of the physical keyboard.

[fra81]

Hi,

it seems that the X11 agent is not detecting correctly the actual XKB rules settings. In fact, xfree86 rules are used in the xrdp session, which are obsolete, instead of the evdev rules, that are now generally used. We will fix that in one of the next updates, but for now, as a workaround, running this command in the xrdp session should do the trick:

setxkbmap -rules evdev

[fra81]

Hi, would you try this workaround?

1.$ cd /usr/NX/lib
2. $ sudo mv libvpl.so libvpl.so.ori
3. $ find / -name "libvpl.so*"
4a. If ‘libvpl.so’ (the exact name, without suffixes) is found in the system by the previous command, then skip to step 7 to restart the server
4b. If the libvpl library is found with a slightly different name like ‘libvpl.so.2′ or similar, then proceed to step 5 to create a symlink
5. $ cd <directory_where_is_libvpl.so.2>
6. $ sudo ln -s libvpl.so.2 libvpl.so
7. $ /usr/NX/bin/nxserver --restart

[fra81]

@LittleWoods, what is your KDE Plasma version?

[fra81]

Hi,

did you also check the content of the /usr/libexec/plasma-dbus-run-session-if-needed script?

Besides, you can try the following steps:

1. Create the /etc/xdg/plasma-workspace/env directory

2. Place a nx-surceenv.sh script in it containing only this line: export LD_PRELOAD=/usr/NX/lib/libnxegl.so

3. Reboot

4. Make sure the libnxegl library is preloaded (the output of the sudo netstat -anlp | grep egl command shouldn’t be empty)

 

Let us know the results 😉

[fra81]

@jjgalvez,

please show the content of the ‘/usr/libexec/plasma-dbus-run-session-if-needed’ script. Note that this file could be in a different path, so you can use the ‘locate’ command to find it.

Also show the output of:

ls -l /etc/xdg/plasma-workspace/env

[fra81]

Hi,

do you mean that the 1280×1024 monitor is “physically” attached to the Mac mini and turned on? Or do you mean that the 1280×1024 monitor is it what you see in the system settings but no real monitor is actually plugged in?

To investigate further we would need to see the logs. You can gather both server and client side logs by following the instructions in https://kb.nomachine.com/DT07S00243. You can send them to forum[at]nomachine[dot]com, by referencing this topic.

[fra81]

Hi,

for maximum image quality, besides setting the slider all the way up, I would check ‘Disable network-adaptive’ but leave ‘Disable multi-pass’ unchecked. I’d also check ‘frame buffering’ and ‘post-processing’. Hardware decoding shouldn’t be relevant for quality. For this scenario, you may also want to disable hardware encoding on the server, since hardware encoders are surely faster but they could encode with lowest quality compared to the software encoder, even when using the same parameters.

For video playback, I’d choose a lower quality in the slider (medium quality should be a good trade off), uncheck ‘network-adaptive’ and ‘multi-pass encoding’, check ‘frame-buffering’ and ‘post-processing’. Hardware decoding is usually faster.

 

[fra81]

Hi,

we’re trying to reproduce the encoder issue with the new drivers, but it seems you also have a different problem. In fact, the fact hardware encoding fails isn’t enough to explain the black screen. Software encoding should be used as a fallback. Can you check, on the machine where you have the black screen, if unchecking ‘Use hardware encoding’ (Server settings -> Performance panel) solves the black screen problem?

Can you also send server side logs gathered while reproducing the black screen? For gathering the logs you can follow the instructions in https://kb.nomachine.com/DT07S00243 and send them to forum[at]nomachine[dot]com.

[fra81]

Sorry for the delay. I checked the logs and I see there is no difference in the scroll events before and after the connection, so we can exclude that NoMachine leaves the input events system in an inconsistent state. Even the modifiers state is exactly the same. I don’t know why those two applications stop handling scroll events, but it doesn’t seem anything that the NoMachine does wrong. One last thing you could try is comparing the outputs of the ‘xev -q’ command before and after the connection, in order to see if any of the X server settings has changed in the meanwhile.

[fra81]

Hi,

sorry for the delay. Disabling CapsLock by XKB settings on the Linux client will simply disable it as a modifier, but the NoMachine player will still receive it and forward to the Mac. Furthermore, when you disable CapsLock on the Mac, this will only affect the physical keyboard of the Mac, but it won’t have any effect on the remote input events.

What I’d suggest you is to disable the CapsLock key completely on the Linux machine, by using this command:

xmodmap -e 'keycode 66=NoSymbol'

[fra81]

Hi OldMan,

can you try to run the ‘xev’ utility in the remote desktop, send the Ctrl key to it through the NoMachine remote session and show us what is reported in the output? I would start with sending any other key first, just to check if everything is set up correctly and the keys are reported in the output. Then you can type just the Ctrl key, to see if it is sent through. Finally, you can try with the problematic Ctrl-<key> combinations and show us the xev output.

[Author]

Posts