On 01/17/15 12:19, David Herrmann wrote: > Hi > > On Sat, Jan 17, 2015 at 1:10 PM, Topi Miettinen <toiwo...@gmail.com> wrote: >> On 01/17/15 12:03, David Herrmann wrote: >>> Hi >>> >>> On Sat, Jan 17, 2015 at 1:01 PM, Topi Miettinen <toiwo...@gmail.com> wrote: >>>> On 01/17/15 11:38, David Herrmann wrote: >>>>> Hi >>>>> >>>>> On Sat, Jan 17, 2015 at 12:28 PM, Topi Miettinen <toiwo...@gmail.com> >>>>> wrote: >>>>>> On my computer, the minimum brightness enforced by clamping in >>>>>> backlight is too bright. >>>>> >>>>> How can 5% of the backlight be "too bright"? Can you give some >>>>> information on your backlight device? (type, max_brightness, >>>>> actual_brightness and so on). >>>> >>>> Well, my eyes start to hurt with level 1, 0 is OK. Max_brightness is 9, >>>> actual_brightness always matches brightness. This is cheap old Acer >>>> Aspire 8530 laptop with Mobility Radeon HD 3200, I don't know beyond >>>> that what handles backlight. >>> >>> Which backlight driver is active? acpi? Or the native radeon driver? >> >> The device path is >> /sys/devices/pci0000\:00/0000\:00\:01.0/0000\:01\:05.0/backlight/acpi_video0/brightness, >> does that mean acpi? > > The problem here is, there're 2 types of backlight drivers in the kernel: > > 1) backlight==0 is interpreted as 'off' > 2) backlight==0 is interpreted as 'lowest level that is not "off"' > > There is a second switch called 'bl_power' which allows to actually > power the backlight off or on. This works on all devices the same way. > However, if we want to figure out the lowest backlight level, we > really cannot use '0' as we have no idea how the driver will interpret > it.
I see. Here, setting bl_power to 0 does nothing, > > We discussed this at the last XDC but haven't really come to a > conclusion. This is definitely a kernel bug, as user-space has no > chance of setting a backlight generically to "lowest level". If there > were a property called "min_brightness" that exposes the minimal > brightness level supported (which is not 'off'), we could parse it. > However, we don't want to write per-driver workarounds in userspace if > kernel people could just fix it. > > Conclusion: Lets try getting kernel backlight people to solve this mess. That may be the proper long term path, but because there's already a clamping workaround which does not do the right thing for all hardware, this override would be useful for such cases until the kernel is fixed. After the kernel is fixed, the clamping (along this override) should not be applied anymore. > > Thanks > David > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
