[HN Gopher] Modifying an HDMI dummy plug's EDID using a Raspberr...
___________________________________________________________________
Modifying an HDMI dummy plug's EDID using a Raspberry Pi
Author : zdw
Score : 161 points
Date : 2025-06-15 16:00 UTC (6 hours ago)
(HTM) web link (www.downtowndougbrown.com)
(TXT) w3m dump (www.downtowndougbrown.com)
| zdw wrote:
| You can also buy these with a passthrough, which is useful for
| older systems that balk at higher resolution monitors.
|
| I have a 2011 era AMD FX8350 system where the onboard 880G
| northbridge+video chipset doesn't output video over HDMI
| correctly with a 4k display. Hooking up one of these inline to
| tell it to send a 1080p image works great, which the monitor does
| a 2x integer upscale to 4k.
| dougg3 wrote:
| I also have a couple of passthroughs -- I probably should have
| mentioned them in the post as another option. The one I have is
| fancy -- it can read the EDID from a monitor, save it, and use
| it as an override for another monitor.
|
| Another awesome thing is it can force the monitor to always be
| detected. One of my monitors virtually unplugs itself when I
| shut it off, which causes a bunch of issues for me, and the
| passthrough completely solved it. The one I use is the HD-EWB
| by THWT.
| gadiyar wrote:
| Doug, thanks for mentioning this. I didn't realize pass-
| through ones existed. I'll check out the one you have. Nice
| article btw.
| dougg3 wrote:
| Thank you! Hopefully it works for you.
|
| I guess I should reword the way I said something in the
| previous message: when I said "it can force the monitor to
| always be detected", I really should have said "it forces
| the monitor to always be detected".
| avidiax wrote:
| One caveat of these dummy plugs is that they don't do HDCP. They
| handle the typical use case of forcing a specific resolution
| output for headless machines rather well, but fail for the use
| case that you need to run something that expects HDCP.
|
| This seems a good place to ask: does anyone know of a good
| solution like this HDMI dummy plug, but that negotiates HDCP? I
| need to test video streaming apps that require HDCP to play at
| full resolution, but it is inconvenient to have a full TV for
| every test.
|
| The one solution I've found is an HDMI multiviewer, which seems
| to negotiate HDCP to each port individually.
| mschuster91 wrote:
| Try one of these HDMI splitters that are more or less openly
| advertised as "HDCP strippers" on Amazon.
| crazysim wrote:
| I think multiviewer might have been a synonym for that.
|
| I wonder if the chips on these dummy plugs are powerful
| enough to hack in HDCP support though.
| aappleby wrote:
| The dummy plugs are literally just a 256-byte eeprom hooked
| to the I2C lines, there's nothing else inside the shell.
| dcan wrote:
| Terminating HDCP is difficult, you'd have to downgrade it to
| HDCP 1.4 and then have a 1.4 'compliant' (see: device on the
| end for it to be a dummy monitor. If you need anything newer
| than HDCP 1.4, it's likely not possible.
| tverbeure wrote:
| I did a tear down of this Monoprice dongle:
| https://tomverbeure.github.io/2023/11/26/Monoprice-
| Blackbird....
|
| It terminates as an HDCP 2.0 endpoint and converts to HDCP
| 1.4. You'd still need an HDCP 1.4 sink to make it work
| though.
| avidiax wrote:
| I'm using the Monoprice multiviewer. It negotiates HDCP
| without a display attached. Other than being a bit big and
| expensive, and being unable to strip HDCP, it's a good
| solution.
|
| I found the same device in generic packaging on AliExpress,
| but haven't had the chance to order that version, yet.
|
| There are lots of professional SDI converters and such, but
| they are either $3k+ or "call for price".
| kevin_b_er wrote:
| That was written by you?
|
| I don't agree with this section:
|
| > The HDCP converter simply announces itself as a final
| video endpoint... yet still repeats the content to its
| output port. Without a very expensive HDMI protocol
| analyzer, we can't check if the source is tagging the
| content as type 0 or type 1, but there is no reason now to
| think that it's not type 1.
|
| There's no magic in the HDMI protocol that says type 1 vs
| type 0. Its just another HDCP message over DDC, but it is
| only sent to repeaters. In this case, since the HDCP
| Repeater is lying about not being a repeater, it isn't
| getting sent the StreamID Type information.
| ndiddy wrote:
| I use this HDMI splitter. It lets you either set a
| preprogrammed EDID, or learns an EDID from whatever you plug
| into HDMI output 1, and then shows up as a connected monitor
| for as long as the splitter's plugged in without having to
| connect anything to the outputs. I believe it negotiaties HDCP
| between the computer/console/whatever and the splitter, then
| sends the signal to the output monitor without HDCP.
| https://www.amazon.com/dp/B07VP37KMB
| amelius wrote:
| I have a different usecase. I have an embedded system that
| sends out HDMI. However, its boot screen is something I want to
| replace by another HDMI stream (a static image would suffice).
| I specifically don't want to change anything on the embedded
| system for a thousand reasons I won't go into. How do I cheaply
| and robustly do this?
| hedora wrote:
| Aliexpress sells things that claim to terminate hdcp and
| forward hdmi. Caveat emptor.
| kachapopopow wrote:
| I find it crazy that the signal between our monitors and
| desktop computers is encrypted when these exist.
| dishsoap wrote:
| Fun tip: the same process works to modify the edid stored on a
| typical monitor or laptop screen. Sometimes you can even change
| various settings on the tcon by writing to other i2c addresses.
| You also don't need a raspberry pi, any computer works.
| crtasm wrote:
| The author recommends using a Pi while noting it's not a
| requirement
|
| >If you attempt these commands on a PC, it's possible that you
| could accidentally flash hardware that isn't an EDID, like a
| RAM module's SPD EEPROM.
| dishsoap wrote:
| True, although the i2c controller that the dimms are
| connected to is an entirely separate device from the i2c
| controller in the gpu that's connected to the display ports.
| As long as you know what you're doing the risk is not
| significant.
| dougg3 wrote:
| Yeah, if you are 100% confident you're using your GPU's I2C
| controller it's probably fine, but the reason I warned
| about it repeatedly in the post was because I stumbled upon
| this GitHub issue where two people accidentally flashed
| their RAM SPD:
|
| https://github.com/bulletmark/edid-rw/issues/5
| netsharc wrote:
| Makes me think of this anecdote from Linus Torvalds'
| officemate, from (1)
|
| > At one point, Linus had implemented device files in
| /dev, and wanted to dial up the university computer and
| debug his terminal emulation code again. So he starts his
| terminal emulator program and tells it to use /dev/hda.
| That should have been /dev/ttyS1. Oops. Now his master
| boot record started with "ATDT" and the university modem
| pool phone number. I think he implemented permission
| checking the following day.
|
| 1) https://liw.fi/linux-anecdotes/
| ajb wrote:
| The flash chip usually has a write enable/disable pin and most
| monitors and TVs will wire it to prevent writes to the EDID. I
| would guess only cheap ones don't bother. It's risky as without
| protection, a voltage glitch during a read can turn it into a
| write and trash the flash.
| Aurornis wrote:
| > the same process works to modify the edid stored on a typical
| monitor
|
| That would be a strange oversight by the hardware developers.
|
| Typically they would buy pre-programmed EPPROMs and then place
| it on to a board where the write enable pin is never pulled
| high.
|
| It would be strange to put an EEPROM into a product like a
| monitor and leave it writable, but I've seen stranger things on
| shipping hardware.
| ajb wrote:
| Yeah,it shouldn't happen - but I've seen it happen. What's
| worse, the first batch we got from that place weren't flashed
| with an EDID _at all_ - and were shipped directly to
| customers (who mostly didn 't notice, because the main
| product it connected to had default that worked, but it
| wasn't optimal. Meant none of those screens could be used
| with a normal laptop though). Ironically the combination of
| the two issues meant we could have fixed the EDID in the
| field, but we didn't dare in case we bricked someone's $x000
| TV.
| crote wrote:
| Modern monitors don't even use an EEPROM chip for EDID
| anymore. The I2C bus is hooked up to a microcontroller inside
| the monitor, which allows it to implement Display Data
| Channel. This way you can tune things like display brightness
| and color profile from an application running on the
| computer, instead of messing around with the monitor's OSD.
|
| Tools like ddcutil aren't very well-known, but they can be
| quite useful if you want to do something like DIYing a KVM
| switch by just having the PC tell the monitor to switch to a
| different input!
| awaymazdacx5 wrote:
| hex dump for the USB ibus2 plug extract is concatenated to EDID
| aappleby wrote:
| Minor note for those wanting to try this at home - these cheap
| dummy plugs only have a 256 byte eeprom, which is not enough for
| storing the various extended EDID blocks needed to specify high-
| refresh high-resolution configs. If you just want 1080p60 they're
| fine, but you won't be able to simulate a 4k240 monitor with
| them.
|
| Also, some of them have the write-protect line pulled high (or
| low? don't remember) and you'll need a bit of surgery to actually
| write to them.
| 01100011 wrote:
| Does anyone know of a cheap DisplayPort EDID emulator to fix
| issues with a KVM and linux? Last time I checked, they were much
| more expensive than HDMI, to the point where it would be better
| to buy a new KVM.
| crote wrote:
| The issue here is that DisplayPort doesn't use a basic EEPROM
| hooked up to an I2C bus for EDID. Instead it uses the high-
| speed DisplayPort-specific AUX bus, which is _significantly_
| more complicated to mess around with. Heck, I don 't think you
| can even find any decent documentation about it without joining
| VESA and signing a bunch of NDAs.
| slipheen wrote:
| Relatedly, is there a good archive of EDID binaries somewhere, or
| a better program to make them?
|
| I have an nice programmable EDID emulator plug, and I can clone
| my monitor and others, but there's some times there's a specific
| resolution or feature I want to set and I don't have a way to.
| (Like 8K with DSC, etc)
|
| I'm aware of https://github.com/bsdhw/EDID but it's rather
| limited in terms of modern monitors.
|
| I've also written by own using
| https://www.analogway.com/products/aw-edid-editor but getting all
| the nuances of various modes, and setting preference order, etc,
| is rather difficult, at least for me :)
| ashirviskas wrote:
| Why are dummy plugs a thing? What can you do with them that you
| cannot do in software? (asking as a person who had no issues with
| having 18 virtual displays and no dummies).
| dd_xplore wrote:
| I have a moded chromebox(booting windows and linux), which
| refuses to boot without any video device attached to hdmi port.
| So I had to use a dummy plug.
| tshaddox wrote:
| Presumably it's for devices which do not have easily modifiable
| software.
| pfych wrote:
| Dummy plugs are a lot easier for most people. I added a fake 4K
| monitor to my desktop via software for remote game streaming,
| and it was a lot more complicated than I expected[^1].
|
| [^1]: https://pfy.ch/programming/4k-sunshine.html
| SXX wrote:
| A lot of OS / GPU / driver combinations dont actually let you
| setup virtual displays with arbitrary settings. And you might
| want it for setting streaming with OBS or games streamings via
| Steam / Parsec / etc.
|
| Some years ago it's kind a worked for me on Linux with Xorg and
| open source drivers and Windows with Nvidia, but when it comes
| to MacOS or Windows+AMD or Intel GPU it simply doesn't work
| that well.
___________________________________________________________________
(page generated 2025-06-15 23:00 UTC)