[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  : 289 points
       Date   : 2025-06-15 16:00 UTC (1 days 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.
        
               | tverbeure wrote:
               | You're probably right.
        
             | Sporktacular wrote:
             | Great teardown. Can these things remove HDCP altogether? It
             | seems like if it can report that the sink is HDCP2.x then
             | it can do so even if it has no compliance at all right? So
             | that would mean it streams an encrypted stream to something
             | that needs to then still do the decryption? These devices
             | seem like they'd be underpowered to do that in real time at
             | 18 Gb/s.
        
               | tverbeure wrote:
               | I assume the silicon can do it, but it's not exposed to
               | the user, because that would almost certainly be a
               | license violation.
        
         | 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?
        
           | atoav wrote:
           | Probably not the most elegant solution, but there are many
           | HDMI switchers out there that can be talked to using gpio
           | and/or RS-232. You could use one of those and a Raspi, feed
           | the image in from the Raspi, detect the power of your
           | embedded device via GPIO and then switch over to the other
           | HDMI input. Whether that is a feasible solution mostly
           | depends on other requirements, e.g. regarding power
           | consumption or space.
           | 
           | I used a similar solution once in an AV context and it has
           | been running reliably for years now.
           | 
           | If you want something less hacky Blackmagic has the Atem
           | Mini, a good HDMI switcher that can also store multiple
           | stills and can be switched via ethernet (among other things)
        
         | 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.
        
             | wkat4242 wrote:
             | Yes though for monitors displayport is better anyway and it
             | doesn't do hdcp.
        
               | wolrah wrote:
               | DisplayPort has supported HDCP (as well as its own DRM
               | scheme DPCP) since version 1.1.
               | 
               | I agree that DisplayPort was better for monitors, but
               | HDMI has basically become DisplayPort so these days
               | they're more or less two sides of the same coin. Both use
               | data packets over fixed rate links now.
        
               | AshamedCaptain wrote:
               | You may be thinking of HDMI vs DisplayPort over USB-C,
               | because otherwise they couldn't be more different. In any
               | case, HDMI is still heavily patent and royalty
               | encumbered, to the point it is going to be difficult for
               | opensource GPU drivers to support native HDMI 2.1 or
               | higher going on, while DisplayPort is still royalty free.
               | 
               | The situation is so bad Intel has pretty much skipped
               | native HDMI ports in recent chipset graphics to focus on
               | DP only (motherboards can still install off the shelf
               | DP->HDMI converters), while on AMD the newer HDMI
               | features won't be supported at all on Linux.
        
               | kachapopopow wrote:
               | yep, I'm running an hdmi to dp converter to make linux
               | work.
        
             | phh wrote:
             | What's even crazier is that we get the negative of DRM but
             | none of the upside. I have a 4k hdmi 2.0 TV without hdcp 2,
             | so no 4k content without the "splitter". Also any
             | interoperability issue is a "catastrophic" failure (as in
             | at best no content, at worst no hdmi output at all). And
             | yes they do happen, either because of broken software
             | implementation (some TV don't reset their hdcp state
             | machine when switching hdmi source), or just dumb
             | electrical issue (i2c - and cec - have a habit of dying
             | because of leaking charges, and one needs to unplug
             | everything for 10 min to fix it)
        
               | ACCount36 wrote:
               | That's video DRM for you.
               | 
               | Upside? There is no, and never was, an upside. Not for
               | the user, and not for anyone else. Video DRM literally
               | never worked.
               | 
               | Nonetheless, it exists, and it makes things worse for
               | everyone by existing.
        
               | voidUpdate wrote:
               | I assume it has an upside for whoever invented it since
               | they can sell it to everyone
        
               | immibis wrote:
               | This is how the world works. If you want to get rich, you
               | can sell something that doesn't work, to rich people who
               | believe it does. That's basically how YCombinator works.
        
               | radicality wrote:
               | I even occasionally get audio issues on Netflix (AppleTV
               | plugged into Samsung 4k oled tv), which I assume are due
               | to some kind of DRM, though never dug into it. Sometimes
               | when switching inputs (firetv stick / AppleTV stick), or
               | switching content on AppleTV between different apps, the
               | Netflix content audio just stops working. All app UI
               | sounds work correctly, but no audio once you hit play.
               | Toggling the AppleTV audio settings a few times between
               | dolbyAtmos and standard stereo usually brings it back, so
               | I assume it has something to do drm on the audio tracks,
               | but if anyone has other ideas lmk
        
               | freedomben wrote:
               | I used to run into this often with Paramount+. I don't
               | know if it's still an issue or not because I cancelled
               | over it (plus them showing me ads when I pay for
               | premium).
        
               | wildzzz wrote:
               | The only direct upside to DRM is for the IP owner.
        
           | bombcar wrote:
           | There are others that end up doing the same thing - I believe
           | some of the Decimators do - perhaps this?
           | 
           | https://www.decimator.com/Products/MiniConverters/12G-CROSS/.
           | ..
        
       | 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.
        
           | nyanpasu64 wrote:
           | Attaching the write-protect pin to +V is literally free in
           | the PCB design process; IMO not doing so is a design error or
           | decision (though IDK how much thought was placed into
           | allowing users to rewrite the monitor identification).
        
         | 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!
        
             | nyanpasu64 wrote:
             | Do any monitors use the I2C multi-peripheral feature to
             | allow both DDC communication and an I2C EEPROM to exist at
             | different addresses on the same bus? Or is it cheaper to
             | integrate functionality into a controller chip? (Though DP
             | tunnels EDID over the aux bus, and (I assume) doesn't use
             | an EEPROM to begin with.)
        
             | Crespyl wrote:
             | > DIYing a KVM switch by just having the PC tell the
             | monitor to switch to a different input!
             | 
             | I made a tiny contribution to the ddcutil-db database when
             | I did exactly that. My monitor wasn't supported initially,
             | but it wasn't hard to use the utils and templates to poke
             | around and find the correct addresses for basic settings
             | and input switching.
             | 
             | It was a nice afternoon's work to get it all working.
        
         | gblargg wrote:
         | I did this once on an Acer monitor. I was modifying it to
         | strobe the LED backlight to give blur-free video like a CRT. I
         | had found that the DDC bus exposed other registers to control
         | the backlight, etc. and had an external circuit connected to do
         | the strobing. I noticed it had registers to read and write the
         | flash ROM, so I dumped it, wrote an 8051 disassembler and did
         | some crude reverse-engineering, then eventually modified the
         | ROM to include a strobed mode (occupying the lower end of the
         | brightness control, so it could enabled and adjusted via the
         | OSD or normal DDC brightness controls). I did have to go inside
         | and connect the write line when flashing it. There was
         | conveniently an interrupt on vblank, and the timer that
         | controlled the LED backlight had a mode that could turn it on a
         | little before the next interrupt and then off an adjustable
         | amount of time after, just the right time needed to flash it on
         | after the LCD had settled updating. Originally I just wanted to
         | remove the several-second boot logo (which I achieved).
        
       | 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.
        
         | klysm wrote:
         | WP high vs low might depend on which chip is used.
        
       | 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.
        
         | nyanpasu64 wrote:
         | You can override EDID in the kernel options
         | (https://foosel.net/til/how-to-override-the-edid-data-of-a-
         | mo...), but I don't know if you want to _add_ a virtual monitor
         | (unsure if https://askubuntu.com/questions/453109/add-fake-
         | display-when... works).
        
           | mlukaszek wrote:
           | Have a look at https://github.com/DisplayLink/evdi and
           | (shameless plug, toy project, be gentle)
           | https://github.com/mlukaszek/evdipp
        
       | 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 :)
        
         | 3abiton wrote:
         | I had a similar problem recently: I got this cheap 5.1 surround
         | system soundbar that support up to Dolby TrueHD via HDMI. But
         | here is the catch, it only works with eArc enabled devices (new
         | gen TV). If you plug your PC you need to use SPIDF or aux which
         | hamper the quality. One solution beside buying an audio
         | ectractor/splitter is to fake the PC edid to be reconized as
         | eARc by the soundbar. Still yet working on this, no strict
         | guidelines existing unfortunately.
        
         | nyanpasu64 wrote:
         | I have (too much) experience in EDID editing. My suggestions:
         | 
         | - AW EDID Editor as you mentioned.
         | 
         | - CRU is a Windows-only tool, and will modify the EDID files it
         | dumps from monitors (removing serial/etc. descriptors to make
         | room for detailed resolutions), but will work. It does _not_
         | run under Wine.
         | 
         | - 010 Hex Editor has an EDID template.
         | 
         | - On Linux you can install wxEDID from Flatpak (IIRC the
         | distribution packages would crash in WxWidgets). I don't think
         | it can _create_ sections though.
         | 
         | - v4l-utils has edid-decode (which can be used as a git diff
         | textconv tool), though this does not help you _encode_ EDID
         | files.
         | 
         | I found that HDMI EDIDs have a CEA extension block while DP
         | EDIDs have a DisplayID extension block. I haven't done any work
         | in multi-page EDIDs with over 256 bytes (and don't know what
         | EEPROM chip you'd use to emulate them, nor the protocol or APIs
         | to read and write them).
        
         | _kb wrote:
         | https://www.extron.com/product/software/edidmanager30
         | 
         | https://www1.kramerav.com/au/product/edid%20designer
         | 
         | Both are free but not free to distribute. The Extron one may
         | require you to be working on projects / orgs using their
         | hardware.
        
         | The_SamminAter wrote:
         | What programmable EDID emulator plug do you use? I was recently
         | looking into them, and it wasn't clear what devices had what
         | features, or if any (cheaper) ones were any good.
        
           | slipheen wrote:
           | https://www.store.level1techs.com/products/p/5megt2xqmlryafj.
           | ..
        
             | The_SamminAter wrote:
             | Ah. Any affordable alternatives? Or just hacking cheap
             | ones.
        
       | 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
        
           | lyu07282 wrote:
           | What gpu/driver were you using?
        
             | pfych wrote:
             | I was using an AMD 5700xt at the time with Mesa drivers
        
         | 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.
        
         | TheJoeMan wrote:
         | Raspberry Pi's with remote desktop won't render the desktop
         | unless a monitor is physically plugged in... easiest solution
         | for say a PhD student.
        
         | ndiddy wrote:
         | One example: I use software called Looking Glass on my PC for
         | interacting with a Windows virtual machine. I have two GPUs in
         | my computer, an AMD one for the Linux host and an NVidia one
         | that gets passed through to the Windows guest. Looking Glass
         | then captures the NVidia GPU's output and displays it in a
         | window on my desktop. This allows me to use Windows software in
         | the VM and get acceptable performance (Windows has basically
         | required graphics acceleration to run acceptably after 7). The
         | problem is that the NVidia GPU will not do anything without
         | having a display connected. NVidia Quadro GPUs support dumping
         | a monitor's EDID and then mapping that file to an output (so
         | the GPU always thinks that monitor is connected to that
         | output), but their consumer-grade GPUs don't support this.
         | That's where the dummy plug comes in.
        
         | leonheld wrote:
         | We use it for testing binary embedded Linux distros where
         | tricking the OS to think there's a display connected introduces
         | a new variable that is not present in the user's deployment -
         | and it's a cheap hardware solution. Buying and installing them
         | is probably more cost-effective than having an engineer writing
         | the `echo on > /sys/whatever` and the logic around it.
        
         | antgiant wrote:
         | They make it super simple for someone on the move to do a zoom
         | out teams call with one screen and still have access to
         | PowerPoint's presenter view.
         | 
         | Basically use the dummy plug screen for PowerPoint's output and
         | the laptop screen for the presenter notes. Then share the dummy
         | plug's screen.
         | 
         | Might not be the best answer for the citizens of Hacker News
         | but so, so easy for teachers and salespeople.
        
         | TiredOfLife wrote:
         | It seems that linux doesn't support virtual displays. On
         | Windows you can either install a dummy display or have Apollo
         | do it automatically. No such thing on linux.
        
         | detaro wrote:
         | In addition to what's already been mentioned, I remember there
         | being issues with macs not unlocking the full abilities of the
         | GPU if there was no display present. Maybe there is some
         | software workaround, but a HDMI dummy is cheap and quick and
         | won't disable itself on updates etc.
        
         | RunSet wrote:
         | > What can you do with them that you cannot do in software?
         | 
         | It lets a macbook operate with the lid closed.
        
         | immibis wrote:
         | Convince a locked-down Fuck You Inc (I mean Apple) device to
         | use a specific display resolution over VNC.
        
       | mrheosuper wrote:
       | hdmi dummy plug is a hardware solution to solve a software
       | problem that should not exist in first place at all.
        
         | HappMacDonald wrote:
         | This sounds like a description of a huge number of extant
         | hardware solutions, to me.
        
       | 1vuio0pswjnm7 wrote:
       | Can dummy plugs be used to change device fingerprinting
        
       | Simon_O_Rourke wrote:
       | I don't get it - why do you need to spoof having a monitor
       | connected for a Raspberry Pi? Surely they boot up fine
       | regardless?
        
         | Gigachad wrote:
         | Did you read the article? The RPI is just being used to
         | reprogram the dummy plug.
        
       | cdg007 wrote:
       | been eyeing this kind of solution
        
       | m000 wrote:
       | I'm confused. I was expecting to see th plug hooked to the GPIO
       | i2c pins, but just plugging it to the RPi appears to be enough.
       | So, does HDMI directly expose an i2c interface?
        
         | pm215 wrote:
         | Yep -- the DDC link which is the comms part of VGA/HDMI/DVI is
         | basically an i2c link, and that's how the OS queries the EDID
         | in normal operation.
         | 
         | As the article notes, the rpi has an i2c controller wired up to
         | those hdmi port pins, because it needs to be able to read the
         | EDID over the DDC.
        
       ___________________________________________________________________
       (page generated 2025-06-16 23:01 UTC)