From patchwork Fri Jun 6 14:39:35 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 4312111 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 0A0CB9F23C for ; Fri, 6 Jun 2014 14:39:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DED572020F for ; Fri, 6 Jun 2014 14:39:44 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id DFFED201CD for ; Fri, 6 Jun 2014 14:39:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4DA196E38E; Fri, 6 Jun 2014 07:39:43 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTP id 339636E38E for ; Fri, 6 Jun 2014 07:39:41 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s56Edb0B027621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 6 Jun 2014 10:39:38 -0400 Received: from shalem.localdomain (vpn1-4-89.ams2.redhat.com [10.36.4.89]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s56EdZmg013625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 10:39:36 -0400 Message-ID: <5391D2A7.7060407@redhat.com> Date: Fri, 06 Jun 2014 16:39:35 +0200 From: Hans de Goede User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Chris Wilson , Jani Nikula , intel-gfx@lists.freedesktop.org References: <1401976118-8780-1-git-send-email-hdegoede@redhat.com> <8761kfe9qk.fsf@intel.com> <20140605142912.GB22214@nuc-i3427.alporthouse.com> <5390C031.4090500@redhat.com> <20140605202427.GC22214@nuc-i3427.alporthouse.com> In-Reply-To: <20140605202427.GC22214@nuc-i3427.alporthouse.com> X-Enigmail-Version: 1.6 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Subject: Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On 06/05/2014 10:24 PM, Chris Wilson wrote: > 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. And now a mail with the promised patch really attached ... Regards, Hans From c39c9f3cded6e47ae7b1899362a85bc94926a1d5 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 5 Jun 2014 14:56:56 +0200 Subject: [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off We've several reports from users where the backlight comes up turned off on starting X, when using video.use_native_backlight=1 (true dmi quirks, will be the default for 3.16), in combination with having an external display plugged in: https://bugzilla.redhat.com/show_bug.cgi?id=1032978 https://bugzilla.redhat.com/show_bug.cgi?id=1103806 This seems to be caused by /sys/class/backlight/intel_backlight/brightness reading back 0 when re-initializing the outputs. Unlike /sys/class/backlight/acpi_video0/brightness which is used without the video.use_native_backlight=1 param, which keeps returning the value from before Here is an excerpt from Xorg.log when this happens: [28225]: (II) intel(0): resizing framebuffer to 3286x1080 [28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 0 using LVDS1, position (0, 0), rotation normal [28225]: (II) intel(0): switch to mode 1920x1080@60.0 on pipe 0 using HDMI2, position (1366, 0), rotation normal [28225]: (II) intel(0): DPMS off mode 3, saved backlight level 0 ^^^ This is an extra debug line I added, mode == the mode parameter to xxx_output_dpms_backlight, saved backlight level is the value of backlight_active_level after the xxx_output_backlight_get call. Note how backlight_active_level becomes 0 here. [28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 1 using LVDS1, position (0, 0), rotation normal [28225]: (II) intel(0): DPMS on mode 0, setting backlight to 0 And here we restore the backlight to backlight_active_level which now is 0. This commit fixes this by not reading back the backlight setting from the kernel on DPMS off. Signed-off-by: Hans de Goede --- src/sna/sna_display.c | 3 --- src/uxa/intel_display.c | 3 --- 2 files changed, 6 deletions(-) diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index 13dbf64..c9d4b08 100644 --- a/src/sna/sna_display.c +++ b/src/sna/sna_display.c @@ -2323,9 +2323,6 @@ sna_output_dpms_backlight(xf86OutputPtr output, int oldmode, int mode) sna_output_backlight_set(output, sna_output->backlight_active_level); } else { - /* Only save the current backlight value if we're going from on to off. */ - if (oldmode == DPMSModeOn) - sna_output->backlight_active_level = sna_output_backlight_get(output); sna_output_backlight_set(output, 0); } } diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c index 95ddcc8..62902f4 100644 --- a/src/uxa/intel_display.c +++ b/src/uxa/intel_display.c @@ -963,9 +963,6 @@ intel_output_dpms_backlight(xf86OutputPtr output, int oldmode, int mode) intel_output_backlight_set(output, intel_output->backlight_active_level); } else { - /* Only save the current backlight value if we're going from on to off. */ - if (oldmode == DPMSModeOn) - intel_output->backlight_active_level = intel_output_backlight_get(output); intel_output_backlight_set(output, 0); } } -- 2.0.0