Forum Replies Created
-
Posts
-
I’m going to send to you a couple of debug libraries you should place in C:\Program Files (x86)\NoMachine\bin, replacing the originals. Be aware they produce a lot of output in the log files.
When you reproduce the issue, please create a zip archive of the folder C:\ProgramData\NoMachine\var\log and send it by email.
Could you check that xrandr is able to resize the screen as expected? Try xrandr -s 1280×800, for example.
I can see that 1920×1080 is not in the list produced by xrandr. Is that test with VNC from a different host?
Hello.
Resizing the screen of the remote machine failed. The reason could be traced in the Xorg server log.
Could you send the content of files /var/log/Xorg*.log ?Unfortunately I’m not able to reproduce the problem. I can create a verbose version of NoMachine libs in order to log detailed data about input events. If you want to try it, it could be helpful. By the way, if I were able to reproduce the problem on my own it’d be much better.
It looks the behavior you get with a Shift key is stuck.
In the case it occurs again, could you try to press and release, one by one, left and right Shift and see if something changes?
Could you pay attention to the situation in which such issue occurs (some specific sequence of input actions, for example)? That could help us to reproduce the problem.graphixillusion, I think touchpad does not cause any problem.
Do you mind if I ask you more:
Did you gather the wintest output while the mouse problem was ongoing?
Did you do it on the server through NoMachine?
About the Caps Lock issue, is it just inverted? In other words, if you press Caps Lock once can you type in lowercase (although the light on the keyboard turned on)?I think your X server fails to start if no monitor is attached to the graphical output. You can try to configure Xorg tweaking /etc/X11/xorg.conf. Configuration depends on video card vendor, but you can easily find something useful for NVIDIA, for example:
https://virtualgl.org/Documentation/HeadlessNVTo check if a physical display is available, you can search for running “X” process:
ps -ef | grep X
Search for “X” or “Xorg” among results.Virtual sessions use nxnode.bin as display server, search for them using nxserver –list and ps:
/usr/NX/bin/nxserver --list
ps -ef | grep nxnodeIf session is still running and you’d like to try to recover, killing all the running grabs could be useful.
Access the remote host using the same account owning the graphical session.
Using the proper display number (it should be :0, but check the Xorg command line with ps) setup the xkb map:
DISPLAY=:0 setxkbmap -option "grab:debug" -option "grab:break_actions"
Check the result:
DISPLAY=:0 xprop -root | grep XKB
Now you can list the grabs sending keystrokes through xdootol:
DISPLAY=:0 xdotool key XF86LogGrabInfo
Output will go into file/var/log/Xorg.0.log
To cancel the grabs or kill the grabbing programs:
DISPLAY=:0 xdotool key XF86Ungrab
DISPLAY=:0 xdotool key XF86ClearGrab
See the results:
tail /var/log/Xorg.0.log
[ 1951.330] Ungrabbing all devices and killing their owners; grabs listed below:
[ 1951.330] End list of ungrabbed devicesIf you tried anything without success, you could restart the display manager or reboot the server machine, but that would kill any job you were running in the graphical session. If you decide for that way, switching to runlevel 3 would kill display manager, runlevel 5 will bring it up:
init 3
init 5The client treats raw keyboard event. The server is the place where raw events are translated in a meaningful symbol on the basis of the current keyboard layout.
Did changes in remote KDE settings take to any effect, by the way?
Could you change SessionLogClean to “0” in /usr/NX/etc/node.cfg in your server, reproduce the problem and send to me the folder /usr/NX/var/log compressed?
Hello, you can provide GPU acceleration to specific programs or to the whole Linux desktop using VirtualGL:
https://www.nomachine.com/AR11K00737
VirtualGL is meant to offload the OpenGL rendering jobs to a single accelerated X server through separate connections without any defined priority. In that sense resources are equally allocated among the remote sessions.
AMD cards provide H.264 encoding but the API is different. NoMachine does not leverage it at the moment but support for AMD encoder is under development.
Hardware encoding seems unavailable and you haven’t got a software encoder. See https://www.nomachine.com/AR10K00706