Hacker News Reader

Comment by numpad0 | Hacker News Reader

Apparently there are $5-15 EDID "emulator" devices that are just an HDMI passthrough adapter with a fake EDID ROM that always reports common modes as 4K60/2K60/VGA. Apparent purpose is to get PS5 to work with quirky 4K TVs. A similar device called HDMI "dummy plug" allows GPU acceleration on quirky PCs without having a display, but the latter has no passthrough port at the back.

If that's all the author needs, that might be the path of least resistance.

View on HN

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.

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

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!

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?

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

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.

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?

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.

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).

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.

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

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).

These devices are also used among home theater enthusiasts as a hack to enable LLDV (Low Latency Dolby Vision) which causes the source device to perform tone mapping.

http://videoprocessor.org/lldv

https://www.avsforum.com/threads/alternative-devices-for-ena...

https://blog.semtech.com/demystifying-dolby-vision-for-pro-a...

The added benefit is you don't get a chance to brick your TV with a bad write.

No need to write to eeprom. On Linux, just load your custom EDID.

I returned OP's model display for a similar reason - except there was no HDR possible on Windows, even with the LG custom drivers. I also can't unsee the parallax on those models. It's pretty atrocious for the price.

Yeah, we still have loads of "EDID minders" left over from the RGB/VGA days. Little in-line boxes with DIP switches to set a given resolution and refresh so display hardware always reported the same spec to any laptop/desktop/device plugged in.

Not surprised there are similar for HDMI.

Indeed they are for Hdmi. I even saw some claiming to support hdmi 2.0 (4k @60Hz), but I have never seen one for Hdmi 2.1.

Unfortunately despite huge progress with resolutions, refresh rates and ability to use one cable for lots of stuff (usb-c) we went significantly backwards in KVMs. If all your devices speak hdmi 2.1 there are one or two 4way devices that claim 8K-hdmi 2.1 (made by easycoo?), but if you have usb-c or newer displayport devices that don't support passive hdmi dongles your out of luck.

As far as I know there is one device on the market (made by delock) that claims to support DP1.4 (4k@60hz),but it has no edid emulation and there are no pass through edid emulators for displayport 1.4... So every time you switch kvm your displays will act as if they're disconnected/reconnected. If you do actual work on two pcs and you switch a lot that's horrible.

So the tldr is: great modes, but why did nobody think of the kvm users when making those standards (by for example making monitor hot plug detect being able to be disabled from monitor menu?).

Reply on news.ycombinator.com