Bug 90351 - [Regression, bisected] Backlight of internal eDP display doesn't turn off any more (Dell XPS 17/GeForce GT 555M)
Summary: [Regression, bisected] Backlight of internal eDP display doesn't turn off any...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-06 21:36 UTC by Erik van Pienbroek
Modified: 2019-12-04 08:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Patch which resolves the issue on the internal display for me (976 bytes, patch)
2015-05-06 21:36 UTC, Erik van Pienbroek 		no flags Details | Splinter Review
debug logging k.8.8-300.nvmst.fc25.x86_64 (3.96 MB, text/plain)
2016-11-26 14:52 UTC, Erik van Pienbroek 		no flags Details
Show Obsolete (1) View All

Description Erik van Pienbroek 2015-05-06 21:36:08 UTC 
Created attachment 115605 [details] [review]
Patch which resolves the issue on the internal display for me

This bug was already filed quite some time ago in the Fedora bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1123661) but due to lack of response there I've now filed the bug here. Here's a recap of the details mentioned in the downstream bug report:

Between kernel 3.16.0-0.rc0.git9.1 and 3.16.0-0.rc0.git10.1 a regression got introduced. After this kernel update the backlight on the internal display on my notebook (Dell XPS 17/Geforce GT 555M) doesn't turn off any more.

Together with Hans de Goede we tried some additional kernel boot parameters (like acpi_backlight=vendor) but those didn't resolve the issue.

The issue is still valid with the latest 4.1 development kernels on a Fedora 22 environment.

A git bisect was done to find out the exact commit which caused the regression and this turned out to be:

commit 4874322e78d505d38c8d4481118af5c9f0e8306d
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Sat May 31 01:48:06 2014 +1000

    drm/nouveau/dp: fix support for dpms
    
    SOR_PWR has no effect to power-off DP links, unlike other SOR protocols.
    
    Instead, on the source side, we cut power to the lanes after having put
    the sink into D3.  Link training takes care of everything required to
    bring it back again.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


By now the code in question has seen some rewrites, but I found out that removing the "args.pwr.state = 1;" instruction from the nv50_sor_dpms function (see attached patch) resolves the issue for me. With this change the backlight of the internal display on my notebook now properly turns off whenever I try to lock my desktop.

Unfortunately this patch doesn't resolve all display related issues I'm having with nouveau. There's also an external display connected to my notebook (using a mini-DP connection) which shows a similar issue. Whenever I lock my desktop the external display goes black (with the backlight off), but after about 8 seconds the backlight suddenly turns back on and remains on. The backlight on my internal display remains off (with the patch applied). I've tested various kernels (from 3.16 to current 4.1) and none are able to properly turn off the external display (it may have worked in the past, but I can't get it reproduced at the moment).

Any ideas where to go from here?
Comment 1 Erik van Pienbroek 2015-11-01 22:22:29 UTC 
This bug still exists on kernel 4.3.0-rc7.
The patch mentioned here still behaves the same as mentioned in the initial bug report (backlight of internal display can be turned off, but externally connected DP displays fail to be turned off)
Comment 2 Erik van Pienbroek 2016-11-26 14:52:46 UTC 
Created attachment 128201 [details]
debug logging k.8.8-300.nvmst.fc25.x86_64

The nouveau atomic modesetting changes have arrived recently in the drm-next tree. I did some testing with a recent drm-next git checkout and the situation has improved regarding this bug, but it's not fully solved yet. The findings were also discussed in downstream bug report https://bugzilla.redhat.com/show_bug.cgi?id=1123661 but I'll also share them here.

Initial testing was done with drm-next git rev d8c1abd, dated 20161111. With this kernel I can confirm that with no external monitors connected the backlight of the internal laptop monitor now turns off properly when the GNOME session is locked. So we can consider that part of this bug report resolved (the patch which was uploaded to this bug report earlier can be considered obsolete now)

However, when an external monitor is attached (using a mini-DP-to-DP adapter) and powered on as well then locking the GNOME session results in the behaviour which was also mentioned in comment 0, that is: the backlight of both the internal monitor and the external monitor initially turn off properly, but after 8 seconds the backlight of both monitors suddenly turns back on while the image on both monitors stays blank. When I press any key or move the mouse the image comes back normally and I can unlock the GNOME session and resume work.

As suggested by Hans de Goede in the downstream bug report I also did testing with a custom Fedora kernel which was prepared by Ben Skeggs recently (containing a backport of the nouveau atomic modesetting changes: https://copr.fedorainfracloud.org/coprs/bskeggs/nouveau-atomic-mst) but that kernel also showed the same issue.

I managed to collect debug logging from both nouveau and gnome-settings-daemon (using kernel boot flags 'log_buf_len=8M nouveau.debug=disp=trace,i2c=trace drm.debug=0x14' and running gnome-settings-daemon with the '--debug' argument) and uploaded it to both this bug report.  In this logging these are the related timestamp events:
nov 21 19:05:53 - Boot of kernel 4.8.8-300.nvmst.fc25.x86_64
nov 21 19:07:00 - Pressed Super+L to lock the GNOME session
(both monitors turns off now including both backlights)
nov 21 19:07:08 - Backlight of both the internal and the external monitors turn back on automatically showing just a blank screen
nov 21 19:07:29 - Unlock of the GNOME session
Comment 3 Martin Peres 2019-12-04 08:58:51 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/186.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.