graywolf

[graywolf]

The keyboard layout is unusual.

Please, could you post additional info?
Run in the affected session:
xkbcomp $DISPLAY - > xkbcomp.out
xprop -root | grep XKB > xprop.out

Also NoMachine server log could be useful (create an archive of folder /usr/NX/var/log).

[graywolf]

Have you tried to decrease “Quality” in the client display settings?

[graywolf]

As far as I understand, on the left there is a smaller monitor. So the garbled part is not normally visible on the physical screens.

When viewing all monitors, you can see that part because NoMachine captures the whole “virtual” screen. I think the graphics stack doesn’t even care of updating that part that is not normally visible.

We should improve this by setting a black background on all areas that are not visible in any monitor:
https://www.nomachine.com/TR09P08855

[graywolf]

In the “Display settings” pane, try checking the box labeled “Disable network-adaptative display quality” and “Disable multi-pass display encoding”. Place the “Quality” slider to the max.

[graywolf]

Matthias, please

1. Check if both packages “mesa-libGL” and “libglvnd-glx” are installed:

sudo rpm -qa mesa-libGL libglvnd-glx

2. If mesa-libGL is not installed, please install it:

sudo dnf install mesa-libGL

3. Check if files or symlinks “libGLX_indirect.so.0” and “libGLX_mesa.so.0” exist:

ls -l /usr/lib64/libGLX_indirect.so.0 /usr/lib64/libGLX_mesa.so.0

4. If libGLX_indirect.so.0 doesn’t exist, create the symlink to libGLX_mesa.so.0:

ln -s /usr/lib64/libGLX_mesa.so.0 /usr/lib64/libGLX_indirect.so.0

5. Check if problem is solved.

[graywolf]

You should get something like this: llvmpipe (LLVM 6.0, 256 bits)

Would you tell me the results of command glxinfo | grep render and ldconfig -p | grep libGL?

[graywolf]

Please try this:

Install xterm: sudo dnf install xterm
Edit node.cfg to change DefaultDesktopCommand: DefaultDesktopCommand "xterm"
Run the session, you’ll get a virtual screen with only a terminal window
Run the command /usr/libexec/gnome-session-check-accelerated in the terminal window and let me know the result.

[graywolf]

Matthias,

Didn’t you find any file named .xsession-errors in the user’s home directory?

Could you dump the journal (sudo journalctl -b > journal.txt) and send it to us, too?

[graywolf]

So you have a dual monitor setup at client side. Could you detach one of the two and try with a single monitor attached? Doe it change something?

Do you know which is the screen resolution at server side before you connect to it with NoMachine?

Would you take a screenshot of NoMachine Display Settings pane showing the available screen resolutions?

 

[graywolf]

Hello mwshook,

Could you tell me whether the problem arises connecting to a physical or a virtual display?

Could you specify the NoMachine product in use (free version, Workstation, etc)?

 

We are going to create a debug build of NoMachine libraries in order to identify the source of the issue you have reported. Please let us now if you are interested in trying it.

[graywolf]

Hello, would you connect from Windows to Linux, open a terminal window and run the command: xrandr -q

A screenshot could be useful, too.

[graywolf]

Hello, I think you would find this feature interesting:

https://www.nomachine.com/FR10N03220

There’s a ‘notify me’ service which you can use by inserting your email address. You’ll receive an email from us when it gets implemented 🙂

[graywolf]

Hello.

Thanks for reporting, the problem is under investigation. I’d suggest to uncheck the option “match the client resolution” and set “Fit to window” instead, as a workaround.

If you need to handle the two monitors separately, you would find this interesting:

https://www.nomachine.com/FR10N03220

 

[graywolf]

Hello.

Glad to heard you fixed the issue with QuickSync.

The current version doesn’t use VAAPI yet, but work is in progress for that.

[graywolf]

The blurring looks the result of the deblocking filter. You can disable it in the “Display settings” pane checking “Disable client side image post-processing”.

Deblocking filtering is automatically tuned or turned off, with criteria adapting to the different decoder in use, so the final effect could differ on VP8 and H.264. The algorithm is supposed to disable deblocking if the image is almost perfect like in this case, by the way it is going to be improved in order to find a better trade-off with the quality level.

 

[Author]

Posts