On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote:
> Note that it is read after the framebuffer has been resized and a new mode
> has been set on "pipe 0 using LVDS1", could this perhaps cause the 0 to be
> read when using actual_brightness ?
Indeed, that is likely the explanation, and shows the fallacy in the
current approach. And also explains why acpi_backlight works with the
current code, but that the kernel interfering with intel_backlight does
not.
> Also I've just had a user who has been testing this patch come back to
> me it does help, but he still has a suspend/resume issue. It seems that
> some X app / gnome-component is doing the following:
>
> 1) DPMS off
> 2) Read backlight xrandr property -> this will now return 0
> 3) Set backlight xrandr property value to the value just read, aka 0
> 4) DPMS on -> "restores" backlight to 0 because of the property set
>
> I believe the best way to fix this will be to make
> xxx_output_get_property("backlight") return backlight_active_level
> when in DPMS off, rather then calling xxx_output_backlight_get.
I had the same thought when reviewing the code following your email. I
modified sna, but I think I want to restructure how backlight is saved
around modesets.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
