Return to

Looking Glass - Triage



Thanks for the evdev method. it seems to be working nicely.

However, I had issues with permissions. Apparently by default libvirt runs qemu instances as “nobody” user. I had to make qemu run as root to solve permissions issues which is probably not secure. I am planning on setting up a new user that will run the qemu and put him in the “input” group. or do you have a better idea?


awesome, looking forward to hearing progress on that front


that last point is really interesting, as there are certain bioses that seem to run bug-free. Maybe try using the shim wolf0/ohgodacompany provides to load the water edition sapphire bios on system startup instead?


yeah this could definitely have been made easier

PSP does stand for the same thing on their GPUs, it’s just a different implementation that prevents flashing unsigned bioses, which is why the shimming tools are everywhere now given that mining needs significantly different settings than stock.


Well at least we have an answer and official confirmation that this reset method will put the card into a useful state. I am going to get some sleep now and will try to figure this out over the next few days. It doesn’t look like too much to implement, just need to reverse engineer how it currently operates to cut out all the unnecessary stuff.

One thing to note however, VEGA12 will have the exact same problem, it’s reset the same way. Thankfully the reset method is identical so this could be applied to that card also.


glad you’re working on it

main reason I’m interested in the bios shim option is that it also has the potential to fix bugged polaris/hawaii cards


Is it possible modifying the AMDGPU firmware process or patching the stock firmware device files might help with other cards? it seems like you can force your initramfs to incorporate different files and change the PSP loading process with the fw_load_type amdpu module parameter.


It is not possible to modify the firmware as it is signed. As for a AtomBIOS shim, that is possible, but it very likely will not help with fixing cards as the AtomBIOS is designed for the low level early initalization before the firmware takes over, which is where the problems will lie.

To be honest at the moment this is not my goal though, if I am so inclined I may look later but the goal to achieve here is a fixed VEGA10 and VEGA12 series reset.

This morning I have managed to gather all the information together needed to issue the PSP mode3 reset, including a way to detect if the PSP microcode has already been loaded into the GPU. This is great because now (in theory) instead of needing to load the microcode, simply detecting if it’s already loaded will tell us if the card needs a reset.

However, even if the microcode does still require loading it is not very hard to add this, but I am not sure that Linus will like firmware loading code to enter a PCI Quirk, I know personally it doesn’t “feel” right.


IIRC you can actually patch the kernel to load something else before init, basically point the driver at a romfile, because the psp only checks what’s on the card. I’ve sent out an email to wolf0 to see if she’ll give me her method for doing so. I know for a fact it works around the PSP signing check, as i’ve seen mining rigs set up with completely off-spec and unsigned bioses on vega running happily.


Good news! waiting on a kernel compile of the first revision of the quirk, should know soon if it’s successful.


PM me when it goes up and we’ll get the word out ASAP


What user are we talking about here?

[email protected]:~$ sudo virsh start --domain win10lab

error: Failed to start domain win10lab
error: internal error: process exited while connecting to monitor: 2018-08-09T12:56:18.531699Z qemu-system-x86_64: -object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/looking-glass,size=33554432,share=yes: can’t open backing store /dev/shm/looking-glass for guest RAM: Permission denied

[email protected]:~$ ls -l /dev/shm/looking-glass
-rw-rw---- 1 maestro kvm 0 août 9 11:50 /dev/shm/looking-glass

[email protected]:~$ cat /etc/group | grep kvm

Using Ubuntu 18.04, thanks


It is an example, adjust it to suit your requirements.


That’s what I did (check commands above): used a user ‘maestro’, part of the ‘kvm’ group

[email protected]:~/LookingGlass/client$ ./looking-glass-client
[I] main.c:726 | run | Looking Glass (a11-69-gf75e2fe8db)
[I] main.c:727 | run | Locking Method: Atomic
[I] main.c:720 | try_renderer | Using Renderer: OpenGL
[I] main.c:830 | run | Using: OpenGL
[E] main.c:684 | map_memory | Failed to map the shared memory file: /dev/shm/looking-glass
[E] main.c:923 | run | Failed to map memory


The problem was related to AppArmor: thanks Ubuntu!
The following commands solved both of my problems (starting looking-glass-client and the VM itself):

$ sudo nano /etc/apparmor.d/abstractions/libvirt-qemu
/{dev,run}/shm/looking-glass rw,

$ sudo systemctl restart libvirtd

Maybe this should be added to the documentation


I noticed that Looking Glass on GNOME on Wayland has some performance issues. I cannot sustain the 144 frames, only around 120.

If GNOME on Xorg is used Looking Glass seems to be able to sustain 144 frames.

Not sure if the problem is with GNOME or Wayland. The only other Wayland desktop environment I know of is Sway but it does not support 144 Hz refresh rate yet so I won’t be able to test.


I can’t seem to get the keyboard and mouse to work. I get video and tried scroll lock but can’t seem to capture them. Did I miss something? I am running it with -s because I get an error below.

[I] main.c:692 | run | Looking Glass ()
[I] main.c:693 | run | Locking Method: Atomic
[I] main.c:686 | try_renderer | Using Renderer: OpenGL
[I] main.c:775 | run | Using: OpenGL
[I] spice.c:159 | spice_connect | Remote:
[E] spice.c:562 | spice_connect_channel | socket connect failure
[E] spice.c:167 | spice_connect | connect main channel failed
[E] main.c:868 | run | Failed to connect to spice server

Update 1: After adding display spice to the VM I am able to run it with out -s and capture keyboard and mouse. Issue now is the mouse does not work right (right click and mouse jumps). I thought Display Spice is not needed?

Update 2: I add a spice channel to VM and now looking glass client works without -s and without Spice display. Still not able to get mouse and keyboard to capture.

  1. Make sure you read through:

  2. Make sure you do not have a “Tablet” pointing device attached, Looking Glass does not work with absolute positioning devices as they do not work with FPS games.

  3. Try capture the mouse, hit Sctoll Lock.


This is what I have to do to get it to work:

  1. plug monitor to pass-through GPU.
  2. Start Looking Glass on Ubuntu.

If I unplug the HDMI cable, I loose the mouse pointer. I press scroll lock, I see the event capture but still no mouse. Also, I have to add Display Spice or I get can connect to Spice Server. Could this be what’s causing the issue? If it is, how do I avoid the Spice server error?


This is expected, your GPU still needs to see a monitor attached. You’re not actually loosing the mouse, you’re loosing all video and the stream freezes.

Correct, when using libvirt you must have a Spice display attached. If using QEMU direct (without libvirt) you can just specify a spice server without a display.