[whalesalad]

Funny... I am trying to learn how to patch my own debian stable kernel with an (incomplete) kernel patch submitted for adjusting the backlight on an Apple Studio Display. The monitor - to my surprise - works really great with my Debian 12 workstation via a displayport->usb-c converter cable. But (in typical Apple fashion) there is not a single button on the display to adjust brightness and the kernel doesn't support this monitor.

The patch is quite simple: https://lore.kernel.org/lkml/20230701120806.11812-1-julius@z...

But I haven't been able to make the time to sit down and 1. respond to the feedback (original author hasn't yet) and 2. try and apply it to the otherwise standard Debian kernel.

Aside from this issue linux on the desktop has been quite pleasant, and of course this issue is not the fault of Linux per say. Deb12/KDE/Wayland/AMDGPU

[nomel]

> and the kernel doesn't support this monitor

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

[sho_hn]

The kernel doesn't necessarily need to know about every monitor specifically, there's lots of standards that divide this space into broad categories. But some hardware does custom things that need individual drivers, e.g. use the USB channels to announce a custom device with its own proprietary protocol.

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

[whalesalad]

    > 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.

[BenjiWiebe]

It's hardware, and usually userspace can't talk directly to hardware.

[nomel]

Sounds like an abstraction is appropriate. We could call it a "device driver". Is there a reason so many things get baked into the kernel, rather than using, say, kernel modules?

[whalesalad]

Pretty sure this is what DDC is supposed to solve. https://en.wikipedia.org/wiki/Display_Data_Channel which is why this EDID post reminded me of this problem.

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.

[sho_hn]

Relatively few things need to actually be baked into the kernel. Most features in the kernel codebase can be built as a module at will, especially drivers.

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.

[t-8ch]

The latest version of that patch is here: https://lore.kernel.org/lkml/20230820094118.20521-2-julius@z...

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 ```

[whalesalad]

this is really helpful - thanks!

[Arch-TK]

>original author hasn't yet

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.

[whalesalad]

ah nice - i hadn't seen any additional activity so was gonna try and run with it on my own but thanks for the info