"modernizing to HDMI" by writing EDID into ~2012 DualLink-DVI-only 2560x1440 display

[galkinvv]

Hello! I have a 2012 DualLink-DVI-only 2560x1440 display - the "No scaler, no menu, no overclocking, no audio, but not-bad panel" variant of Yamakasi Catleap Q270 27"

It was going to become unused since only selected GPUs can provide DualLink-DVI signal (the last one are some variants of RTX 3050 and RX5500 I suppose). The classic solution is "use active DP->Dual DVI converter or forget about it" but I was interested in checking how it would behave given a higher frequency single-link input with a passive hdmi->SIngle DVI cable. Thanks to ToastyX we have a great "EDID writer tool" and the good news are that at least my instance had NOT write protection on EDID EEPROM.

Result: it works fine in 35-55Hz range for 2560x1440; 60Hz was sometimes unstable in my experience. So "a monitor that can't be plugged anywhere" is turned into "55Hz hdmi 1440p monitor" given passive cable and 5 minutes for EDID flashing.

I performed several experiments and attach .zip with several EDID variants
  EDIDModToFixDualLink-2025.2.zip (Size: 75.91 KB / Downloads: 11)

• recommended 40-54Hz YamakasiQ270-54HZ2025.1-edid-256byte.bin
  EDID with a 3 entries for 40-50-54Hz. The 40Hz kept for compatibility with booting stage of integrated intel GPUs, since having only faster entries with 165+Mhz pixelclock caused "no monitor" beeps from intel GPU and "no picture until windows is loaded". So, after booting to desktop with this EDID - increase the frequency via standard windows settings.
• failsafe 40Hz-only YamakasiQ270-ANY40HZ2025.1-edid-256byte.bin
  EDID with a single 40Hz entry, fitting in pre-HDMI 165Mhz pixelclock limit. This variant should provide maximum compatibility with different signal sources, especially sources not capable of providing >165Mhz pixelclock
• experimental 40-60Hz YamakasiQ270-60HZ2025.2-edid-256byte.bin
  EDID with a 5 entries for 40-50-54-56-60Hz. Similar to the recommended variant but with higher frequencies. It's experimental, so have caveats:
  • 56 Hz uses same ~217.5Mhz pixelclock similar to 54Hz mode, but absolutely reduced blanks still handled by a specific monitor model. Blanks are so small that while it is listed&works on Intel and Nvidia, the AMD driver excludes this mode from an available list treating is as "unbelievable")
  • 60 Hz with 241.5Mhz pixelclock is not very stable in my experience. With some sources it "works almost always" but for most others it sometimes gives a black screen, and only 3-4 poweroff-wait-on by the monitor button gives the monitor the ability to sync with input signal and start displaying
    

Since my monitor was "just writable" - after writing those EDIDs it start be useful with any signal source, no ClockPacther/CRU needed. In theory if some similar monitors are not writeable - those EDIDs can be activated another ways:

• via importing it in Custom Resolution Utility
• Or to avoid effect of "picture not visible before OS boot" - the writable EDID EEPROM can be injected in the form of a trivial extra device that provides only writable EDID and the the video signal is passing through. The so called "HDMI lock emulator" in the role of writable-EDID-injector between signal source and HDMI cable. Cheapest one is in a picture below (no need to disassemble it; internals are shown below just for reference). Write EDID into it and always use the monitor with this emulator.
  

A bit more obscure cases like writing EDI via Linux on integrated intel GPU presented at the project page

[ToastyX]

I've done this before with the same monitor. It can also handle FreeSync with an AMD GPU. Here is an example of what I did:

  catleap-hdmi-freesync-60.bin (Size: 256 bytes / Downloads: 8) - 40, 50, 55, 60 Hz
  catleap-hdmi-freesync-55.bin (Size: 256 bytes / Downloads: 10) - 40, 50, 55 Hz

I wanted to post this somewhere, but overclock.net seems dead these days, and nobody asked me about these monitors recently, so I never had the chance to suggest this method.

I didn't include the range limits descriptor or video capability data block because they aren't really needed. Even though technically EDID 1.3 requires the range limits descriptor, I never ran into anything that cared. You don't really need the failsafe version as long as the first detailed resolution is 2560x1440 @ 40 Hz because anything beyond 165 MHz pixel clock will be ignored on systems that don't support it.

I also found 60 Hz to not always be stable, so I included a 55 Hz. You shouldn't make the vertical blanking less than 5 because some GPUs can't handle that. I just made it 10 to make the refresh rate exact. Also 120 horizontal blanking is too close to the edge of what the Catleap can handle at 60 Hz. It seems to depend on the temperature and might vary slightly between units, so 128 would be better. I just made it 140 to make the refresh rate exact.

Also not all EDID emulators are writable. The Evanlak ones aren't writable. Which one do you have?

[galkinvv]

Thanks for sharing your experience and especially the estimation on minimal blanking! My experiemnts was in too hurry (I gave a monitor to friend after this fix).

Can I place yours freesync EDID variant on my page near another variants (with attribution to you)?

I plan to share all this to repair-community-forum that are doing different hardware repairs and doing such mods may be easy/useful-to-know for them.

Regarding the range limits - I just edited things to minimize the errors reported by edid-decode tool (https://git.linuxtv.org/v4l-utils.git/tr...-block.cpp) since this is the first time I edid EDIDs.

(01-10-2025 03:18 AM)ToastyX Wrote:  Also not all EDID emulators are writable. The Evanlak ones aren't writable. Which one do you have?

I have exactly one on the photo its "noname USD$3-5 on aliexpress with 'source' and 'sink' labels". They name it "HDMI Lock/Screen Signal Holder", lol.

My was writeable. I didn't know exact eeprom model they use, labelling is too common, but in addition to the standard 0x50 address it hase something unkwnown to me at address 0x58:

Code:

No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01    ????????????????
50: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01    ????????????????
60: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01    ????????????????
70: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01    ????????????????
80: 44 57 4b 34 36 32 0c 06 31 05 2a c1 00 00 00 00    DWK462??1?*?....
90: 44 57 4b 34 36 32 0c 06 31 05 2a c1 00 00 00 00    DWK462??1?*?....
a0: 44 57 4b 34 36 32 0c 06 31 05 2a c1 00 00 00 00    DWK462??1?*?....
b0: 44 57 4b 34 36 32 0c 06 31 05 2a c1 00 00 00 00    DWK462??1?*?....
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

I didn't tried writing there to avoid locking it.

However there is a bad thing about this EDID Injector - it can't handle passthrough of high-frequency pixel clock - I experimented with another, 4k monitor.
It handles 2560x1440@60 but fails on 4k@60 or 2560x1440@120. I think that it has pourely routed differential pairs. You can see on the photo that pairs on different sides has different lengths - non-stright near eeprom and stright on the other side. So unfortunately it is not "a silver bullet for EDID modding"

[ToastyX]

(01-10-2025 03:57 AM)galkinvv Wrote:  Can I place yours freesync EDID variant on my page near another variants (with attribution to you)?

Sure. I've updated the post to have two versions, one with 60 Hz and one without. Another consideration I forgot to mention is the GPU might not clock down when idle if the vertical blanking is too low, so I've adjusted 55 Hz to have enough vertical blanking. 60 Hz still has reduced blanking because these monitors seem to have trouble with that.