HDMI DDC Keypad Controls Monitor From Rack

April 12, 2024 by Kristina Panos 20 Comments

Sometime last year, [Jon Petter Skagmo] bought a Dell U3421WE monitor. It’s really quite cool, with a KVM switch and picture-by-picture support for two inputs at the same time. The only downside is that control is limited to a tiny joystick hiding behind the bezel. It’s such a pain to use that [Jon] doesn’t even use all of the features available.

[Jon] tried ddcutil, but ultimately it didn’t work out. Enter the rack-mounted custom controller keyboard, a solution which gives [Jon] single keypress control of adjusting the brightness up and down, toggling picture-by-picture mode, changing source, and more.

How does it work? It uses the display data channel (DDC), which is an I²C bus on the monitor’s HDMI connector. More specifically, it has a PIC18 microcontroller sending those commands via eight Cherry MX-style blues.

Check this out — [Jon] isn’t even wasting one of the four monitor inputs because this build uses an HDMI through port. The finished build looks exquisite and fits right into the rack with its CNC-routed aluminium front panel. Be sure to check it out in action after the break.

Ever wonder how given keyboard registers the key you’re pressing? Here’s a brief history of keyboard encoding.

Continue reading “HDMI DDC Keypad Controls Monitor From Rack” →

An 128x64 OLED display with a weird image on it, showing a mouse cursor, date and time in the bottom right corner, and a whole lot of presumably dithered dots

Making Your Own Technically-HDMI OLED Monitor

April 1, 2022 by Arya Voronova 17 Comments

One day, [mitxela] got bored and decided to build his own HDMI monitor – the unconventional way. HDMI has a few high-speed differential pairs, but it also has an I2C interface used for detecting the monitor’s resolution and issuing commands like brightness control. In fact, I2C is the backbone for a lot of side channels like these – it’s also one of our preferred interfaces for connecting to cool sensors, and in this case, an OLED display!

[mitxela] describes his journey from start to end, with all the pitfalls and detours. Going through the pinout with a broken hence sacrificial HDMI cable in hand, he figured out how to probe the I2C lines with Linux command-line tools and used those to verify that the display was recognized on the HDMI-exposed I2C bus. Then, he turned to Python and wrote a short library for the display using the smbus bindings – and, after stumbling upon an FPS limitation caused by SMBus standard restrictions, rewrote his code to directly talk to the I2C device node, raising FPS from 2 to 5-10.

From there, question arose – what’s the best software route to take? He tried making a custom X modeline on the HDMI port the display was technically attached to, but that didn’t work out. In the end, he successfully employed the Linux capability called “virtual monitors”, and found out about an interesting peculiarity – there was no mouse cursor to be seen. Turns out, they’re typically hardware-accelerated and overlaid by our GPUs, but in [mitxela]’s case, the GPU was not involved, so he added cursor support to the picture forwarding code, too.

With partial refresh, the display could be redrawn even faster, but that’s where [mitxela] decided he’s reached a satisfactory conclusion to this journey. The write-up is a great read, and if videos are more your forte, he also made a video about it all – embedded below.

We first covered the ability to get I2C from display ports 14 years ago, and every now and then, this fun under-explored opportunity has been popping up in hackers’ projects. We’ve even seen ready-to-go breakouts for getting I2C out of VGA ports quickly. And if you go a bit further, with your I2C hacking skills, you can even strip HDCP!

We thank [sellicott] and [leo60228] for sharing this with us!

Continue reading “Making Your Own Technically-HDMI OLED Monitor” →

Controlling External Monitors On M1 Macs With Undocumented APIs

September 8, 2021 by Maya Posch 8 Comments

Display Data Channel (DDC) is a very useful feature of modern digital displays, as it allows the graphics card (and thus the OS) to communicate with a display and control features such as brightness and contrast. The biggest negative aspect here is the relatively poor access to this feature within an operating system like MacOS, which can change on a whim, as [Alin Panaitiu] found out recently.

Current displays implement DDC2, which is based around an I²C bus. Despite this, few OSes offer DDC-based control of features such as brightness which is where [Alin] developed a popular utility for MacOS that used undocumented APIs to talk DDC2 with external monitors via I2C. Until the new Arm-based Mac systems got released and these undocumented APIs got changed, that is.

Even though there are some ways around this, with some utilities using a simple software-based overlay to ‘dim’ the display, or using an external gamma adjustment via an external Raspberry Pi system hooked up to HDMI and using ddcutil, the best way is still via DDC2. Ultimately the new (undocumented) APIs that provide access were discovered, with another user going by the name [zhuowei] notifying [Alin] of the new IOAVServiceReadI2C and IOAVServiceWriteI2C methods with Arm-based MacOS.

After this it took some more sleuthing to figure out which of the devices on the I2C bus were which monitor in the case of multiple external monitors, but in the end it all worked again, adding hardware-based brightness controls back in the hands of MacOS users. Minus a few apparent hardware issues with HDMI on the M1 Mac Mini and some displays, but who is counting?

[Heading image: Screenshot of the Lunar app on MacOS. Credit: Alin Panaitiu]