4 ms·

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

by nomel 3y ago

whalesalad 3y ago
> 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 3y ago
It's hardware, and usually userspace can't talk directly to hardware.
- nomel 3y ago
  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 3y ago
    Pretty sure this is what DDC is supposed to solve. https://en.wikipedia.org/wiki/Display_Data_Channel 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 3y ago
    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.
sho_hn 3y ago
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.

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

by nomel 3y ago

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

whalesalad 3y ago

> 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 3y ago

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

nomel 3y ago
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 3y ago
  Pretty sure this is what DDC is supposed to solve. https://en.wikipedia.org/wiki/Display_Data_Channel 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 3y ago
  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.

sho_hn 3y ago

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.