Return to

Looking Glass - Guides, Help and Support



Looking Glass

What is looking glass? It is a program that uses DXGI (or NvFBC if you're on Quadros or better on Nvidia) to directly capture what is displayed on a video card in a windows virtual machine and then display that on a QEMU/KVM Linux Host in near real-time.

Aren't there programs like Remote Desktop, VNC, etc that do this?

Those programs provide remote access, yes, but in this case we are copying uncompressed the actual RGBA frames from the render pipeline on the virtual machine for display on the host. It seems similar, but is entirely different. For one we have extremely low latency (probably even less as time goes on since most of our latency seems to be down to the render pipeline in vendors' drivers rather than our own code...).

If you are using IOMMU graphics in a virtual machine, and want to use productivity apps on that windows virtual machine at full speed/native performance, you should give this project a look.

Known Issues

This program is *alpha* quality. It's got bugs. Lots of bugs. It might be more bugs than substrate at this point (not really, but you know). Please read this thread very carefully before posting for help. Many known issues are posted on Geoff's site as well.

Note: QEMU currently has a bug in relative-movement mouse pointers that is being worked on. For now, we still recommend using a separate input device (or toggling USB input passthrough between) because of these bugs in QEMU. They’re aware of them, will be fixed soon.

Note2: For now, you probably still need something plugged into the passed-through GPU. This seems to depend, a bit, on the GPU but you can use a secondary input on your monitor (often) but not have to actually switch inputs to that display. We have also tested “dummy” EDID DisplayPort plugs as seen in the video, and those work fine, but it is hard to find dummy plugs that have a wide variety of supported display modes. We’ll probably link to some known good ones soon.

OMG You Guys Rock!

This is the help thread. Please kindly direct any flames or praise to this thread here. Please, and thank you!

Documentation/Getting Started

Be sure to start with the documentation on Geoff's site:

If you have questions, post them here, or alternatively join the #LookingGlass channel on the FreeNode IRC network.

Enough pillow talk, let's do this thing!

The repo is located here:

Please understand, there are several components:

  1. A windows driver, for the shared memory driver. This has been signed by RedHat – Kudos and thanks guys.
  2. A windows program, for capturing the frame buffer and copying it into the shared memory driver.
  3. A Linux program for reading and displaying the shared frame buffer (and acting as a spice client, basically).

Compiling the windows program does require visual studio from Microsoft, but fortunately the community edition (free) of Visual Studio works fine for this purpose. Once the program matures a bit, we are sure that packagers will provide signed binary downloads for Windows.

The compilation process on Linux is not super complicated.

We have experimented with many different techniques for minimizing latency and optimizing throughput. We are sure that advanced developers will want to tweak the source code for their particular setup to optimize latency, frame speed, etc. It isn’t perfect yet, but it can be extremely good.

I have done a lot of testing with a Windows guest at 95hz and 60hz and the host machine at 60, 95 and 144hz.

I can report that it is possible to tweak the source, read the rendered frame from the Windows Guest and then display that frame on the host, via FreeSync, than it takes for vblank to roll around (up to 16ms @ 60hz). Technically this means I am using FreeSync on a GTX 1080ti :wink: But the reality of this is that only the closed binary drivers from AMD are providing working FreeSync, so we don’t recommend this route yet. Kernel 4.15 has great AMD graphics support, but we are having trouble achieving over 30fps with Vega, for whatever reason, the second frame in the GL buffer just never displays on Vega. We are looking into it and thanks to the generous support from both companies and the community, we will have everything we need to work through those issues.

Again, massive thanks to everyone in the Level1 community, and especially Sapphire Technologies, Gigabyte/Aorus, and PLE Computers Australia – without their support, this project would not have been possible.

Level1, changing the world one community project at a time? :smiley:

A little teaser of what is to come :)
Monitor resolution issue on Looking Glass



still giving me

cannot open shm file ivshmem: Permission denied
cannot bind

is the /tmp/ directory fine if I leave the code as it is presented in the guide? Or should I point it to somewhere in my home directory?


What’s giving you the error? You’re going to need to be a bit more specific.


unless your user has access to /tmp point it to a folder in your home directory. Worked for me.


That’s one option. Another option is changing groups around. You could also run ivhsmem-server as qemu and add yourself to the qemu group. (if not already in there)


Hows this for a bug? or am i just doing something wrong?



Haven’t experienced that before.


Looks like the stride is out… what is the guest GPU?


Guest GPU is a EVGA GTX1080 FTW. Host is Fedora Rawhide kernel, 4.14.3


Can you try to change the guest’s resolution?

Also don’t run Looking Glass as root, add yourself to the qemu group so it can access the ivshmem server without the extra access.


Will take another crack at it tomorrow. Don’t think I got the permissions quite right on the ivshmem socket so it’s not able to connect without sudo for the moment.


No worries. The problem with the output is clearly a bug though, it’s not due to your setup.


Running this right now, works amazingly well! I get sub-60 frames with the client full-screened while playing games , but I suspect it’s due to using igpu on the host…

Can I suggest adding a flag to ignore all input on the client? There’s some funky behavior when trying to switch between windowed and fullscreen in i3 (it doesn’t work half the time). I got around this by commenting out all the keyboard/mouse events. It’d also be useful for those that have their special keyboard/mouse setups between guest and host.

Host: Arch Linux w/ intel gpu (intel HD 530)
Guest: Windows 10 w/ 980ti


How sub? and is it constant or dips?
Also try turning off mipmapping with the -m switch.

Just turn off the spice client in Looking Glass looking-glass-client -s


I’m having the same issue currently.


Can you please try with another resolution, seems to be related, the last report was running the same.
Edit: I think I know what it is, just want to confirm before I hack on it.


EDIT: Yes at 1920x1080 it works as expected. Not at 3440x1440. Also resizing the window doesn’t work.


Sorry I should have provided more info.

The fps on the client appears to be constantly lower - here’s a SS from just sitting idle in Overwatch:
A little hard to tell but the client is constantly at ~40-50fps while the game itself is much higher. Perhaps my processor is getting taxed from the CPU usage of these games; I don’t see the fps dips when running GPU benchmarks eg Heaven.

Also for the -s switch, it appears to turn off all events including window events, so things like resizing doesn’t actually re-adjust the render resolution?

Edit: mipmapping does not seem to make a difference either. Might be time to finally get a dgpu for the host…