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

[David Herrmann]

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.

Thanks
David