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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
