linux-kernel - Re: [BUG] drm/i915: backlight off after resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87fvbkz7nd.fsf@intel.com>
Date:	Fri, 09 Jan 2015 10:21:26 +0200
From:	Jani Nikula <jani.nikula@...ux.intel.com>
To:	Jeremiah Mahler <jmmahler@...il.com>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	David Airlie <airlied@...ux.ie>,
	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [BUG] drm/i915: backlight off after resume

On Fri, 09 Jan 2015, Jeremiah Mahler <jmmahler@...il.com> wrote:
> Jani, all,
>
> On a Lenovo X1 Carbon if the display is off when suspend is entered
> it will be off when it is resumed.  A key must be pressed to restore
> normal brightness.

Please file a bug on [1] and attach dmesg with drm.debug=14 set, from
boot to reproducing the problem.

Thanks for the report.

BR,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

>
>   xset dpms force off
>   sleep 1
>   sudo systemctl suspend
>   (resume)
>   (screen off, press any key)
>
> The behavior I am accustomed to is for it to resume with the screen on.
> All of my other machines behave this way and the X1 Carbon behaved this
> way in the past.
>
> I performed a bisect and found that the following commit introduced the
> problem.
>
>   From 6dda730e55f412a6dfb181cae6784822ba463847 Mon Sep 17 00:00:00 2001
>   From: Jani Nikula <jani.nikula@...el.com>
>   Date: Tue, 24 Jun 2014 18:27:40 +0300
>   Subject: [PATCH] drm/i915: respect the VBT minimum backlight brightness
>   
>   Historically we've exposed the full backlight PWM duty cycle range to
>   the userspace, in the name of "mechanism, not policy". However, it turns
>   out there are both panels and board designs where there is a minimum
>   duty cycle that is required for proper operation. The minimum duty cycle
>   is available in the VBT.
>   
>   The backlight class sysfs interface does not make any promises to the
>   userspace about the physical meaning of the range
>   0..max_brightness. Specifically there is no guarantee that 0 means off;
>   indeed for acpi_backlight 0 usually is not off, but the minimum
>   acceptable value.
>   
>   Respect the minimum backlight, and expose the range acceptable to the
>   hardware as 0..max_brightness to the userspace via the backlight class
>   device; 0 means the minimum acceptable enabled value. To switch off the
>   backlight, the user must disable the encoder.
>   
>   As a side effect, make the backlight class device max brightness and
>   physical PWM modulation frequency (i.e. max duty cycle)
>   independent. This allows a follow-up patch to virtualize the max value
>   exposed to the userspace.
>   
>   Signed-off-by: Jani Nikula <jani.nikula@...el.com>
>   Reviewed-by: Jesse Barnes <jbarnes@...tuousgeek.org>
>   [danvet: s/BUG_ON/WARN_ON/]
>   Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
>
> -- 
> - Jeremiah Mahler

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/