[systemd-devel] [PATCH] backlight: let the administrator override clamping

[Topi Miettinen]

On 01/17/15 12:34, David Herrmann wrote:
> Hi
> 
> On Sat, Jan 17, 2015 at 1:32 PM, Topi Miettinen <toiwoton at gmail.com> wrote:
>> On 01/17/15 12:19, David Herrmann wrote:
>>> Hi
>>>
>>> On Sat, Jan 17, 2015 at 1:10 PM, Topi Miettinen <toiwoton at gmail.com> wrote:
>>>> On 01/17/15 12:03, David Herrmann wrote:
>>>>> Hi
>>>>>
>>>>> On Sat, Jan 17, 2015 at 1:01 PM, Topi Miettinen <toiwoton at gmail.com> wrote:
>>>>>> On 01/17/15 11:38, David Herrmann wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> On Sat, Jan 17, 2015 at 12:28 PM, Topi Miettinen <toiwoton at 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
>