VGA/DVI/HDMI ports have an I2C interface (though DP tunnels I2C over AUX), which is normally used to read EDID information from monitors and control brightness, but on Linux (not Windows) you can control it as a general-purpose I2C bus, dump and even rewrite EEPROMs placed on the monitor bus. In theory you could even hook up a Nunchuk or Classic Controller to a display output (with level shifters if you want to run the Nunchuk at 5V off a 3.3V bus), and write a Linux driver to communicate with the peripheral and expose it as a game controller.
HDMI is an absolutely unhinged standard. I run the mediatec department at a university and the amount of things that can go wrong with HDMI is absolutely astonishing, when 99,9% of people at best what the digital equivalent of analog video /audio connections.
The best thing was certain macbooks not working at a certain input. It the turns out HDCP was at fault, which is basically DRM for HDMI.
The I2C part is something of an implementation detail -- it's only _really_ guaranteed to work as an EEPROM interface. It's usable on a lot of platforms, but again, not a guarantee.
Also, if you have ddcci-driver-linux installed, then the KDE desktop lets you adjust monitor brightness from the UI. Eventually Linux upstream might get the same functionality as the out-of-tree module.
VGA/DVI/HDMI ports have an I2C interface (though DP tunnels I2C over AUX), which is normally used to read EDID information from monitors and control brightness, but on Linux (not Windows) you can control it as a general-purpose I2C bus, dump and even rewrite EEPROMs placed on the monitor bus. In theory you could even hook up a Nunchuk or Classic Controller to a display output (with level shifters if you want to run the Nunchuk at 5V off a 3.3V bus), and write a Linux driver to communicate with the peripheral and expose it as a game controller.
I2C is also extremely common as a low-speed peripheral bus in electronic devices - some common applications are:
- Small EEPROMs, often used for configuration data or small firmware blobs
- MEMS sensors (accelerometers, gyroscopes, etc)
- Small LCD/OLED displays (e.g. 128x64)
- Configuration ports on devices which use other busses for bulk data (e.g. display drivers, audio codecs, etc).
HDMI is an absolutely unhinged standard. I run the mediatec department at a university and the amount of things that can go wrong with HDMI is absolutely astonishing, when 99,9% of people at best what the digital equivalent of analog video /audio connections.
The best thing was certain macbooks not working at a certain input. It the turns out HDCP was at fault, which is basically DRM for HDMI.
The I2C part is something of an implementation detail -- it's only _really_ guaranteed to work as an EEPROM interface. It's usable on a lot of platforms, but again, not a guarantee.
I use ddcutil all the time on linux to set my monitor brightness without needing to fiddle with the OSD.
The ddcutil folks also have a great GUI btw:
https://www.ddcutil.com/#ddcui
Also, if you have ddcci-driver-linux installed, then the KDE desktop lets you adjust monitor brightness from the UI. Eventually Linux upstream might get the same functionality as the out-of-tree module.
https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux
In my experience the KDE desktop lets you set monitor brightness from the UI... and on Wayland it happens even if you don't ask it to (https://bugs.kde.org/show_bug.cgi?id=494497). You can turn it off by "setting the `POWERDEVIL_NO_DDCUTIL=1` environment variable in PowerDevil as described in its README file: https://invent.kde.org/plasma/powerdevil/-/blob/master/READM..."
You can even use the I2C bus to attach a second (tiny) display, see for example https://www.youtube.com/watch?v=8UbVgUFfN8U
My favorite bit of alternate history computer interface standards is UPAMD (https://en.wikipedia.org/wiki/Universal_Power_Adapter_for_Mo...) - essentially what USB-C/USB-PD ended up being but using CAN for communication and a pogo-pin-based connector.
Memory unlocked: the family ViewSonic 17PS-2 had an Access.bus connector on the back.
I couldn’t find any info back in the day beyond that it was I2C-based, but appreciate being able to connect the dots now.
A major disadvantage of using something based on i2c for computer peripherals is being unable to connect two devices with the same ID at a time.
[dead]