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

David Herrmann dh.herrmann at gmail.com
Sat Jan 17 04:19:57 PST 2015


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.

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.

Thanks
David


More information about the systemd-devel mailing list