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.
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.
And here I was assuming it was changing to intel arc or display port (due to the card) or wayland (due to the driver) that causes my screens to jump to 100% brightness after they turn off. I see it still isn't fixed after 5 months so if I can't go back to X after my next update I'm putting my old nvidia back in.
I'd recommend following the steps at https://invent.kde.org/plasma/powerdevil/-/blob/master/READM... to disable brightness control. You can switch to X11 too, but for some reason I get screen tearing and blocky incomplete updates I haven't looked for a workaround yet.
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.
This article mentions one downside of ACCESS.bus (low speed), but misses another big one: it's a shared bus. Meaning that any misbehaving/buggy device can bring entire bus (and all devices on it) down, or slow it down significantly (via SCL stretching)
Compare this to USB, which has fixed timing (once you get the bus, you have to respond in time or release bus without sending anything). Moreover, all USB traffic is sent via hubs - so if device is misbehaving, hubs can cut it off without affecting the rest. The spec even has provisions for cutting off the power to misbehaving device, but most cheap hubs do not implement this.
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).
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..."
And here I was assuming it was changing to intel arc or display port (due to the card) or wayland (due to the driver) that causes my screens to jump to 100% brightness after they turn off. I see it still isn't fixed after 5 months so if I can't go back to X after my next update I'm putting my old nvidia back in.
I'd recommend following the steps at https://invent.kde.org/plasma/powerdevil/-/blob/master/READM... to disable brightness control. You can switch to X11 too, but for some reason I get screen tearing and blocky incomplete updates I haven't looked for a workaround yet.
EDIT: I tried switching to Wayland on Arc and am getting stuttery mouse cursor movement at around 36 FPS. I wonder what's wrong...You can even use the I2C bus to attach a second (tiny) display, see for example https://www.youtube.com/watch?v=8UbVgUFfN8U
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.
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.
This article mentions one downside of ACCESS.bus (low speed), but misses another big one: it's a shared bus. Meaning that any misbehaving/buggy device can bring entire bus (and all devices on it) down, or slow it down significantly (via SCL stretching)
Compare this to USB, which has fixed timing (once you get the bus, you have to respond in time or release bus without sending anything). Moreover, all USB traffic is sent via hubs - so if device is misbehaving, hubs can cut it off without affecting the rest. The spec even has provisions for cutting off the power to misbehaving device, but most cheap hubs do not implement this.
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.
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.
[dead]