There are a few good ~cheap CEC adapters for HDMI out there. I’ve used the PulseEight one since they have decent library support plus a CLI. You can also use the HDMI port on a Raspberry Pi to play with CEC: https://github.com/Pulse-Eight/libcec/blob/master/docs/READM...
I came across a monitor with an EDID that was out of the spec for what constitutes a valid EDID, and it actually exposed a bug in the linux i915 driver, I had all this corrupted output.
While the patch was getting merged, I was able to dump the EDID, edit it to be within spec, and then was able to actually flash it BACK to the monitor by using nothing other than this program on github [1], and the HDMI port on a Dell E6430.
I was amazed that was possible to write an EDID from simply connecting to the port, didn't need to open anything up, was able to do it without any special equipment, etc.. I never realized how complicated some of these display protocols can be, but part of it is just i2c, and I guess the hardware is not very restrictive on how that i2c controller can be used outside of display purposes.
Someone with a Raspberry Pi could go around a college campus and wreak havoc if they wanted. Goes to show you that you should not trust any public peripheral, not ever. That's especially important in the age of USB-C and mobile devices where charging and data are put on the same port.
Oh it's so much worse than that. The EDID is typically implemented with an I2C EEPROM connected directly to the AUX lines. The "edid read" procedure is no more than reading "0xA0", the standard EEPROM I2C address, over AUX.
The first time I ever sniffed that bus and saw a simple "read" command to that address I'd seen in so many other places before I almost fell off my chair.
Editing a monitor's EDID data would be a sneaky attack. Someone might never figure out why their monitor suddenly became monochrome or only supported 640x480. Or you could gaslight someone by making the resolution a bit worse every day.
There should be a write protect for the EDID on displays. A display I was working with didn't have the write protect enabled and my Nvidia graphics card decided to overwrite the EDID for me. Had to reprogram it before my PC would recognize the display again.
You can also use the Debian package i2c-tools to communicate with things connected to the busses on your computer.
I once used it to play with a set of Melexis IR sensors I'd soldered to the VGA port on a crap video card. It made writing the Arduino code way easier after figuring out all the hard things with Linux. There was even enough power on the VGA pin to run 4 of them!
Really though, it was just exciting to be able to wire some of my own hardware into the computer and write a program to talk to it. Made me feel like I actually own my computer again.
Author cited a Wiki page as technical reference. Worth noting that VESA has made the EDID standard--including errata and other relevant standards--readily accessible to the general public[1]. Now if only they'd do the same for the latest revision of DisplayPort...
Yes, plugging the monitor into a Linux box would have be easier. In my case the edid is exposed under /sys, and edid-decode is from the xorg-x11-utils Fedora package
Even on Linux things don't always work as intended. The reason I am familiar with the EDID information is that my display stopped working after a kernel update and I tried to figure out why. It turned out that my AV receiver didn't like the VIC field being sent in the HDMI infoframes[1]. There is a surprising amount of communication which goes on between the graphics card and the monitor in a modern system.
1:
Bug 50371 - [BISECTED] HDMI display blank unless VIC set in AVI infoframe
I use it in my personal projects a lot, it's very easy to code up an i2c master and/or slave on pretty much any microcontroller. Very handy for abstracting different sensors or actuators by hiding them behind a microcontroller that bridges them to a common i2c bus. Not to mention that boat loads of sensors use the protocol directly. SPI is even simpler, but it requires more wires and also is lower level (SPI is basically just a fancy shift register) so it usually ends up taking more boilerplate.
>To read the data over I2C, I used the PocketBeagle, a tiny Linux computer that I had handy. (You could use a different system that supports I2C, such as the Raspberry Pi, Beaglebone or Arduino.)
I keep hearing that the Raspberry Pi's peripheral support for things like I2C is pretty bad - is that no longer the case?
It's a pretty easy interface to bit-bang and not too sensitive to the clock line's precision, but it's nice when you can actually use a chip's hardware peripheral as intended.
Perhaps you are thinking of the I2C clock stretching bug[1]?
Bugs like these are not unusual in embedded systems. It is often difficult to fix the hardware and the software will implement some kind of workaround. The web page lists several possible workarounds for this bug.
HDCP also happens over this interface, so it’s trivial to snoop on the key exchange: https://github.com/ApertureLabsLtd/hdmi-sniff/blob/master/RE...
CEC (control devices via HDMI) happens on a separate channel using a proto also similar to I2C: http://www.quantumdata.com/pdf/CEC_White_Paper.pdf
There are a few good ~cheap CEC adapters for HDMI out there. I’ve used the PulseEight one since they have decent library support plus a CLI. You can also use the HDMI port on a Raspberry Pi to play with CEC: https://github.com/Pulse-Eight/libcec/blob/master/docs/READM...