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.
> 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.
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?
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.
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.
Sometimes this may be intentional design to lower compatibility and cause these problems intentionally, but often it is just bad engineering, not malice.