Windows comes up at 1920x1080, and 2560x1440 is not even listed as an available resolution.
Audio through the KVM does not work at all - Windows shows no HDMI audio endpoint for it, so there is no sound in the remote session.
Switching the device identity/EDID preset to something else and back immediately restores both the 2560x1440 resolution and the audio device. This happened with a custom EDID, with the factory ViewSonic preset, and (based on Windows' stored monitor history) with the default GL.iNet EDID (GLIC21C) as well.
Root cause (verified with EDID dumps from the Windows monitor driver)
After a host reboot, the EDID the GPU receives from the KVM is only block 0 (128 bytes), even though byte 126 of that block declares 1 extension block. The CTA-861 extension - which carries the HDMI Vendor-Specific Data Block and the basic-audio flag - never arrives.
Both symptoms follow directly from that one missing block:
No HDMI VSDB → the Intel driver treats the sink as DVI and applies the single-link 165 MHz pixel-clock cap. 2560x1440@60 needs 241.5 MHz, so it's dropped from the mode list; 1920x1080@60 (148.5 MHz) becomes the maximum. This is why 1440p "disappears".
A DVI sink with no audio capability data → Windows creates no HDMI audio endpoint, so sound is dead until the monitor is re-detected with the full EDID.
After toggling the EDID preset (which cycles hot-plug), the host reads the full 256 bytes and everything works - until the next host reboot. A real monitor (LG ultrawide) on the same GPU reads its full 256-byte EDID on every boot, so the host's DDC side is fine.
So: on the first DDC read after the host's HDMI link comes back up, the KVM (LT6911C DDC) serves block 0 but fails to serve the extension block (second 128-byte segment). A subsequent HPD cycle fixes it.
Suggested fix
Ensure the complete 2-block EDID is available to DDC reads from the moment the KVM's HDMI input is (re)initialized after host link-down/link-up - or pulse HPD once the full EDID is in place.
Workaround that confirms the diagnosis
Installing the full 256-byte EDID as a Windows EDID_OVERRIDE (what CRU does) makes the host boot straight into 2560x1440 with working audio, with the KVM unchanged.
Related threads (same subsystem, not the same bug)
[BUG] Video Link negotiation Issue with GL-RM10 V1.8.2 - LT6911C re-init problems after HDMI link re-negotiation on the RM10, with kernel logs. My issue occurs in the same window: the first DDC/EDID read after the host's link returns.
Edid problems - firmware re-applying the EDID on monitor events (fixed in 1.7.2), showing the EDID is rewritten around link changes.
Attached: the sanitized diagnostic report from the Windows monitor driver (captured after a host reboot, before any workaround was applied) and the truncated 128-byte EDID exactly as read post-reboot. I can provide the full 256-byte EDID and additional captures on request. glkvm-rm10-edid-diagnostic-after-reboot.txt (5.0 KB) glkvm-rm10-truncated-edid-128bytes.hex.txt (455 Bytes)
Hi,
Thanks for providing the detailed information. Please export the syslog and share it with us.
Also, could you please confirm if the issue occurs every time after restarting the host?
@Thalia Thanks for the quick response! Syslog attached (exported via Help & Support > Export Log Files, V1.10.0 release4). I removed the wifi/network/cloud config files and masked IPs/MACs with stable placeholders for the public forum - all log content, timestamps, and HDMI/EDID data are untouched (see README in the zip). If you need the full unmodified bundle, tell me where to send it privately.
To confirm: yes, it happened on every single restart of the host, without exception, over several months - with a custom EDID, with the factory ViewSonic preset, and (per Windows' monitor history) with the default GL.iNet EDID earlier. The only reason it no longer bites me is the Windows-side EDID_OVERRIDE workaround, which just masks it on the host.
The exported log actually captures the mechanism. At the host restart (Sep 2, 08:18:15 daemon-local / 13:18:15 kernel-UTC - note the export mixes both clocks):
So on every host power/link cycle the LT6911C is reset and its EDID re-programmed by lt86102sxe_setup. And here is the smoking gun: the block 0 the daemon writes in that log has checksum 0xEA, but the EDID my Windows host actually captured at that same boot is a different block 0 - checksum 0x97, several standard timings blanked to 01 01 - with no block 1 at all (the 128-byte dump attached to the first post). In other words, the host's GPU read the chip's EDID after the reset but before programming finished, and got whatever pre-programming/default content the chip had - which declares 1 extension block it can't serve. Windows' per-monitor registry history contains both variants (VSC2F34...*_97 and ...*_EA), so the race has been running on every boot; whichever side wins decides between 1440p+audio and DVI-fallback 1080p with no audio.
Suggested fix follows directly: after the chip reset, hold RX HPD low until both EDID blocks are programmed, and only then release it (or pulse HPD once programming completes). glkvm-rm10-syslog-20260903-sanitized.zip (231.8 KB)
Thanks for providing the detailed syslog! From the logs, our merged EDID does include HDMI audio support, but Windows somehow only reads an incomplete 128-byte EDID (missing the CTA extension block), which causes the 1080p limit and missing audio.
This is likely an EDID/DDC timing issue during host startup. Our R&D team is currently investigating and optimizing the HPD/DDC timing logic to ensure complete EDID delivery across different host environments.
In the meantime, could you share the detailed steps of your Windows EDID override workaround? This would be helpful for other users facing the same issue before we roll out a fix in a future firmware update.
@Thalia Great to hear R&D is on the HPD/DDC timing - that matches everything we measured. Happy to share the workaround. It's a standard Windows mechanism (the monitor driver's registry EDID_OVERRIDE, documented by Microsoft as "Overriding Monitor EDIDs"): you pin the KVM's complete EDID in the registry, so even when the boot-time DDC read comes back truncated, Windows builds its mode list from the full EDID. Nothing changes on the KVM, and it's fully reversible.
Steps (works for any preset/resolution, RM1 or RM10, any GPU):
Get the KVM display into its good state first - if you're stuck at the wrong resolution, switch the EDID/device-identity preset away and back in the KVM console so the full resolution returns. This matters because the override must be captured from the complete EDID.
Run the attached script with no arguments (no admin needed) - it lists your monitors, shows which EDID is complete vs truncated, and gives you the KVM's PNP ID: powershell -ExecutionPolicy Bypass -File .\GLKVM-EdidOverride.ps1
In an elevated PowerShell, install the override (add -PnpId <id> from step 2 if you have more than one monitor): powershell -ExecutionPolicy Bypass -File .\GLKVM-EdidOverride.ps1 -Install
The script captures the live EDID, verifies checksums and the HDMI vendor block, and refuses an incomplete EDID, so it can't pin the broken boot-time copy by mistake.
Restart Windows - it should come up at full resolution with audio working.
Undo any time with -Install's counterpart -Uninstall (elevated). Two caveats worth documenting for other users: the override is tied to the monitor identity the KVM emulates, so after switching to a different EDID preset you re-run -Install while that preset is working; and if a host reads no EDID at all at boot (rather than a truncated one), the override can't attach - that case needs the firmware fix.
For people who prefer a GUI, ToastyX's Custom Resolution Utility (CRU) does the same thing - it's free from monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU (in backticks rather than as a clickable link because new forum accounts are limited to one link per post, and the script attachment below uses up my one): with the KVM in its good state, open CRU, select the KVM display, click OK, and run its restart utility. The script's -SaveEdid also exports the captured EDID as a .bin if anyone wants to inspect it or import it into CRU.
The file is attached as .txt because the forum doesn't accept .ps1 - just rename it after downloading. Happy for you to fold any of this into a KB article until the firmware fix ships, and glad to beta-test that fix on my unit when it's ready. GLKVM-EdidOverride.ps1.txt (12.4 KB)