I don’t like HDMI. Despite it being a pretty popular interface, I find crucial parts of it to be alien to what hackers stand for. The way I see it, it manages to be proprietary while bringing a lot of the old cruft in. It doesn’t have a native alternative like DisplayPort, so portable implementations tend to suffer power-wise; the connector situation is interesting, and the HDMI Foundation has been doing some weird stuff; in particular, they are pretty hostile to open-source technology.
This article is not the place for such feelings, however, especially since I’ve expressed them enough in the DisplayPort article. We the hackers deserve to be able to handle the interfaces we stumble upon, and I firmly believe in that way more than in my right to animosity towards HDMI.
The HDMI interface is seriously prominent wherever you look, in part because it’s the interface created by the multimedia-involved companies for the multimedia-involved companies. Over the years we’ve had it, it’s been more than sufficient for basically everything we do video-wise, save for the highest resolutions.
It’s also reasonably simple to wire up, hack on, and even bitbang. Let’s go through what makes it tick.
The Core
HDMI is, at its core, three differential pairs for data, plus one pair to clock them and in the darkness bind them. It’s a digital interface, though it is a fun one. This makes it way more suitable for higher-distance video transmissions than interfaces like VGA, and as long as you stick to relatively low resolutions, HDMI won’t have as many asks in terms of PCB layout as DisplayPort might, thanks to HDMI link speeds scaling proportionally with the display resolution.
As internals go, HDMI is not that far from either VGA or LVDS aka FPD-Link – it’s still a constant stream of colours, respecting VSYNC and HSYNC. Unlike LVDS, however, bits are not quite transmitted directly – each 8-bit colour gets turned into a 10-bit packet. This scheme has been inherited from DVI, and HDMI has mostly built upon it, though things become more complicated in the latest HDMI generations.
You will see the three differential pairs referred as D0/D1/D2, but they do roughly correspond to blue, green and red color data streams in practice. That said, you couldn’t simply disconnect all of them and replicate the VGA cable missing colour effect – there’s more going on. HSYNC and VSYNC bring quite a bit of blank space with them, intervals where no pixel data is transmitted, and HDMI puts some more useful stuff into these intervals – like audio, which DVI couldn’t do, as well as some control messages, like the ones signaling HSYNC and VSYNC.
HDMI is reasonably simple. If you want to figure out clock frequency for a HDMI link, calculate the pixel clock for your resolution (as mentioned in the parallel RGB article), then multiply it by 10, due to the packing and encoding that has to happen; this is how HDMI signal on a Raspberry Pi manages to jam WiFi at a very specific resolution. This simplicity makes it all that easier to implement in your own project, whether you’re using an FPGA or a Pi Pico.
Side Channels
There are a few extra pins you will see in a HDMI connector pinout. These are way more fun than you might know of, and I’m not even talking about the I2C as some might guess. For a start, there is the simplest one – it’s called HPD, and it’s just hotplug detect. The lore goes, a HDMI display has to pull HPD up to 5V with a 10k resistor; I’ve had success just feeding 5V into it, but sticking to the spec is undoubtedly better.
Then, yes, there’s I2C, the SDA and SCL we all know and love. They’re level-shifted to 5V, but with just two FETs and four resistors, you can treat it as an I2C interface for all intents and purposes. On Intel and AMD computers, you can tap that I2C interface in Linux super easily, even if your GPU (external or internal) is pretty modern, and do things from hardware hacking to driving a separate tiny 128×64 I2C OLED screen. Nvidia proprietary drivers are a no-go because they don’t expose the interface, and same goes for Windows, unless you’re okay with paying a fair bit for a software suite from someone who’s reverse-engineered the internal interfaces.
I2C gives you access to EDID, a display configuration data blob that’s standardized by VESA and pretty hackable, as well as DDC – an I2C-exposed interface that lets you control your monitor programmatically. Yes, if you’re using Linux, there are a slew of utilities that let you turn your monitor on or off, switch inputs, control brightness and contrast, and a ton of other features you’d usually find in your display’s on-screen menu so often awkward to navigate.
Then, there’s the less known but pretty fun feature called CEC (Consumer Electronics Control). It’s a single-pin multi-drop data bus for controlling over the HDMI cable, letting you do things like adjust volume sliders on your HDMI-equipped receiver, change channels, or much more. The interface and the protocol are standardized, but a ton of device-specific commands are not; that said, it’s a reverse-engineering treasure trove.
Another fun pin is pin 14, known as HEAC. You might’ve heard of Ethernet over HDMI and HDMI ARC (Audio Return Channel), and this pin is used for both of these, together with the HPD pin that gets double duty. Last but not least, you get a pin that carries 5V, at, supposedly, 50mA. The 50mA limit is not always adhered to, as you might guess, but it’s enough to power a good few things nevertheless.
Hacking Galore
HDMI is simple enough and it’s seriously abundant, so there’s more than enough fun stuff you can do with it. For a start, there’s no shortage of projects that output HDMI, or help you output HDMI. From open-source FPGA IP cores to the Pi Pico PIO trick that is now pushing 1080p, from fun ASICs that help us drive DSI screens to homegrown HDMI to LVDS converters, FPGA-backed or not.
Both the I2C channel and CEC get their minutes of fame every now and then. It might happen that an IC in a product exposes a bootloader over the I2C channel, as the Amazon Fire TV Cube did. If you’re okay with wading through the labyrinth that is DDC (or reusing one of the existing libraries), you can build a hardware keypad for controlling your monitor setups. And, since a Raspberry Pi has CEC support exposed to us mere mortals, a Pi connected to your TV can help you control anything else connected to it, like we’ve seen [Victor] do – alternatively, you could implement CEC on an ATTiny or on a PIC for all your home entertainment mod needs!
The HDMI hardware abundance applies to capture cards, too, which is wonderful since they’re a worthwhile tool for hackers – we’ve even seen open-source ones, as cheaply as $10, and you could build a KVM as cheaply, too. If HDMI cables, as far as they go, are not long enough for you, there are plenty of HDMI to IP solutions, and we see hackers playing with them every now and then.
There’s also the part of HDMI known as HDCP, a video encryption standard that, in practice, means your display will be black if your hardware isn’t HDCP-blessed. The irritance factor makes it a worthwhile bastion for hackers, of course. That said, you don’t need a FPGA – if you simply want your hardware to work together without compatibility issues, there’s HDMI splitters you can get on Eastern markets, that strip HDCP on their input and conveniently forget to reapply it on one or both of their outputs. And, if your splitter is more conscientious than that, you can always force it to mis-step.
Learn More…
If you want to hack on HDMI or learn more in depth about what makes it tick, there’s a fair amount of resources we have covered and even written ourselves, and even more resources on the wider web. HDMI connectors and cables are available wherever you look, and if you get NDA requests or membership requirements when buying your HDMI-equipped chips in the West, you can always turn to Eastern markets.
HDMI is not about to leave our homes, and as long as it’s here, you deserve to know how to hack on it. It’s not the only interface that’s surprisingly prominent – in fact, next time, we ought to take a look at the DSI interface, surprisingly proprietary yet in everyone’s pocket, and a treasure trove waiting to be dug into.
How does the Xi3 Piston prototype “steam machine” jack that is both HDMI and DisplayPort work?
Mechanically? You could try to grab one and see for yourself:
https://www.mouser.com/ProductDetail/Rego-Electronics/845-002-217CRL?qs=Znm5pLBrcAJJY6Wkw0u8yA%3D%3D
Thanks for the part number, it looks like pin 21 will let you know if a DP or HDMI is plugged https://rego.com.tw/product_detail.php?prdt_id=76
I’m sure HDMI foundation will sue you if you try to claim it as HDMI compatible.
Also according to the pin out they are completely incompatible electrically. So it requires a switching circuit. An Xi3 7238US00 machine is about $100 on eBay. Probably worth it because just the jack will set you back $22 with shipping.
not completely, only a few pins have to be changed up, and they aren’t even the high-speed ones! also, it’s $10 alone, the $10 shipping is why you buy $40 more of parts with it =D
You are correct the pin out is closer than I thought. That is truly bizzare I don’t understand why this wouldn’t be standard on something like a laptop.
Licensing, that’s the only reason. Proprietary standards are great aren’t they?
Do you have suggestions for if you are using an FPGA that can’t quite hit the speeds needed for high res HDMI and definitely not Display Port? I haven’t had much success finding an all in one chip for converting that doesn’t need a bunch of setup that’d increase complexity.
The thing the HDMI forum is so hostile over is HDCP… Copy protection. And that comes directly from the content providers sue and abuse of intellectual property laws.
Until IP law is properly resolved, this is gonna go on.
The first link of the article shows the HDMI forum rejecting AMD’s open-source implementation of HDMI 2.1, with previous version implementations open-sourced by AMD, as far as I’m aware. Could you elaborate how that is related to HDCP?
Technology is rather poor at resolving social issues.
No, they are actively hostile to any open adoption or compatibility, *and* Linux specifically. Just like at the main members for why. The people who created this were actively pushing for control to choose the “analog hole” and view open source in general as undermining their efforts.
Hollywood Did Make It. HDMI, we didn’t need it.
> Yes, if you’re using Linux, there are a slew of utilities that let you turn your monitor on or off, switch inputs, control brightness and contrast, and a ton of other features …
No “need” to use Linux – there are a few utilities doing similar / the same things on Windows too.
Some were even mentioned in an article you link to in this article (the DDC keypad one)…
eg. https://github.com/chrismah/ClickMonitorDDC7.2/
https://www.entechtaiwan.com/util/mc.shtm (mControl)
maybe https://www.entechtaiwan.com/lib/softmccs.shtm
On Windows I think I was using ClickMonitorDDC for a while, now dead. V7.2 is the last one.
https://www.reddit.com/r/software/comments/jpqlm6/clickmonitorddc_is_gone/
My problem with HDMI is that USB-C used Display port, and I really like the idea of everything being USB-C, despite not having ever actually used USB-C video yet because it’s not common on cheaper stuff.
There are a lot of things that are odd with DVI/HDMI. DVI had to deal with the duality of analog and digital signals, thus why HDMI payloads follow analog alike payloads that can be a source of interference. Heck encoded signals may not be DC balanced. Not to speak of transmitting a clock over a cable. Some time later, the patent for 8B/10B encoding was not extended and you can see that better encoding in Gigabit Ethernet and DisplayPort.
HDMI signal is related to 3.3V and cannot be level shifted by having series capacitors. That forces chips to deal with 3.3V I/O, something that is a PITA to work with.
Having a signal that is related to the link bitrate meant that no memory was needed but it made link equalisation harder. DP is fixed rate link with training mode built inside the spec.
HDMI 2.1 introduced a new “optional” transfer mode, that is fixed rate link, that is incompatible with the previous transfer methods. You go from 3 data lanes plus one clock to 4 data lanes.
Speaking of optional features, PS3 (yes, three) introduced DeepColour, aka 30bpp or 36bpp RGB 4:4:4 colour representation. Too early introduced, as panels at that time could not reproduce anything over 15bpp without dithering or similar technique. HDMI Ethernet was never really popular. It is limited to 100Mbps if memory does not fail me.
DP is having these days their own HDMI snaffu moment too. Cables for 80Gbps are too difficult to manufacture for any normal cable length, or they require active cable equalisation that is not yet available. The ones that are being sold are shorter than 1.2m.
Isn’t HDCP pretty much dead since a masterkey was published in 2010?
The fact that HDCP is never stopped piracy doesn’t stop them from forcing their stupid anti piracy crap onto consumers causing all sorts of problems
You are right. HDCP gets in your way where you least expect it, e.g. with VNC connections.
I once learned that HDMI (the video part) ist basically DVI-D, but with additional DRM to protect the media industry’s business model. Why do it the simple way, if you can have it complicated and user-hostile :-(
I’m still looking for a working hdcp bypass that is less than 200$.
I remember when the eff had an anti DRM television hackathon before dtrm law kicked in. Whatever happened to those schematics?
Can hdmi send keyboard mouse events to the host?
not that I know, unless CEC has a funny mechanism for that of some sort?
This article is a treasure trove of project ideas. I should not have read it after two cups of coffee.
ayyy glad to hear! ^_^