4 ms·

To be more specific, which ever attaches first. Firmware controls (ACPI) are favoured over the native hardware controls (drm). https://marc.info/?l=openbsd-cvs

To be more specific, which ever attaches first. Firmware controls (ACPI) are favoured over the native hardware controls (drm). https://marc.info/?l=openbsd-cvs&m=149989034626478&w=2 https://marc.info/?l=openbsd-cvs&m=149989034626478&w=2 On OpenBSD, RandR xbacklight(1) often just works out of the box, and as the author of the article writes, involves much less magic than the rituals involving systemd on Linux. Perhaps your Linux bias is showing little as you attempt to justify the complexity of the interfaces Linux provides.. care to go for a round on epoll(2), a botched attempt at copying kqueue(2)? Or how about getrandom(2), a Linux kitchen sink that sprung out of OpenBSD getentropy(2).

mjg59 8y ago
If acpivideoout and thinkpad both attach then whichever attaches second will win - you're right that i915 special cases this. The author of the article describes doing an ioctl() on the console, which is a different codepath to any brightness properties attached to the connector, so if the OpenBSD DRM implementation is exposing the latter on chipsets other than i915 then you're still going to have two different codepaths to get broader coverage (and it's still broken on Apples) I'm not interested in defending Linux in general, I'm just pushing back against the idea that a low complexity implementation is inherently preferable to a more complex one. All else being equal that's true, but if the additional complexity is associated with additional useful functionality then it's really up to the person making that claim to demonstrate that a less complex implementation could provide the same functionality or to make it clear that they're ok with not satisfying the use cases that require that functionality.
- hedora 8y ago
  The article is arguing for a low complexity API. The complexity of an interface is only loosely coupled to the complexity of the implementation. The article even hints at a better solution than what Linux or OpenBSD do: Add backlight control in a away that provides 1:1 (or 1:0) mapping between display devices and backlights by, for example, adding the backlight API to the display device file. A naming convention for device files would also work. So would a directory of device files associated with a given screen. You could even have a device file that lets you tell the kernel if it should use ACPI or something else, assuming you don’t like the default. What doesn’t work is the status quo in Linux, where there’s a 50% chance I have to implement a new shell script that futzes with some one-off device file in /sys every time I buy a new laptop. (And then use xbindkeys, or whatever to make the keyboard shortcut work) Fixing this would require the type of thankless work that never quite gets done in the Linux kernel. I suspect it is because no one has a financial motivation to fix things like this, but they do have a financial motivation to bring up new hardware and to strong-arm through platform lock in plays like systemd. edit: and thank you for libbacklight. It works beautifully on the other laptops. :-)
  - mjg59 8y ago
    The biggest problem is that the policy association between what the hardware and firmware provide and what the expected behaviour is vary between releases of Windows, and so having the kernel make that kind of association leads to problems. The goal of doing stuff with a userland library was to leave the mechanism up to the kernel (ie, expose the various different ways of driving the hardware) and allow userland to make a policy decision over which interface was least likely to cause confusion. If you're having to write shell scripts then there's absolutely a failure - but I haven't bought a laptop in years where that's been the case (and I stopped doing this stuff professionally a few years ago, so I really do appreciate stuff working out of the box). Desktop environments should be providing the necessary glue to bind keys to something that can make an appropriate decision while still allowing overrides for the corner cases that the kernel can't catch. Systemd actually makes it easier to handle a lot of these -it provides a centralised mechanism for exposing platform-specific quirks to other userland components. I'm not going defend every systemd design decision, but honestly it's been an improvement for everything discussed in this post.

mjg59 8y ago

If acpivideoout and thinkpad both attach then whichever attaches second will win - you're right that i915 special cases this. The author of the article describes doing an ioctl() on the console, which is a different codepath to any brightness properties attached to the connector, so if the OpenBSD DRM implementation is exposing the latter on chipsets other than i915 then you're still going to have two different codepaths to get broader coverage (and it's still broken on Apples) I'm not interested in defending Linux in general, I'm just pushing back against the idea that a low complexity implementation is inherently preferable to a more complex one. All else being equal that's true, but if the additional complexity is associated with additional useful functionality then it's really up to the person making that claim to demonstrate that a less complex implementation could provide the same functionality or to make it clear that they're ok with not satisfying the use cases that require that functionality.

hedora 8y ago
The article is arguing for a low complexity API. The complexity of an interface is only loosely coupled to the complexity of the implementation. The article even hints at a better solution than what Linux or OpenBSD do: Add backlight control in a away that provides 1:1 (or 1:0) mapping between display devices and backlights by, for example, adding the backlight API to the display device file. A naming convention for device files would also work. So would a directory of device files associated with a given screen. You could even have a device file that lets you tell the kernel if it should use ACPI or something else, assuming you don’t like the default. What doesn’t work is the status quo in Linux, where there’s a 50% chance I have to implement a new shell script that futzes with some one-off device file in /sys every time I buy a new laptop. (And then use xbindkeys, or whatever to make the keyboard shortcut work) Fixing this would require the type of thankless work that never quite gets done in the Linux kernel. I suspect it is because no one has a financial motivation to fix things like this, but they do have a financial motivation to bring up new hardware and to strong-arm through platform lock in plays like systemd. edit: and thank you for libbacklight. It works beautifully on the other laptops. :-)
- mjg59 8y ago
  The biggest problem is that the policy association between what the hardware and firmware provide and what the expected behaviour is vary between releases of Windows, and so having the kernel make that kind of association leads to problems. The goal of doing stuff with a userland library was to leave the mechanism up to the kernel (ie, expose the various different ways of driving the hardware) and allow userland to make a policy decision over which interface was least likely to cause confusion. If you're having to write shell scripts then there's absolutely a failure - but I haven't bought a laptop in years where that's been the case (and I stopped doing this stuff professionally a few years ago, so I really do appreciate stuff working out of the box). Desktop environments should be providing the necessary glue to bind keys to something that can make an appropriate decision while still allowing overrides for the corner cases that the kernel can't catch. Systemd actually makes it easier to handle a lot of these -it provides a centralised mechanism for exposing platform-specific quirks to other userland components. I'm not going defend every systemd design decision, but honestly it's been an improvement for everything discussed in this post.