Forum Replies Created
-
Posts
-
I see that there are no X events reported by xev even before the connection. You have to keep the cursor on the xev window to make them appear. Can you try again in that way? No need to send the whole xev output, it would be enough to show just the scroll events, before and after the connection.
Please run the ‘xev’ utility on the server and show us its output when scrolling. You should see a few ButtonPress/ButtonRelease events (of button 4 and 5), and these are the ones we’re interested in. Do this on the server before the connection (when scrolling works in all the apps) and then again after the connection (when you experience the problem).
Hi,
we don’t reproduce in our lab with version 8.9.1. Can you make sure you have rebooted the system after updating NoMachine? Can you also confirm what is the distribution you are using on the server?
If that doesn’t help, please show us the output of the following commands:
sudo netstat -anlp | grep egl sudo getcap /usr/bin/kwin_waylandPlease also check if any of these files exist:
/usr/lib/plasma-sourceenv.sh /usr/lib/plasma-dbus-run-session-if-neededHi,
it looks like a problem with the Nvidia drivers, so I would try to reinstall them. Alternatively, as a workaround, you could rename temporarily the libcuda.so library, so that it won’t be loaded and the installation can complete.
Hi,
it looks like the NumLock is off on the Ubuntu server’s keyboard, and the keypad on the Mac works as expected in this regard. You should be able to turn it on remotely by pressing the “Clear” key on the keypad of the Mac.
Hi,
please gather server side logs as exaplained in https://kb.nomachine.com/DT11R00182. You can send them to forum[at]nomachine[dot]com.
Then open the /usr/NX/etc/node.cfg file on the server, uncomment the WaylandModes key and set it to the following value:
WaylandModes drm,compositor,eglIf that doesn’t help, gather the logs again with the changed key.
It seems your graphics card goes into some low power mode. Very likely not something that can be controlled programmatically. I’d try one of the suggestions in this article: https://kb.nomachine.com/AR03P00973.
But before that, it would be nice to gather some more info on the system status. Do you have the possibility to ssh into the server and show the output of the following commands?
DISPLAY=:0 xset -q DISPLAY=:0 xrandr --verboseIf possible, run the commands both before and after the problem occurs.
And finally, what system was installed on the server before you reinstalled it?
Hi,
do you have a Nvidia card on the server? In that case you may try the suggestion in this article: https://kb.nomachine.com/AR12T01182.
If that doesn’t help, please gather server side logs by following the instructions in https://kb.nomachine.com/DT07S00243. You can send the logs to forum[at]nomachine[dot]com.
Hi hexwit,
on a headless system, it’s very likely that the GPU is not functional and so no acceleration is available, but that doesn’t always mean that performance can’t be acceptable. What you have seems a system configuration issue, that it’s not easy to pinpoint. As I understand you tried option 2 of https://kb.nomachine.com/AR03P00973. What about option 3 of the article instead? Did you give it a try? With that option NoMachine will create its own virtual display, that would be less dependent from the system configuration.
Hi Ilgaz,
please show us the client side logs for your case (https://kb.nomachine.com/DT07S00244?s=client%20logs#2). You can attach them here or send to forum[at]nomachine[dot]com, by referencing this topic.
Hi manzaiya,
sorry for the delay. I’m not sure this is the same as the known issue, given that you aren’t using a scaled display. Can you reproduce the issue right now or you downgraded the NoMachine server version in the meanwhile? If you can reproduce, would you send us the logs as explained in https://kb.nomachine.com/AR07K00677? You can send them to forum[at]nomachine[dot]com, by referencing this topic. Then please try to disable hardware decoding on the client (Open the session menu -> Display settings -> Advanced options) and hardware encoding on the server (Server settings -> Performance).
Hi Doug, I examined your logs (sorry for the delay). It seems that something is delaying the startup of the session until a timeout is reached, but unfortunately it isn’t clear what exactly. Did you maybe set up the forward of some device through the session? In that case, please try to connect with a newly created connection file. And would you exclude network problems?
The Mac is an M1 Mini
What model year?
it seems like my hardware and OS should support hardware H264
Yes, it does. The problem is that the hardware encoder doesn’t provide all the capabilities NoMachine relies upon.
That having been said, certain things are still very poorly rendered
Have you tried to increase the display quality in the Display settings panel of the session menu? You can also try to click on the ‘Disable client side post-processing’, in the advanced options.
would a complete re-install still be recommended
Yes, I would do that, just to be sure.
Hi nxmac, sorry for the delay. We identified 3 issues in your logs, not all dependent on NoMachine, that explain your observations. The first one is that the library used for software H.264 encoding is missing in your NoMachine installation, probably due to a problem occurred during the upgrade. We suggest to uninstall NoMachine completely on the Mac and reinstall it from scratch. The second issue is that the hardware H.264 encoder on the Mac lacks the capabilities needed for encoding by NoMachine. This doesn’t depend on NoMachine but it would be interesting to know the exact model of your Mac and the macOS version. These 2 issues prevented H.264 from being used at all and the VP8 encoder was used as a fallback, resulting in lower quality images. The third issue is a bug in the code responsible for falling back from H.264 encoding failures and it was causing the blanked screen issue. This will be fixed in the next NoMachine update.