Nouveau - May 2015 - [Bug 90351] New: [Regression, bisected] Backlight of internal eDP display doesn't turn off any more (Dell XPS 17/GeForce GT 555M)

https://bugs.freedesktop.org/show_bug.cgi?id=90351

            Bug ID: 90351
           Summary: [Regression, bisected] Backlight of internal eDP
                    display doesn't turn off any more (Dell XPS 17/GeForce
                    GT 555M)
           Product: xorg
           Version: git
          Hardware: Other
               URL: https://bugzilla.redhat.com/show_bug.cgi?id=1123661
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: erik-freedesktop-bugzilla at vanpienbroek.nl
        QA Contact: xorg-team at lists.x.org

Created attachment 115605
  --> https://bugs.freedesktop.org/attachment.cgi?id=115605&action=edit
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 at 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 at 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150506/2ed1dc74/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90351

--- Comment #1 from Erik van Pienbroek <erik-freedesktop-bugzilla at
vanpienbroek.nl> ---
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)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151101/64b4a801/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90351

Erik van Pienbroek <erik-freedesktop-bugzilla at vanpienbroek.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #115605|0                           |1
        is obsolete|                            |

--- Comment #2 from Erik van Pienbroek <erik-freedesktop-bugzilla at
vanpienbroek.nl> ---
Created attachment 128201
  --> https://bugs.freedesktop.org/attachment.cgi?id=128201&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161126/ede10f4d/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90351

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #3 from Martin Peres <martin.peres at free.fr> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/7e39eaf2/attachment.html>