Before finding a way to use DDC on Apple Silicon [1] for Lunar (https://lunar.fyi), I contemplated creating a universal DDC/CI device that can change brightness, contrast, volume, input and colors of a monitor, by either receiving commands through HTTP, or acting as an Adaptive Brightness standalone device.
In my mind, it would have been an HDMI dongle with an ESP32 that gets power through the 5V line of the HDMI port, and which has an ambient light sensor to adapt brightness by itself.
In the end, I found the I2C APIs on M1 so this was not so sorely needed anymore, but given the limitations of the M1 Display Coprocessor, I still think it might be a good idea. I just have no idea where would I start with hardware distribution and mass production, this domain seems so intangible from the software development side.
I also started working on something similar a while back, unfortunately got sidetracked with other things before I got many of the features (color adjustment, contrast, etc) implemented.
Both of the monitors on my desk have ESP32 based HDMI dongles plugged into a spare HDMI port. I have 2 USB 3.0 switches that have been retrofitted with ESP32s as well, one for my keyboard and mouse, and one for a hub on my desk. A short press of the button on the switch on my desk will switch my keyboard/mouse between my desktop and a thunderbolt 4 dock, which will then trigger both of the monitors to switch the the inputs that are also connected to the dock. A long press of the button will do the same, but will also switch the secondary hub over (speakers, mic, webcam, and a few free ports for flash drives and the like).
I was looking for an alternative option to an expensive KVM that would do the job I needed. As a 'poor man's KVM' it works pretty well, though I do hope to flesh out the rest of DDC/CI to get some of these other features implemented as well.
My own implementation. I actually started writing a more full featured DDC library with things like capability scanning on the roadmap. I should have some time next month to potentially get back to it.
A lot of what was available seemed to be Arduino based with Arduino specific calls in the libraries. I'm using standard ESP32 libs/build system and am trying to keep this one generic.
I hope I’m not stepping over the line, but if it’s not already open source, would you be willing to send me a source code tarball? I’d love to prototype a DIY solution with it for the people having trouble with DDC on DisplayLink connected monitors.
My email is on my HN user page in the About section.
I wouldn't mind if there was a bit more there. There is only the beginnings of the library (headers w/ DDC register map, function prototypes, etc), and I was still in the process of figuring out the architecture of the thing when I ran out of time to work on it. That being said I would be more than happy to get back to you if I am indeed able to get some more of the groundwork done on it next month as my schedule frees up.
I maybe could have been clearer on this, but the DDC dongle I made isn't using this library, just hardcoded i2c calls for input switching. I started working on the library to eventually integrate with that dongle, but I'm still using the 'hacky' firmware on the dongles hooked to my monitors.
I have a repo for the switch firmware, which has some pics and other details. Keep in mind though that was pretty quick and dirty, and I think there is a fix for the secondary switch that I still need to push. I should hopefully have some free time to get back to it soon though.
The HDMI dongle repo is still private, and I really want to do some cleanup before making it public. But, as for parts, I just used a breakout off amazon, and some cheap perfboard to make a hat containing the ESP32.
Wow, this looks fantastic! No one ever mentions that the Apple displays integrate with the brightness controls on macs. This can be a major quality-of-life feature if you work during the day and night and don't want to keep changing brightness on multiple monitors every day.
However, I have non-Apple displays as well. Just tried https://lunar.fyi/ via usbc and it worked great so far!
I see a lot of questions on the internet on “how do I control monitor brightness on macOS?” and a lot of “just use Control+Brightness Up/Down” answers from people not realizing that only Apple vendored monitors support that.
And that’s only possible because Apple implements a proprietary USB protocol inside their monitors for changing brightness so they have smooth transitions and be sure it works every time.
I’m pretty sure they’ll never touch DDC/CI for that, and rightfully so as it has very spotty support, especially with these new Thunderbolt hubs/adapters and smart monitors.
I'm using MonitorControl [1] and it works great. Plus, it is really open source, in contrast to Lunar which is "open source" but you can't build it as per its repo's README:
> Lunar can't be built from this repo yet as the source code for the paid features is hidden.
Thank you for the snark, but what you probably don’t know is that MonitorControl for M1 wouldn’t have been possible if I hadn’t open sourced Lunar’s code and my reasearch on that.
All the work on MC after Apple Silicon is done by a previous Lunar user (@waydabber) which I helped for months on Discord until he got the implementation right, and then eventually got to do his own paid implementation called BetterDisplay.
Lunar is my full time job, I can’t have it fully open source and still earn money from it. I would still be working at some corp on gluing web APIs if I hadn’t done this.
I think it's perfectly fine to do non open source work as long as one does not pretend to be open source.
I had a quick look to your website at in all fairness, it's pretty clear that the product is proprietary and paid (at least it doesn't claim "the de facto open source app to ...").
In your comparison table I would suggest to put at least a yellow tick (rather than the green one currently) in the open source line though, because that is slightly misleading.
Does Open Source require the source to be compilable?
The free parts of the app are fully open source with an MIT license, you’re free to modify it and add mocks for the paid parts. It’s gonna be hard, but infinitely easier than having to rewrite such an app from scratch.
For me, the source code is there and open, call it whatever you want, they’re just vague terms anyway. I’m gonna keep calling it open source.
> Does Open Source require the source to be compilable?
No, but, the actual code clearly is compilable (because you've compiled it). So this is only part of the code. So it's partially open source. So it shouldn't have a green tick and you shouldn't call it "open source".
Well yes, the full Lunar Pro app is compilable. I'm only open sourcing Lunar Free which is not compilable without some mocks, not even on my own machine.
But whatever, since all I've had is attacks and flat out stealing from the "open source community", I'll only release closed source binaries from now on so that I'm staying away as much as possible from this drama.
I'm not gaining anything from calling it "open source", it's just what regular people understand easier than "source available" or "semi-closed source" or however OSS people would like to call it just for the sake of pertaining to an arbitrary Open Source Definition like it's the law.
Lunar started as open source until v4 and Lunar v3 is still in the lunar3 branch, as compilable and usable and open as it ever was. I wanted to contribute my knowledge just how I got help from reading and using part of the ddcctl source code.
And people did profit from that: all current M1 DDC solutions (MonitorControl, DisplayBuddy, m1ddc and BetterDisplay) are based on my code from the DDC.c and DDC.swift files. I've created competitors for the only business that's keeping me afloat financially, so I'm definitely not liking when people attack even this gesture.
I'm probably sounding like an old man shouting at the sky, these words are not a direct reply to your comment anymore so hopefully you won't take it personally.
Don't worry, I was just providing suggestions to be helpful, not demanding or expecting anything (I don't use Apple products, so I won't be one of your customers no matter whether it's OSS or not) and I'm not taking things personally.
Each people have their own reasons to want open source software. Some people like it for knowledge sharing as you mentioned, but other use cases include make it easier to package in Linux distributions (I don't know the Macos equivalent, maybe that one doesn't make sense), or making it possible to customize the software for my own need (and sharing it with the community in case it's helpful for someone else). For those use cases, it's very useful to have enough code to build the software. Maybe you should suggest whoever would be interested to have this to contribute the missing pieces / mock.
Anyway, I wish you luck with your business, personally it makes me happy to see people build software independently, OSS or not :)
The part that is open source is open source, but the part that is proprietary is not open source. Which is why I think a yellow tick at least would be fairer, because it's only partially open source.
> MonitorControl for M1 wouldn’t have been possible if I hadn’t open sourced Lunar’s code and my reasearch on that.
Thank you for your open source contributions.
> I can’t have it fully open source and still earn money from it.
I understand. No one asked you to make it 100% open source, but it would be great if the open source parts of the app are decoupled and can be independently built.
Actually, I knew several partially open source apps, similar to Lunar. For example, Rectangle [1] has both an open source version and a pro (paid) version. However, unlike Lunar, the open source code of Rectangle is buildable. In fact, Lunar might be the first partially open source app I know that is not buildable.
Someone determined enough could add adaptive brightness to it. You can even use Lunar’s wireless ambient light sensor [1] for that as it’s simply sending lux values through Server Sent Events [2]
And for a more advanced feature set, ClickMonitorDDC.
Sadly it is no longer hosted by the company where the developer worked. I mailed them, asking where the dev went or if they could put me in contact with him so he could release the source code. Regretfully I never got a response.
It doesn't have ambient light sensing, but I use Twinkle Tray [1] for controlling multiple monitors at once.
It has a time schedule feature, and my hacky-but-functional setup is to have it reduce the brightness a bit every 30 minutes between 5:30 and 9pm -- on my setup it goes 80% to 20%. I have it reset back to 80% before I start using it in the morning.
Looks like lunar.fyi is just for Mac, right? Any idea about an equivalent on Linux? I want to add an input switch shortcut on my keyboard, but I want it to work on both machines.
This just solved a problem I have that I never knew there was a solution for! It seems really weird to me that every OS doesn't have a native solution for changing external monitor brightness; I thought it was down to the monitor but clearly it isn't. Thanks for the link and thanks for your work on Lunar!
Well it kinda is up to the monitor. Given how many monitors don’t implement the DDC/CI standard correctly and flash and crash and blackout on simple brightness change commands, it would turn into a PR nightmare at the scale of an operating system.
I’m overwhelmed by the daily support I have to provide for Lunar users and I barely have 20k users. I can’t even imagine how bad it would be if 100k users started having their monitor crash or lose color on “such a simple thing as changing brightness”.
Thank you! It was built incrementally over the past year to reach this state, so I thought it might be a tad too long and in-depth :) happy to hear you find it just right!
[OffTopic] Thank you for Lunar.fyi. I tried Lunar and then stumbled on MonitorControl[1]. Went back to Lunar and bought the pro. I'm not aware of the details but Lunar just works with the LG external monitor and syncing with the iMac.
No worries! The same sentiment is what keeps me enthusiastic about programming day after day :)
So computer monitors have support for a communication protocol called Display Data Channel which is normally used by the host (Mac, PC) to get info about supported resolutions, frame rates, signal timing etc.
On top of that, a command interface has been created called MCCS or Monitor Control Command Set [1] which allows changing brightness, volume, input and a ton of other aspects of the monitor, by sending specific bytes through the cable. That cable can be HDMI, DisplayPort, Thunderbolt, VGA, DVI. It doesn’t matter, as long as it has dedicated wires to carry the I2C signal.
I2C is the 2-wire communication protocol used by DDC, and it basically defines things like “a pulse of 5V (volts) of x milliseconds followed by 0V of y milliseconds means the 0 bit. The 1 bit is represented by a pulse of 5V of 2x milliseconds”. It’s a bit more complex than that, also defining TCP-like features with data frames and ACK packets, but you get the idea. It’s something that both devices agree on so that they can send raw bytes using 5 volt pulses.
I’ve created Lunar as an adaptive brightness app for macOS after finding out about a little CLI called ddcctl: https://github.com/kfix/ddcctl
That’s where I learned how DDC packets look like, where to place the payload (brightness value between 0 and 100, input ID, etc) and how to write that to the monitor using the macOS I2C APIs.
When Apple Silicon came out, none of that was possible anymore so I had to go looking around kernel assembly and private macOS frameworks for “the Apple Silicon way” of writing data through I2C.
If you’re also curious how I learned that, it’s a very cool domain called “reverse engineering” and I learned it while working as a Malware Researcher at Bitdefender. A bit hard to get started, but so many gems to discover once you know how to open binaries in IDA/Hopper and look around their disassembled code.
These HDMI ports use an internal MCDP29xx chip to convert the HDMI signal to DisplayPort. That chip supports DDC, but the method we use to write the DDC commands to the monitor (IOAVServiceWriteI2C) fails when used through it.
There are other WriteI2C methods specifically for this chip inside the DCPAVFamilyProxy.kext but they’re not available to be used inside an app like Lunar.
Asahi Linux shouldn’t be limited by the API, but the problem might be in the MCDP chip firmware itself. 1 year later, I’m still investigating new methods to fix this but so far I have no results.
Thank you as well! It’s nice to see I’m really solving problems and saving people time and frustration. That’s the only thing I like to create software for.
Before finding a way to use DDC on Apple Silicon [1] for Lunar (https://lunar.fyi), I contemplated creating a universal DDC/CI device that can change brightness, contrast, volume, input and colors of a monitor, by either receiving commands through HTTP, or acting as an Adaptive Brightness standalone device.
In my mind, it would have been an HDMI dongle with an ESP32 that gets power through the 5V line of the HDMI port, and which has an ambient light sensor to adapt brightness by itself.
In the end, I found the I2C APIs on M1 so this was not so sorely needed anymore, but given the limitations of the M1 Display Coprocessor, I still think it might be a good idea. I just have no idea where would I start with hardware distribution and mass production, this domain seems so intangible from the software development side.
[1] https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/