[SOLVED] Screen corruption

Software & Operating Systems Looking Glass
1

Recently I re-installed kubuntu 20.10 onto the host machine from scratch. I also decided to try the bleeding-edge build of Looking Glass.

Looking glass mostly works well (on xorg, wayland on plasma is still pretty rough) except I get screen corruption after task-switching away from the full-screen viewer (in full-screen mode) and back again.

This is how I typically work - I start a windows gpu-passthrough vm and the viewer in full-screen mode but with capture disabled. Then I have a keyboard key-binding mapped on the host to ‘minimize-window’. This enables me to tap the key to jump out of the gpu-vm session to do other things, then click on the running viewer’s icon on the host’s task manager or alt-tab to jump back in. For me this is pretty much the ideal setup for the work I do.

However there appears to be a bug in the current bleeding-edge build. Sometimes (not always) after switching away then back to the full-screen viewer I see flickering horizontal bands of graphics corruption triggered by screen updates in the guest vm. See attached video for an example.

[On Wayland on the other hand, it’s a mess when using kubuntu. Results were much better back on ubuntu 20.04+wayland so this is probably a wayland on kubuntu bug and not looking glass but I see what appear to be a lot of lost invalidate-rect’s (reminiscent of my old windows 3.1 programming days) but I’m fine using x11 on the host for now so this is not really an problem, just a fyi field report.]

However, I’d like to slip in a small feature request: I think it would be great to have a key mapped in looking glass to minimize viewer. This way the user could enable key-capture mode and yet escape the vm session when desired without having to quit the viewer with ScrLk-Q or disable capture and task-switch.

In general I’ really liking the updates. Overhead is way down and frame-rates are way up vs. B2 which I was on before. It all runs really smoothly on my iGPU host + passthru-gpu guest setup, generally getting ~60fps when orbiting pretty complex cad models. I’m going to try to stay on the leading-edge build in the hope I can give feedback so we can fix this minor issue quickly. @gnif, I’m at your disposal to test/etc if/when you can get to it.

Last but not least, thanks to all the hard work all the developers have put into looking glass. It’s looking great. Check your paypal, progress donation incoming. :slight_smile:

EDIT: changing title, update: looks like I may be forced to go back to the B2+ version that ran pretty well on this system before.

It turns out that the screen corruption isn’t related to task switching, was pretty random and I thought there was a relationship to task switching but now for some unknown reason it happens all the time even on a fresh reboot & no task-switching involved.

Adding egl:vsync to the viewer command line leads to behavior similar to running under wayland where screen updates are incomplete, for example black-screen except where updated where the mouse pointer has moved over.

Anyone have suggestions for getting something working here before I go back to an earlier build?

UPDATE----->

Ok I figured out the problem:

GRUB_CMDLINE_LINUX_DEFAULT="… iommu=pt …" was misspelled.

After updating grub and rebooting the problem appears 100% fixed in the looking-glass viewer. Still seeing minor graphic animation glitches on the host when the viewer is running but it’s very minor.

2

I noticed the problem is more wide-spread than just the viewer. On this system, whenever the viewer is running other application animations on the host get momentary corruption, It even effects apps like the command terminal.

It’s getting a little irritating and with the lack of interest by developers @gnif so despite it’s higher overhead I’m probably going to go back to the B2+ build I was using previously since it worked much better.

FYI it appears the viewer is refreshing when the app is minimized. Suggest filtering canvas updates when it’s not visible.

3

I get that this can be frustrating but I don’t think that calling it a ‘lack of interest’ is fair. You’re talking about an extremely busy bunch of folks.

4

Please just use a stable release if the RC is resulting in problems. Those releases are not called stable for a reason.

1 Like
5

This might be a screen tearing issue. LG is prioritizing low latency and does everything it can to push updates into the screen as fast as possible. If your host is not configured to mitigate screen tearing, you’ll get horizontal tear lines when you run full-screen. This is not a LG bug, but a misconfiguration of your host GPU. Depending on your host GPU type, try turning on screen tear mitigation feature (TearFree with AMD, full composition pipeline with Nvidia) and see if it helps.

1 Like
6

I’d prefer to help push the effort forward by using the bleeding edge version if possible - when software doesn’t get tested bugs don’t get fixed…

Actually I’ve tried moving past the B2 build that worked well for me and had to roll back to B2 due to bugs. I didn’t report the bugs and they didn’t get fixed.

If this isn’t a good venue for bug reporting, please let me know. I try to avoid social apps like discord though.

7

I’m using an Intel iGPU for the host. Not ideal but it works well enough for the most part. This is a pretty close to default install host. I see occasional tearing when in viewer full-screen mode, it’s minor and not the issue I’m reporting above.

Above I’m saying that when the viewer is minimized (i.e. in full-screen mode, capture is off, window-minimized key has been hit) intermittently I see momentary graphics glitches in other apps. Examples are corrupted flashing cursor in s terminal (kconcole) window and corrupted updates in a different VM spice/qxl virt-viewer windows. This corruption effect goes away immediately when the viewer is closed. I can post a short video of the behavior if you’re interested.

9

This is not a LG bug, it’s a vsync issue with your GPU, it is 100% tearing.

You are running bleeding-edge, expect issues. B4 is the current stable release, you should be using that. Bleeding-edge (soon to be B5) brings with it damage tracking as you have noticed and we are still working out the kinks.

10

hmm buffer overflow… not good.
something is causing the mouse to print to the screen buffer space by the looks of it.
bad drivers or some other incompatible program.

check to see whats running in your tasks and start killing none essentials and see if it stops.
if not, start killing essentials till you either find it or kill the system and it reboots.
next reboot
keep going from before, rebooting till you find the problem.
is about the easiest method i know of bug hunting this kind of thing.

11

For this system (Intel graphics host), creating a file /etc/X11/xorg.conf.d/20-intel.conf
that contains:

Section "Device"
    Identifier "Intel Graphics"
    Driver "i915"
    Option "TearFree"    "true"
EndSection

The issue appears to be 80-90% reduced. Prior to this change I had to restart the viewer 3-4 times to get a glitch-free session, and task-switching away and back usually triggered the problem again. After this change (and rebooting) I’ve only seen the problem manifest once today in my typical workflow (CAD/CAM app + plug-in development environment)

Not sure what the eventual solution will be for this issue but at least in the short-term it seems to work pretty well.

Thanks for the clues @Netboy3 @gnif

Update: this change effects the problem in the viewer not the host. I.e. when the viewer is running I’m still seeing refresh-related (?) graphics corruption in other apps running on the host.