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

[Danny Baumann]

Hi,

>>>> Well, the ACPI spec says this (section B.5.2):
>>>>
>>>> "
>>>> The OEM may define the number 0 as "Zero brightness" that can mean
>>>> to turn off the lighting (e.g. LCD panel backlight) in the device.
>>>> This may be useful in the case of an output device that can still be
>>>> viewed using only ambient light, for example, a transflective LCD.
>>>> "
>>>>
>>>> My interpretation of this is that the value 0 is supposed to still
>>>> be visible. I'm pretty sure I saw a statement that 0 is supposed to
>>>> mean "barely visible" somewhere, but can't find it at the moment.
>>>> I'll search for the source of it.

BTW, I found the source for that statement: [1], section 
System.Client.BrightnessControls.SmoothBrightness. While formally it's 
not part of the ACPI spec, I'm pretty sure most vendors (except Apple, 
obviously) will follow it as if it were, if not more strictly.

>> OK, I see. And there is user space depending on that behaviour? And again -
>> how is user space supposed to know about the behavioral differences? Is it
>> something like 'if type is raw, don't expect anything'?
>> The reason for my question is that I want to determine what a) the correct
>> place to fix this and b) the correct fix is. As Xrandr abstracts away the
>> used backlight interface, I see no way for user space using Xrandr (e.g.
>> KDE) to meaningfully handle this.
>
> In practice does it really matter?  As a user if you set the
> brightness really low and you either can't see the screen or can
> barely make it out does it matter if the screen is off or just really,
> really dim?  The 0 brightness setting is probably not practically
> usable regardless of what it does.

That's right. I'm not intending to use the laptop with that low 
brightness, though, I'd just like to distinguish between my laptop being 
turned off / suspended or just its display being dimmed down by the 
desktop environment to conserve power. In order to do the latter, KDE 
sets brightness to 0 ([2]), which worked fine for me as long as 
acpi_video was working on this laptop. This isn't the case at present, 
which is why I'm using intel_backlight at the moment. As you may have 
noticed, things aren't working as expected with it, which in turn is 
what brought me over here ;) I'm fine with sending a patch to KDE if 
that's the correct thing to do, but I'm not yet sure what the correct 
thing to do is.

Thanks,

Danny

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
[2] 
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/actions/bundled/dimdisplay.cpp#L53