nouveau: dark screen after suspend/resume

[Jesse Brandeburg]

Nouveau works fine with brightness controls working fine after initial boot, but I do S3 suspend, and then resume via power button, and brightness controls don't work at all, and backlight is on, but set at extremely low level.

hardware is Quadro 770M on HP 8530w laptop

/sys/.../brightness control does nothing when in this state,
suspend resume cycles after this first cycle all have the same problem.

I'll test if a full hibernate has the issue or not after this and report back.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu7
Uname: Linux 3.3.0-rc1+ x86_64
.tmp.unity.support.test.1:

ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,move,compiztoolbox,grid,vpswitch,gnomecompat,place,session,snap,mousepoll,regex,resize,imgpng,unitymtgrabhandles,wall,animation,workarounds,expo,fade,ezoom,scale,unityshell]
CompositorRunning: None
Date: Tue Jan 24 15:57:58 2012
DistUpgraded: Log time: 2011-10-20 21:20:49.957387
DistroCodename: oneiric
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 nVidia Corporation G96M [Quadro FX 770M] [10de:065c] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company Device [103c:30e7]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
MachineType: Hewlett-Packard HP EliteBook 8530w
PccardctlIdent:
 Socket 0:
   product info: "RICOH", "Bay8Controller", "", ""
   manfid: 0x0000, 0x0000
   function: 254 (unknown)
PccardctlStatus:
 Socket 0:
   3.3V 16-bit PC Card
   Subdevice 0 (function 0) bound to driver "pata_pcmcia"
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.3.0-rc1+ root=UUID=824346e6-fd2f-4916-a2c9-e883c1fe860c ro splash quiet vga=771 crashkernel=384M-2G:64M,2G-:128M quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to oneiric on 2011-10-21 (95 days ago)
Xrandr: Screen 0: minimum 0 x 0, current 3200 x 1200, maximum 4096 x 4096
dmi.bios.date: 12/13/2010
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68PDV Ver. F.13
dmi.board.name: 30E7
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 90.27
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68PDVVer.F.13:bd12/13/2010:svnHewlett-Packard:pnHPEliteBook8530w:pvrF.13:rvnHewlett-Packard:rn30E7:rvrKBCVersion90.27:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP EliteBook 8530w
dmi.product.version: F.13
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.6+bzr20110929-0ubuntu6
version.ia32-libs: ia32-libs 20090808ubuntu26
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20110811.g93fc084-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2.1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1

[Auke-n (auke-n)]

Created attachment 49565
vbios

After a suspend/resume cycle, my brightness is stuck to some low value which can't be changed with the brightness buttons or nvapoke 0x61c084 0x80000200. Both of these do work before suspend.

Output of "nvapeek 0x61c084" (both before and after suspend/resume):
0061c084: 00000401

Attached is /sys/kernel/debug/dri/0/vbios.rom.

[Auke-n (auke-n)]

Created attachment 49572
dmesg|grep nouveau

dmesg|nouveau after said suspend/resume cycle

[Emil-l-velikov (emil-l-velikov)]

Hi Auke

Would you consider this as a regression ?

Looking at your stripped log I can see "ACPI backlight interface available, not registering our own", thus I would say that the issue is not related to nouveau

Although can you please try the following

1 Boot into runlevel 3
   Append " 3" to your kernel command line

2 Make sure that nouveau is not loaded - "lsmod" will tell you if it is
2.1 Possible solution - blacklist nouveau

3 Try to adjust the brightness via acpi
3.1 Look for *brightness* in /sys/devices/
   find /sys/devices -name "*bright*" 2>/dev/null

4 Suspend
   pm-suspend

5 Resume

6 Try to adjust the brightness again

7 Confirm/dismiss if it is a nouveau related issue

I hope it helps

Cheers,
Emil

[Guido Trentalancia (guido.trentalancia-deactivatedaccount)]

Please note that when I compared the openSUSE/jobermayr tree with mine from upstream, I found that the drm kernel module shipped by jobermayr and tagged as 20110721.2009-2.3 on openSUSE does ship separate and different ACPI bits (at least there should be differences in the include files).

I do not know if that helps... Here it does not even specify the version or whether it something that suddenly stopped working or otherwise something that never worked.

[Emil-l-velikov (emil-l-velikov)]

Correction

3.1 Look for brightness and/or backlight in /sys
   find /sys -name "*brightness*" -o -name "*backlight*"

Most likely you will have files similar to

ls /sys/devices/pci0000:00/0000:00:0c.0/0000:02:00.0/backlight/acpi_video0/

  brightness actual_brightness max_brightness

You will have /sys/class/backlight, as well
Note that the /sys/class/backlight/acpi_video0 (or similar) should point to the above entry

Cheers
Emil

[Auke-n (auke-n)]

Emil:
As you suggested, I booted without nouveau into a terminal. Indeed I have these interfaces in /sys, and before suspend/resume I could control brightness as usual. After suspend/resume, the screen stayed black (supposedly the backlight was completely off). Blindly starting X, which loaded nouveau, turned the screen on and gave me the fixed low brightness as described earlier. Seems like it's not a nouveau issue after all, so what do I do now?

Guido:
This is an Arch Linux install, with linux 2.6.39, nouveau-dri 7.10.3 and an xf86-video-nouveau driver that's said to be version 0.0.16_git20110531.

[Skeggsb (skeggsb)]

Can I get the output of the following, both before and after suspend/resume

nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe100 8; nvapeek 0xe280 8

[Skeggsb (skeggsb)]

Correction:

nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8

[Auke-n (auke-n)]

Can't really say if it's a regression, but it hasn't worked for me in a while and I never bothered fixing it.

# ./nvapeek 0xe100; ./nvapeek 0xe28c; ./nvapeek 0xe104 8; ./nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000180
0000e104: 72266640 0441474b
0000e280: 24444747 00000000

UPower suspend...

# ./nvapeek 0xe100; ./nvapeek 0xe28c; ./nvapeek 0xe104 8; ./nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000180
0000e104: 72266240 0441474b
0000e280: 24444747 00000000

[Skeggsb (skeggsb)]

Heh. Okay.. Well, everything I know of on the GPU side that's relevant to the backlight level appears to be in order.. So, I'm out of ideas for the moment.

[Emil-l-velikov (emil-l-velikov)]

Auke

Can you try the following

1. Boot with "nouveau.force_post=1" appended to your kernel command like
2. Do not suspend, but simply try to change the brightness

If it is stuck then the issue may be nouveau related, if not ...

Btw have you tried the blob ? Does it have the same issue

Cheers
Emil

[Rick-hendricksen (rick-hendricksen)]

I have the exact same problem as Auke, for as long as I have the laptop (about 2 years). This problem used to occur with the blob as well (if I remember correctly) but it does work now.
I am using an HP Elitebook 8530w (nVidia Corporation G96M [Quadro FX 770M] (rev a1)) on fedora 15.
dmesg says: nouveau 0.0.16 20090420
yum says: xorg-x11-drv-nouveau.x86_64 1:0.0.16-24.20110324git8378443.fc15
mesa-dri-drivers: 7.11-1

(In reply to comment #10)
> Auke
>
> Can you try the following
>
> 1. Boot with "nouveau.force_post=1" appended to your kernel command like
> 2. Do not suspend, but simply try to change the brightness
>
> If it is stuck then the issue may be nouveau related, if not ...
>
> Btw have you tried the blob ? Does it have the same issue
>
>
> Cheers
> Emil

Brightness control does not work with this option for me.

[Emil-l-velikov (emil-l-velikov)]

Rik

Can you please indicate what exactly do you mean with

"Brightness control does not work with this option for me."

Does it work before suspending the system?

Can you please attach your dmesg log, as it is the one relevant in this case (whereas xf86-video-nouveau, mesa and libdrm are not)

Auke, Rik

AFAIK brightness/backlight is(can be) controlled via
1. ACPI
2. platform specific - (asus-laptop, samsung-laptop, thinkpad ...)
3. the gpu/card itself

On various system different ones work correctly

By default nouveau does not register it's device if an ACPI one exists
Note that the blob has similar behaviour but they have an option to override it.

If you suspect that the ACPI backlight control is buggy you can disable it by appending "acpi_backlight=vendor" to your kernel command line

This will fall back to either 2. or 3. - dmesg will tell you which one

Feel free to give it a try

Cheers
Emil

[Rick-hendricksen (rick-hendricksen)]

(In reply to comment #12)
> Rik
>
> Can you please indicate what exactly do you mean with
>
> "Brightness control does not work with this option for me."
>
> Does it work before suspending the system?
Brightness control does not work before suspend, I did not try suspending. So no.
> Can you please attach your dmesg log, as it is the one relevant in this case
> (whereas xf86-video-nouveau, mesa and libdrm are not)

will post in a few minutes (need to get laptop)

>
> Auke, Rik
>
> AFAIK brightness/backlight is(can be) controlled via
> 1. ACPI
> 2. platform specific - (asus-laptop, samsung-laptop, thinkpad ...)
> 3. the gpu/card itself
>
> On various system different ones work correctly
>
> By default nouveau does not register it's device if an ACPI one exists
> Note that the blob has similar behaviour but they have an option to override
> it.
>
> If you suspect that the ACPI backlight control is buggy you can disable it by
> appending "acpi_backlight=vendor" to your kernel command line

I tried that. It works exactly the same as without this option. Brightness control works fine before suspend, fails after.

> This will fall back to either 2. or 3. - dmesg will tell you which one
>
> Feel free to give it a try
>
> Cheers
> Emil

[Rick-hendricksen (rick-hendricksen)]

Created attachment 51586
Dmesg output for the various testcases

dmesgbacklightisvendor.txt : using acpi_backlight=vendor
dmesgforcepost.txt : using nouveau.force_post=1
dmesgnormal.txt : default

[Emil-l-velikov (emil-l-velikov)]

(In reply to comment #13)
[snip]
> Brightness control does not work before suspend, I did not try suspending. So
> no.
[snip]
> I tried that. It works exactly the same as without this option. Brightness
> control works fine before suspend, fails after.

I see a bit of contradiction in here

Firstly can you try nouveau kernel git tree [1], as it includes some patches regarding backlight/brightness

Note: Fedora may have precompiled package that is up-to date (search for koji)

If it still fails please record the following

example
"with option "xxxxx" (acpi_backlight=vendor, nouveau.force_post=1)
before suspend - works, after - stuck"

it may be worth checking the registers (see comment 7) in each case as well

Cheers
Emil

[1] http://cgit.freedesktop.org/nouveau/linux-2.6/

[Rick-hendricksen (rick-hendricksen)]

(In reply to comment #15)
> (In reply to comment #13)
> [snip]
> > Brightness control does not work before suspend, I did not try suspending. So
> > no.
> [snip]
> > I tried that. It works exactly the same as without this option. Brightness
> > control works fine before suspend, fails after.
>
> I see a bit of contradiction in here
>
> Firstly can you try nouveau kernel git tree [1], as it includes some patches
> regarding backlight/brightness
>
> Note: Fedora may have precompiled package that is up-to date (search for koji)

I cloned the git repo you linked, and compiled my kernel (which works), but it has the exact same issues as before.
$ uname -r
3.1.0-rc7+

> If it still fails please record the following
>
> example
> "with option "xxxxx" (acpi_backlight=vendor, nouveau.force_post=1)
> before suspend - works, after - stuck"
>
with option: none
before suspend: works, after: stuck to low value
with option: nouveau.force_post=1
before suspend: stuck to low value, after: stuck to low value
with option: acpi_backlight=vendor
before suspend: works, after: stuck to low value
with option: acpi_backlight=vendor nouveau.force_post=1
before suspend: stuck to low value, after: stuck to low value

> it may be worth checking the registers (see comment 7) in each case as well

Maybe tomorrow, it took me long enough to get that kernel working. (I need envytools right?)

> Cheers
> Emil
>
> [1] http://cgit.freedesktop.org/nouveau/linux-2.6/

[Emil-l-velikov (emil-l-velikov)]

(In reply to comment #16)
> with option: none
> before suspend: works, after: stuck to low value
> with option: nouveau.force_post=1
> before suspend: stuck to low value, after: stuck to low value
> with option: acpi_backlight=vendor
> before suspend: works, after: stuck to low value
> with option: acpi_backlight=vendor nouveau.force_post=1
> before suspend: stuck to low value, after: stuck to low value

Thanks this is great

>
> > it may be worth checking the registers (see comment 7) in each case as well
>
> Maybe tomorrow, it took me long enough to get that kernel working. (I need
> envytools right?)
Yes you would need envytools

Peeks for "none" and "nouveau.force_post=1" would be enough - before and after suspend
Can you attach your vbios as well please [2]

[2] $ nvagetvbios > vbios.rom

Cheers
Emil

>
> > Cheers
> > Emil
> >
> > [1] http://cgit.freedesktop.org/nouveau/linux-2.6/

[Rick-hendricksen (rick-hendricksen)]

(In reply to comment #17)
> Peeks for "none" and "nouveau.force_post=1" would be enough - before and after
> suspend
normal boot:

# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000
# pm-suspend
# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000

using option: nouveau.force_post=1

# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000
# pm-suspend
# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000

> Can you attach your vbios as well please [2]
>
> [2] $ nvagetvbios > vbios.rom

nvagetvbios didnt exist, so I used nvagetbios (I assume you made a typo)
>
> Cheers
> Emil
>

[Rick-hendricksen (rick-hendricksen)]

Created attachment 51716
rick's vbios

[Auke-n (auke-n)]

Any updates regarding this bug?

[Jesse Brandeburg (jesse-brandeburg)]

At the time the report was generated I had tried to boot to latest upstream kernel to test nouveau (which is broken) but this issue is against stock Ubuntu kernel 3.0.0-14

[Jesse Brandeburg (jesse-brandeburg)]

I am experiencing this bug as well, HP 8530W, brightness controls don't work after resume.

[Jesse Brandeburg (jesse-brandeburg)]

I tried force_post=1, screen is dark even before suspend (even before going into X, just loading frame buffer) - this is a clue the driver is forcing the brightness into this mode, right?

Of course, the tip of tree nouveau won't even load now due to the MXM changes, so I haven't been able to test *it* yet, but that is another bug that I'm trying to help narrow down.

[Walther (walther-md)]

There should be a solution to this dilemma, considering that nvidia's binary blob does it correctly.

I got the nvapeek results for using the binary blob, and the results I got are:

Before
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000

After
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000

Notice that unlike nouveau, register 0xe104's content is unaltered after resuming. What is this particular register for?

The vbios before suspending is identical between nouveau and nvidia, and it is also identical to the one after resuming with nvidia. However, nvgetbios fails with nouveau after resuming:

./nvagetbios > vbios.txt
No extraction method specified (using -s extraction_method). Defaulting to PRAMIN.
Attempt to extract the vbios from card 0 (nv96) using PRAMIN
Invalid signature(0x55aa). You may want to try another retrieval method.

Is this a sign that the vbios is somehow wrong/corrupted after resume?

Note that I am also using a Elitebook 8530W, with an nVidia Corporation G96M [Quadro FX 770M] card, using Linux 3.1.10.

[Emil-l-velikov (emil-l-velikov)]

Did you have the chance to test a kernel that includes the following commit

"drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues"

It does rework the gpio handling and initialization (among other things), that should have positive effect on your issue

It is part of linux 3.3rc1 [1] as well as nouveau linux tree [2]

Cheers
Emil

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=a0b25635515ef5049f93b032a1e37f18b16e0f6f

[2] http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a0b25635515ef5049f93b032a1e37f18b16e0f6f

[Jesse Brandeburg (jesse-brandeburg)]

Hi Emil, thanks. Behavior is unchanged with new kernels. I've tested through nouveau commit:

commit 9a0a03b43176ee676693232f2afe92b83b15233e
Author: Roy Spliet <email address hidden>
Date: Tue Feb 7 00:29:06 2012 +0100

    drm/nouveau/pm: several fixes for nvc0 memory timings

and 3.3.0-rc2 (actually the above is on top of)
which contains a0b2563

commit 62aa2b537c6f5957afd98e29f96897419ed5ebab
Author: Linus Torvalds <email address hidden>
Date: Tue Jan 31 13:31:54 2012 -0800

    Linux 3.3-rc2

with no change, from that patch or any other.

in fact nvapeek (nouveau git with 3.3.0-rc2) shows:
before suspend:
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000

after:
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444747 00000000

the only difference I see is e104 bit 10 being set before, and not after.

NOTE: I have the exact same laptop as Walther.

[Walther (walther-md)]

I repeated testing using kernel 3.3.0 RC4, and results are similar:

nvapeek (before):
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72267640 0441474b
0000e280: 44444747 00000000

After:
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72267240 0441474b
0000e280: 44444747 00000000

Compared to the previous version, the only change is that 0x1000 was added to 0xe104 (and 0x400 is still unset on resume). And, of course, brightness controls ceased to response after resuming.

PS: What still worries me is that after resuming nvagetbios still fails, that is a definite vbios bug/corruption somewhere, isn't it...

[Jesse Brandeburg (jesse-brandeburg)]

Is there anything I can do to help fix this? Willing to provide any data and debug, including remote access if that would help.

[Bugs-30-kappa (bugs-30-kappa)]

Experiencing a similar issue on a Lenovo W510 (FX880m), Fedora 17 Beta RC3, with the difference that after suspend the brightness is set to max, after that brightness controls do not work (nor do echos to /sys/..). Things are fine with the NVIDIA driver.

[Bugs-30-kappa (bugs-30-kappa)]

Is there a way I can help by providing more information or trying a new version?

[Kdebugs (kdebugs)]

Congratulations on going stable! I am experiencing this issue as well, and this is the one bug keeping me from using Nouveau. I would really like to have xrandr 1.2 support, so please let me know if there is anything I could provide to help troubleshoot this.

Notes:
Thinkpad W510

01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [Quadro FX 880M] (rev a2)

When using the nvidia driver, the following option needs to be added to the X config file.
Option "RegistryDwords" "EnableBrightnessControl=1"

When using the nouveau driver, brightness controls works fine. After suspend and resume, brightness stuck on max.

[Clayton Dillard (claytondillard)]

I'm having the same issue on Precice Pangolin Ubuntu 12.04 running on an HP 8530w with the Quadro card.

I loaded 11.10 on an HP 8740w with a newer Nvidia card and don't have this issue.

Still stuck though on my 8530.

[clrelay (cl-relay)]

Applies to me as well on a W510

Linux w510 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[ThGravo (even-more-spam-for-me)]

Also affects Gentoo with x11-drivers/xf86-video-nouveau-0.0.16_pre20120322 and kernel 3.4.3-gentoo.
I'm on a HP8530w, too.

[Emil-l-velikov (emil-l-velikov)]

It appears that even the blob was experiencing the same issue [1]

Affected blob 180.44, fixed in 180.60. I would expect that a specific quirk was added to handle the issue

[1] http://www.bartromgens.org/wordpress/?p=274

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris00 (chris00)]

(In reply to comment #32)

I confirm that this issue is present on the Thinkpad W510 with the driver from kernel 3.6.0.

[Chris00 (chris00)]

The problem is still present in the git version of the driver.

[Clayton Dillard (claytondillard)]

When is a fix for this expected?

[Chris00 (chris00)]

Still present in kernel 3.6.2, even with acpi_backlight=vendor nouveau.force_post=1 and "Support for backlight control" disabled in the kernel configuration.

The funny thing is that the display seem to come back at the right brightness initially and then is changed to max brightness a second after.

Like many people, this bug unfortunately prevents me to switch to the free driver. It would be really nice if it was fixed.

[Emil-l-velikov (emil-l-velikov)]

Created attachment 68764
Enable the PANEL_BACKLIGHT_LEVEL GPIO

Guys can you try the patch. It should apply against the latest nouveau tree

[Walther (walther-md)]

I couldn't get the git kernel, so I tried that patch against linux-3.7-rc3. Unfortunately, it didn't change anything in my set up (Elitebook 8530w, NVIDIA Corporation G96M [Quadro FX 770M] card).

[AG Restringere (ag-restringere-deactivatedaccount)]

Can you check bug #1015297 and see if that describes your issue? This might be a duplicate...

[Jesse Brandeburg (jesse-brandeburg)]

this is NOT a duplicate of #1015297. The issue likely still exists (although I am unable to test anymore as my laptop has been replaced)

[Skeggsb (skeggsb)]

This bug is likely fixed in current nouveau kernel git.

[AG Restringere (ag-restringere-deactivatedaccount)]

Skeggsb, someone has reported a bug similar to this on Launchpad.net in Ubuntu and was wondering if you can give more information on this potential fix and when it will be released...

[AG Restringere (ag-restringere-deactivatedaccount)]

Forgot to include a link: https://bugs.launchpad.net/nouveau/+bug/921321

[Ilia Mirkin (imirkin)]

Can someone confirm that this is fixed in newer kernels as Ben said it should be?

[Rick-hendricksen (rick-hendricksen)]

This bug is still present.

[root@s094648 rick]# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266640 0441474b
0000e280: 44444747 00000000
[root@s094648 rick]# systemctl suspend
[root@s094648 rick]# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000100
0000e104: 72266240 0441474b
0000e280: 44444444 00000000
[root@s094648 rick]# uname -a
Linux s094648 3.10.10-1-ARCH #1 SMP PREEMPT Fri Aug 30 11:30:06 CEST 2013 x86_64 GNU/Linux

[Ilia Mirkin (imirkin)]

What backlight driver is being used? Please post your dmesg. Are you booting with acpi_backlight=vendor ?

[Rick-hendricksen (rick-hendricksen)]

Created attachment 84974
DMESG kernel 3.10.10

[Rick-hendricksen (rick-hendricksen)]

(In reply to comment #41)
> What backlight driver is being used? Please post your dmesg. Are you booting
> with acpi_backlight=vendor ?

No, I am booting with the following command line:
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=d30907c8-9c00-4b4f-9dfb-b01990328a7a rw loglevel=3

Also, is there an IRC channel or something I could join to speed up communication regarding this bug?

[R-spliet (r-spliet)]

(In reply to comment #36)
> Created attachment 68764 [details] [review]
> Enable the PANEL_BACKLIGHT_LEVEL GPIO
>
> Guys can you try the patch. It should apply against the latest nouveau tree

NACK on this patch: this particular pin should be driven by a PWM in SOR, as indicated in 0xe100. Rather look if routing from PWM to GPIO pin is correct...

[R-spliet (r-spliet)]

Created attachment 85010
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised

Auke, Rick, Jesse: please test the attached patch. It should initialise PWM_DIV on both boot and resume, solving your problems _if_ this routine is called after running the initscripts. Please test to verify this is the case.

[R-spliet (r-spliet)]

Created attachment 85012
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v2)

V2 fixes the reach of this patch.
From what I can tell the PWM_DIV is simply a divider for the initial PWM clock or something, it does not affect the scope of the duty cycle. I therefore assume 0x5e is always a good value to set. Traces from NV50:NVA0 would help verify whether NVIDIA always sets this value or not.
This patch requires acpi_backlight=vendor to be set because it tests for the presence of a backlight by testing drm->backlight. An alternative to this test would be checking for the GPIO to be present and routed to SOR, but I wouldn't be surprised if there is at least one device that expects our driver to route it manually. How should we go about this?

[AG Restringere (ag-restringere-deactivatedaccount)]

This bug report is being closed due to your last comment:

"although I am unable to test anymore as my laptop has been replaced"

For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

[Erik Karlsson (pilo)]

I can confirm that the patch "drm/nv50: Fix backlight[...](v2)" works for a HP 8530w. Any chance of getting this included upstream?

[Anonymous-dodgeit (anonymous-dodgeit)]

Created attachment 100635
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v3)

Applying Roy's 0001-drm-nv50-Fix-backlight-not-working-when-PWM_DIV-is-u.patch (v2) to linux-3.15-rc8 results in a compilation error.

...
  CC drivers/gpu/drm/nouveau/nouveau_display.o
drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_display_init’:
drivers/gpu/drm/nouveau/nouveau_display.c:400:5: error: ‘drm’ undeclared (first use in this function)
  if(drm->backlight)
     ^
drivers/gpu/drm/nouveau/nouveau_display.c:400:5: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:318: recipe for target 'drivers/gpu/drm/nouveau/nouveau_display.o' failed
make[4]: *** [drivers/gpu/drm/nouveau/nouveau_display.o] Error 1
scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm/nouveau' failed
make[3]: *** [drivers/gpu/drm/nouveau] Error 2
scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:465: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:878: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Resolved by adding the following line to the beginning of the nouveau_display_init function in nouveau_display.c:

        struct nouveau_drm *drm = nouveau_drm(dev);

I tried to make a patch and attach it - not sure if I did it right.

This patch successfully resolved the "backlight brightness stuck at minimum after waking up from suspend" issue on my HP Elitebook 8530w.

Thank you, Roy! Your code has improved my life significantly.

[Erik Karlsson (pilo)]

Not to be a nag, but multiple people have confirmed that the patch fixes the problem. What are the prerequisites for merging this?

[Erik Karlsson (pilo)]

Created attachment 113754
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v4)

I redid the patch for 3.18.6. Not sure what the use of removed nvif_rd32() chunk was, but it doesn't seem to be necessary anymore.

Could this fix be predicated on the specific PCI ID if the effects are uncertain?

[Rspliet (rspliet)]

(In reply to Erik Karlsson from comment #50)
> Created attachment 113754 [details] [review]
> drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v4)
>
> I redid the patch for 3.18.6. Not sure what the use of removed nvif_rd32()
> chunk was, but it doesn't seem to be necessary anymore.
>
> Could this fix be predicated on the specific PCI ID if the effects are
> uncertain?

No, the value of NV50_PDISP_SOR_PWM_DIVis not derived from the PCI ID. Judging by some other traces I've seen, we can't just unconditionally set 0x5e to NV50_PDISP_SOR_PWM_DIV. Rather, someone needs to step up and figure out how this parameter is correctly determined, which requires some RE'ing work on a laptop that actually has it's brightness controlled by the NVIDIA GPU rather than ACPI or some other backlight component. Only then a patch like this can be merged.

[Erik Karlsson (pilo)]

Is this reverse engineering something I could do myself using software, or does it require active fiddling with the registers?

[Jeff Miller (jefferym)]

I have an NVAC (MCP79) in an iMac9,1 for which the backlight controls do not work if NV50_PDISP_SOR_PWM_DIV(0x61c080) is set to 0x5e. If it is useful at all I have attached an mmiotrace dump with from various backlight control setting changes using the nvidia blob in another bug report (#98677).

[Erik Karlsson (pilo)]

I got the patch working in 4.9.6. But in 4.17.3 the backlight controls no longer work after suspend.

Wierdly though, the "nvapeek" output is the same after suspend as before:
# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000180
0000e104: 72266640 0441474b
0000e280: 24444747 00000000
...suspend...
# nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
0000e100: 001c1100
0000e28c: 00000180
0000e104: 72266240 0441474b
0000e280: 24444747 00000000

Something else has changed. Will bisect.

[Erik Karlsson (pilo)]

According to a bisect, the commit f00f0e218b5d6347f28c0f2d80ee46c45b28f3c3 killed the patch.

[Erik Karlsson (pilo)]

Wrong commit, redid the bisect. 839ca903f12ef8f09374e0b655456482536a733e is the new suspect.

[Erik Karlsson (pilo)]

Created attachment 140871
drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v5)

Patch modified to work with 4.17.9.

[Martin-peres-n (martin-peres-n)]

-- 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/20.