[thomastjeffery]

My favorite use case is Looking Glass.

Want to play video games that only run in Windows, but don't want to leave Linux? You can run Windows in a virtual machine and "passthrough" your GPU's PCIe slot. The advantage is that Windows can get the full performance of your GPU. The disadvantage is that it took the whole GPU away from your Linux host, along with whatever display it's attached to. You can use a second GPU for your Linux host (i.e. your integrated CPU one), but that needs its own physical display.

You can use Looking Glass to copy the framebuffer from your Windows guest so that you can redraw it on your Linux host. That way you can have your Windows guest in a window, and never have to leave your Linux desktop again. The big caveat is that your Windows guest needs a valid display connected, or it will never draw any frames to begin with. You can plug in a spare monitor that you never actually look at, or you can spoof one.

[nullwarp]

I'll add that this setup works great, ran it for a good couple of years before finally dropping it (not for any looking glass reasons, eventually just didn't need it anymore with proton).

Also loved that it integrated so well into OBS directly to stream from!

[cevn]

Wow this is so cool… might have to try it!! The real hacker news is in the comments!

[Roark66]

So this is what those non-pass through "displayport edid emulators" are for!

[hsbauauvhabzb]

Can you commit that to the looking glass readme.md - having skimmed their GitHub, it was unclear what it actually did.

Out of curiosity, what is the performance like? Presumably good for desktop use, but how about fps sensitive games?

[davkan]

Latency is like a couple milliseconds i believe. Looking glass uses shared memory between the host and guest for the framebuffer.

[namibj]

I'd expect vsync-to-host to be the default, though something more like triple buffering should also work (with the host atomically grabbing the latest completed buffer to compose just-in-time for composing to finish before the RAMDAC starts the first line... so roughly grabbing at the start of blank, spending vblank compositing, and no tearing after vblank).

So in total, on the order of a millisecond additional latency if you pass vsync timing alignment down, and no variable refresh rate.

But the latter is barely compatible with compositing in general. All techniques for handling a VFR video stream in a window should also apply to the uncompressed/shared memory looking glass stream.

[Cloudef]

It's pretty cool, of course the need for this kind of setup has become pretty rare as proton runs pretty much everything nowadays (apart from those pesky anti-cheat games).

[Dalewyn]

Genuine question, but are multiple inputs on the monitor not a consideration for your scenario? Or are multiple inputs on a single monitor unsuitable for this purpose?

[davkan]

Multiple inputs works fine with gpu pass through, but regularly switching monitor inputs is honestly a pain depending on your monitor. Its like a 10 second process for my monitor.

Also people running a setup like this are using the Linux host as their main desktop. If you only have one monitor and are switching inputs you lose your whole workflow on Linux host when using the vm. It’s better with dual monitors but I’d still prefer looking glass.

[Dalewyn]

The switching process can be disrupting depending on how it works, I agree. But even so far as to include grabbing a spare monitor "you never actually look at" or spoofing one? For that, I admit I can't see why just using one of the inputs on the monitor you already have isn't an option.

Unless of course the monitor doesn't have additional inputs (but it was never specified the hypothetical monitor is ancient) or they are all already used (again wasn't specified).

[thomastjeffery]

For Looking Glass, probably not: the guest OS will probably notice the monitor switching away from its connected input, and will stop drawing frames accordingly.