I find it so immensely "WTF!?" that a kernel needs to know about a monitor, to change its brightness.

    > The Apple Studio Display does not have any physical buttons and the only
    > way to get or set the brightness is by sending USB control transfers to a
    > HID device exposed by the display.

Sometimes this may be intentional design to lower compatibility and cause these problems intentionally, but often it is just bad engineering, not malice.

Problem is, regular DDC utils don't know how to communicate with this particular display.

Joke is on me, I shouldn't have spent $1,500 on a display that is pretty much exclusively designed to be connected to a Mac. But I was using it with a Mac for a while before building this new Linux box.

But it's the codebase that you patch, so "patching the kernel" doesn't mean the OP ruled out building it as a module in the end. Even though they may well be able to just build it against kernel headers and even load it at runtime.

Also it should be trivial to run this as an out-of-tree module until it's merged. With DKMS or put hid_bl.c into an empty directory and add the following makefile:

``` ifneq ($(KERNELRELEASE),) # kbuild part of makefile obj-m := hid_bl.o

else # normal makefile KDIR ?= /lib/modules/`uname -r`/build

modules:

%: $(MAKE) -C $(KDIR) M=$$PWD $@

endif ```

Julius has responded to comments as recently as a week ago and is now working on a (hopefully mergable) v4.

You will probably see it in 6.7 and probably backported to stable kernels in a few months.

It will support any monitor which uses this USB control scheme (presumably a few other apple monitors).

So don't worry about making the time to address the comments. The author seems to be on top of it. Two to three months for a medium sized driver patch (such as this) to be merged seems about right to me.