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