Forum Replies Created
-
Posts
-
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'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.
Hi,
is the server headless, or is its monitor turned off? Do you experience the same lag when the monitor is attached and turned on?
This doesn’t happen when connected to a physical display.
Please clarify that. Do you mean that it doesn’t happen when you’re sitting in front of the server machine and using the local mouse?
Some tips for headless machines are also available here https://kb.nomachine.com/AR03P00973
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).