On 01/17/15 12:34, David Herrmann wrote: > Hi > > On Sat, Jan 17, 2015 at 1:32 PM, Topi Miettinen <toiwo...@gmail.com> wrote: >> 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, > > Sure, if the hardware does not support power-down, it will not work. > >>> >>> 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. > > No, we still need clamping! In case your hardware has 256 brightness > levels, we really don't want a brightness of 1 as it would still be > far too dark.
How could you know that? The display can be too bright for the poor user even at 4%. -Topi > > Thanks > David > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
