# Looking Glass: a KVMFR client for Windows guests with VGA PCI passthrough > Looking Glass is a C implementation of KVM FrameRelay for running a Windows virtual machine from a Linux host at low display and input latency. It ships as source, it needs shared memory configured for the guest, and the README points to the project website for the setup guide. **gnif/LookingGlass** — An extremely low latency KVMFR (KVM FrameRelay) implementation for guests with VGA PCI Passthrough. - Repository: https://github.com/gnif/LookingGlass - Stars: 5,718 · Forks: 328 - Language: C - License: GPL-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/gnif-lookingglass ## The problem Looking Glass solves for passthrough users A Windows guest with a GPU passed through by VGA PCI passthrough has no useful local console. The guest owns the physical card, so the host cannot simply show the guest's framebuffer in a window, and streaming the desktop over the network adds encoding and transport latency that shows up in mouse movement and video playback. Looking Glass addresses exactly that gap. It is a KVMFR (KVM FrameRelay) implementation: the guest side hands frames to the host through a shared memory channel, and the host client draws them and forwards input back. The README frames the intended audience plainly, describing a setup where you "use a Windows virtual machine from Linux with very low display and input latency". That is a narrower group than the generic remote desktop audience. You need a Linux host running QEMU/KVM, a Windows guest, and a passed-through VGA device. The current recommended path pairs the Looking Glass Indirect Display Driver (IDD) in the Windows guest with the Looking Glass Client on the Linux host. The project is written in C and licensed GPL-2.0. ## How the KVMFR channel moves frames and input The mechanism is a shared memory buffer that both sides map. The README lists configuring shared memory for the virtual machine as step two of the setup, which tells you the buffer is a QEMU-level resource rather than something the client allocates on its own. On the guest side, the Looking Glass IDD presents a display device to Windows, and the guest application writes the captured frame into that shared region. On the host side, the client reads from the same region and renders it, so the frame never passes through an encoder, a socket, or a compositor on the guest. Input travels the opposite direction over the same channel. The repository layout reflects this split: client/ holds the Linux client, host/ holds host-side components, idd/ holds the Indirect Display Driver, and common/ and vendor/ hold code shared between them. module/ and obs/ sit alongside those, and doc/ contains the documentation source. The practical consequence of this design is that latency is bounded by the guest capture path and the host render path, not by network conditions. It also means the channel is only as good as the shared memory configuration behind it. ## Installing the Looking Glass client on Linux The README is direct about distribution: "The Linux client is currently distributed as source code and must be built before it can be installed." There is no package install step documented in the README, so the first real task is producing a binary. The README also carries a warning that matters if you clone the repository rather than downloading a release archive: "This project contains submodules that must be checked out if building from the git repository!" For anyone who is not developing Looking Glass, the README's instruction is to download the source archive from the website instead: ```bash # README: if you are not a developer, download the source archive from # https://looking-glass.io/downloads rather than cloning the git repository ``` The end-user guide at https://looking-glass.io/docs is where the README sends you for the full sequence, which it summarises as four steps: build the Linux client, configure shared memory for the virtual machine, install the Looking Glass IDD in Windows, then install and run the client. The README does not reproduce the build commands, the shared memory configuration, or the IDD installation steps, so those must come from the documentation rather than from this repository's front page. If you are working from the documentation source itself, the README gives one command that renders it locally as HTML: ```bash make html ``` That target requires python3-sphinx and python3-sphinx-rtd-theme to be installed, according to the README. What you should see after that is a local HTML build of the documentation in the doc/ tree, which is useful when you want to read the setup guide offline while working through the guest configuration. ## Where Looking Glass is the wrong tool The setup cost is the first limitation, and it is structural rather than incidental. Looking Glass assumes a virtual machine whose shared memory has been configured for it, a Windows guest with the IDD installed, and a Linux host client built from source. If any of those three is missing, the client has nothing to attach to. That makes it a poor fit for a workstation where you occasionally need to see a Windows desktop, and a poor fit for remote access over a network, where a display protocol is the right layer and KVMFR adds nothing. The README also does not document rollback, so if you install the IDD in a guest and want to return to a plain virtual display, the front page gives you no procedure for that; you would be working from the documentation or from your own snapshot discipline. Version cadence is worth noting as well. The recent releases listed for the project are B7 (2025-03-06), B7-rc1 (2024-03-09) and B6 (2022-12-20). That is a slow release rhythm, and it means the build you produce from the repository may sit ahead of the last tagged release. The last push to the repository was on 2026-09-01, so work continues between releases, but anyone who needs a stable, versioned artifact should plan around the tags rather than the tip of the branch. ## Looking Glass compared with network display streaming The obvious alternative for getting a Windows guest onto a Linux desktop is a network display protocol, the kind that encodes frames in the guest and decodes them on the client. That approach has real advantages Looking Glass does not: it works without PCI passthrough, it crosses machine boundaries, and it does not require shared memory to be configured on the hypervisor. The trade-off is the encode and decode path. Every frame is compressed on one side and reconstructed on the other, and input events make a round trip through the same stack. Looking Glass removes that layer entirely by keeping the frame transfer inside the host's memory. It is a narrower tool that wins on a specific axis and loses on generality. If your guest has no passed-through GPU, or if the machine you are sitting at is not the machine running the hypervisor, the network protocol is the correct choice and Looking Glass cannot substitute for it. The comparison is not about which is better in the abstract; it is about whether the guest and the client share a physical host and a shared memory segment. ## Licence, maintenance and the cost of staying current Looking Glass is licensed GPL-2.0, and the repository includes a LICENSE file at the top level along with AUTHORS and CONTRIBUTORS. For an end user running the client on their own machine, that is the ordinary situation of using GPL software locally. It becomes a consideration if you intend to redistribute a build or link the code into another product, because GPL-2.0 carries obligations that permissive licences do not. That is a question for your own legal review, not something the README answers. On maintenance, the repository is not archived and the last push was on 2026-09-01, so the code is being touched. The release history is sparse, with B6 in late 2022 and B7 in early 2025, so the practical upgrade cost is not a stream of small version bumps you apply with a package manager. It is a rebuild: you fetch the source, build the client, and keep the guest-side IDD and the host-side client in step. Anyone running Looking Glass should expect to own that build process, because the README offers no packaged path around it. ## Conclusion Adopt Looking Glass if you already run a Windows guest with VGA PCI passthrough on a Linux host and you want to drive it from the host rather than over a network display protocol. Do not adopt it if you want a prebuilt binary, a one-command install, or a setup that does not require editing shared memory configuration for the virtual machine. Before committing, read the end-user guide at https://looking-glass.io/docs and check the current requirements there, because the README does not carry them and the client is distributed as source that you must build. ## FAQ ### How do I install Looking Glass on Linux? The README states that the Linux client is distributed as source code and must be built before it can be installed. It points to the end-user guide at https://looking-glass.io/docs for the complete process: build the client, configure shared memory for the virtual machine, install the Looking Glass IDD in Windows, then install and run the client. ### How do I use Looking Glass with a Linux host? The recommended setup pairs the Looking Glass Indirect Display Driver in the Windows guest with the Looking Glass Client on the Linux host, which lets you use a Windows virtual machine from Linux with low display and input latency. The README directs you to the documentation for the current requirements and setup guide. ### Can I install Looking Glass on Ubuntu or Arch from a package? The README does not document a package install for any distribution. It says the Linux client is distributed as source code and must be built before it can be installed, and it points to https://looking-glass.io/docs for the setup guide. ## Sources - [gnif/LookingGlass on GitHub](https://github.com/gnif/LookingGlass) - [Issues](https://github.com/gnif/LookingGlass/issues) - [License: GPL-2.0](https://github.com/gnif/LookingGlass/blob/master/LICENSE) - [README](https://github.com/gnif/LookingGlass/blob/master/README.md) - [Releases](https://github.com/gnif/LookingGlass/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gnif-lookingglass