osx_battery_charge_limit VS ddcctl

That's true. I evaluated it, but it wasn't of use to me as I keep my Macbook plugged in with the lid closed.

I eventually tried this instead :

https://github.com/DevNulPavel/osx_battery_charge_limit

I use it to keep my battery level indicator pegged at 70%. Often doesn't persist after a system update, but it's just a quick terminal command to reapply the setting.

I use my Macbook in clamshell mode, and I use sleep mode when I'm not using it - receiving power from a Thunderbolt dock. It's handy to pick up exactly where I left off on resume. Plus, I use two LG screens where one of the two doesn't switch on after a cold boot, and it's annoying to unplug and replug to activate it. Sleep mode gets around that.

Target display mode was removed somewhere around macos high sierra. It’s just controlled by setting an smc key so you might be able to make a program set that smc key for you. The key itself is explained here https://floe.butterbrot.org/matrix/hacking/tdm/ and a similar approach to this for setting a limit on how much the battery charges could be used to set the key https://github.com/DevNulPavel/osx_battery_charge_limit

I personally use this https://github.com/DevNulPavel/osx_battery_charge_limit

Aldente works, but for Intel machines I used this command line based program https://github.com/DevNulPavel/osx_battery_charge_limit

I'm not sure if it fully works with the new M1 machines, but I use this.

There are some other command line based open-source alternatives as well, like ddctl and m1ddc - the former only works on Intel, the latter on M1 Macs (M2 Pro and HDMI is not supported). Lunar has great CLI support as well for those who want a command-line based solution.

https://github.com/kfix/ddcctl is what you are looking for! It works on my dell and asus monitors at least.

Only TB supports DDC? https://github.com/kfix/ddcctl

I received the same diagnostic in 2017, which coincided with the year I got my first external monitor for my MacBook. Headaches and eye pain became a more common occurence in the first weeks, until I stumbled upon ddcctl [0] and the fact that monitor brightness can be changed from the OS.

That's when I developed the first version of Lunar (https://lunar.fyi) to adapt brightness automatically throughout the day based on the sun position in the sky. (reading the light sensor was not possible at the time)

That combined with Night Shift (macOS native version of f.lux) fixed most of my problems.

I also tried blue light filter glasses but the only effect they had was removing more money from my savings. I feel like this is just modern day snake oil for computer workers.

In the end, what fixed all of my problems was a LASIK [1] operation (well actually PRK because I had only a small abberation). I still recommend this to all my friends and relatives who are always complaining about their vision. It did change my life.

I still cringe when someone turns on an overhead lightbulb though, I never use those in my home. Turns out this wasn't my astigmatism, it's just that most LED bulbs are simply too bright single point lights.

I fit my home with TRADfri warm light lamps hidden behind sofa/door/desk [2], WLED-powered [3] LED strips and simple string lights (like you can see in the front page video on https://lowtechguys.com/volum/)

[0] https://github.com/kfix/ddcctl

[1] https://en.wikipedia.org/wiki/LASIK

[2] https://www.ikea.com/gb/en/p/tradfri-remote-control-kit-smar...

[3] https://kno.wled.ge/

macOS apps which I share at https://lowtechguys.com/ bring me $7k/month on average at the moment, and it keeps growing.

It started in 2017 when I shared the first free and open source version of Lunar (https://lunar.fyi/), an app for controlling monitors.

At that time, there was only a command line for doing this stuff (https://github.com/kfix/ddcctl) and I wanted a more visual way of changing the brightness. So I learned Swift, learned how to bridge the ddcctl C code and call it from Swift, then made a rough interface and published it: https://www.producthunt.com/products/lunar#lunar-5

It turned out people did have a need for this and asked if they could donate. I set up a Buy me a Coffee page and in 4 years collected about $5k in donations. That's a lot of money for a Romanian.

When Apple Silicon appeared, Lunar didn't work anymore because the whole hardware arrangement and drivers were different, and there was no documentation on how to send I²C data. I took the plunge and quit my stressful job, bought an M1 MacBook and reverse engineered the I²C communication: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/

Then published Lunar 4 as a Free version with a Pro paid upgrade. I was reluctant with this, didn't think anyone would buy it, but to this day I'm able to be unemployed and put my ideas into practice because of it.

ddcctl - DDC monitor controls for the OSX command line

Not really sure if ddcctl could help or is related to ddcutil, but in all case I had no chance with it.

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.

[1] https://milek7.pl/ddcbacklight/mccs.pdf