Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann <dannybaumann@web.de>]

Hi,

>> Thus far our assumption always was that the acpi backlight works better
>> than the intel native backlight. So everything only uses the intel
>> backlight if there's no other backlight driver by default.
>
> There are machines, such as the pnv netbook on my desk, on which
> intel_backlight does nothing and the only control is through
> acpi_backlight0.

That's fine - but on my machine, (at least currently) it's the other way 
around. acpi_video[0|1] do nothing, while intel_backlight is the only 
method that works. This sucks (please also see my reply to Daniel), but 
it's a fact.

> Generalising expected behaviour based on one firmware
> implementation is fraught with danger.

I'm not sure what you mean here. I interpret the statement as 'user 
space should treat acpi_videoX and intel_backlight differently'. Is this 
interpretation correct?
If so, how is user space supposed to know how the respective backlight 
device will behave, as this behaviour might change at any point in time 
if there's no understanding in how it _should_ behave? What currently 
happens on my machine is that KDE completely turns off the backlight 
after the dim timeout, because it assumes that the value 0 will keep the 
backlight at a readable level (which would be the case if it used 
acpi_videoX because this behaviour is mandated by the spec there). I 
first thought of sending a patch to KDE, but I couldn't figure out how 
KDE is _supposed_ to correctly handle the situation, especially given 
that the actual sysfs interface used is abstracted away by Xrandr (and 
chosen by the Intel Xorg driver). With my patch, intel_backlight behaves 
in a way that roughly matches the behaviour mandated by the ACPI spec.
Do you have a way in mind that allows fixing this in user space?

Thanks,

Danny