graywolf

[graywolf]

Would try these things:

• Set DisplayServerExtraOptions “-nodamage”. Restart the server.
• Set EnableDisplayServerVideoCodec 1 and DisplayServerVideoCodec “vp8”. Try also “mjpeg”.

[graywolf]

Hello,

localhost:15 and localhost:44 are not usual for NoMachine display. Display is usually :0 when sharing the server console and :1001, :1002, and so on for virtual desktop sessions. There could be something related. Do you how could that happen?

About sourcing of commands in .bashrc, I don’t know how NoMachine is related with that. I guess the environment variables of the shell  are not correctly set.

[graywolf]

If you see that only one resolution is available it is possible that no screen is connected to the video card of the server.

Look at Display Settings panel of your desktop. If you are running an nvidia card, nvidia-xconfig command could help to build a custom Xorg configuration.

 

[graywolf]

It looks you are using the free edition of NoMachine: it provides only desktop sharing that is what you refer as mirroring the screen. In that case, you don’t need VirtualGL (everything occurs on display :0, included the rendering) as display is GPU-accelerated.

Without an X server running, NoMachine automatically creates a virtual display. You cannot accelerate that display by VirtualGL (it would need the X server to offload the OpenGL rendering). So that what you are trying is impossible with the free edition because the two things (virtual display session and GPU-accelerated X server) cannot exist at the same time.

Another tip: command

vglrun -d :1001 +tr +v glxgears

does not look correct. Option -d select the Xserver you mean to use to offload the rendering, that is the physical display, usually :0.

If you need to specify the display :1001 you should put it in the DISPLAY variable.

 

[graywolf]

Hello. Are you using the latest version of NoMachine?

You could try to resize the server display using the Settings tool in the Ubuntu desktop. Does it help?

[graywolf]

Could you tell me the version of Linux Mint in use so we can try to reproduce?

Notice that –activegrab does not turn on the keyboard grab automatically: you have to check “Grab the keyboard” in the Input settings anyway.

 

[graywolf]

Take a look to the session logs (usually located under /usr/NX/var/log/node/C-…). Do logs from the two machines show any difference?

Is there any difference in software (video device driver, for example)?

Are the two machine equipped with the same video card (and which kind of video card)?

[graywolf]

Now it’s clear. X display launched by TightVNC has its own keyboard map. Moreover, it lacks the KEYBOARD extension (XKB), so setxkbmap and xkbcomp cannot work.

If you change that keymap you could make it compatible with NoMachine, but likely you’ll mess up the keyboard for VNC client.

If you want to go on anyway, you have to use xmodmap to edit the map, as XKB is not available.

You could gather a more usual keymap from a different X display (non VNC):

xmodmap -pke > xmodmap_ok.txt

then connect through NoMachine to the VNC X display and load the map with the command:

xmodmap xmodmap_ok.txt

 

[graywolf]

Didn’t it help with recovering the session or didn’t shadowing even work?

Anyway, would you send server and client logs, if possible?

How to gather debug logs for support requests

[graywolf]

Does xinput produce any output?

Could you send the server session log located at /usr/NX/var/log/node/C-…?

Is the problem reproduced with non-KDE applications (xterm, for example)?

[graywolf]

From the logs it fails at an early stage. Is any monitor attached to the video output of the server? Or is it run headless?

[graywolf]

I don’t know how a such keymap is loaded in the Ubuntu server. Would you run a few other commands in the remote session, in the same way:

xmodmap -pke > xmodmap.txt

xkbcomp -xkb $DISPLAY -   > xkbcomp.txt

xprop -root | grep XKB  >  xprop.txt

setxkbmap -print  >  setxkbmap.txt

[graywolf]

Would you test the keys Q,W,E in the remote session with the xev tool (keyboard is not working but you could copy and paste the command included the newline):

xev -event keyboard

[graywolf]

Take a look of Input preference in the NoMachine Player settings: you can change shortcuts definitions included Ctrl+Alt+T.

For WinKey, you need to start the remote session, invoke the NoMachine menu with Ctrl+Alt+0, select Input tab and check “Grab the keyboard input”.

 

Attachments:

1. 

   nm-settings-1.png
   

2. 

   nm-settings-2.png
   

3. 

   nm-settings-3.png
   

[graywolf]

There is no plan to make it optional. Would you tell me why do you need to disable it? How does it impact on your workflow?

[Author]

Posts