Created attachment 49565 [details] 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.
Created attachment 49572 [details] dmesg|grep nouveau dmesg|nouveau after said suspend/resume cycle
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
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.
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
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.
Can I get the output of the following, both before and after suspend/resume nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe100 8; nvapeek 0xe280 8
Correction: nvapeek 0xe100; nvapeek 0xe28c; nvapeek 0xe104 8; nvapeek 0xe280 8
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
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.
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
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.
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
(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
Created attachment 51586 [details] Dmesg output for the various testcases dmesgbacklightisvendor.txt : using acpi_backlight=vendor dmesgforcepost.txt : using nouveau.force_post=1 dmesgnormal.txt : default
(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/
(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/
(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/
(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 >
Created attachment 51716 [details] rick's vbios
Any updates regarding this bug?
I am experiencing this bug as well, HP 8530W, brightness controls don't work after resume.
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.
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.
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
Hi Emil, thanks. Behavior is unchanged with new kernels. I've tested through nouveau commit: commit 9a0a03b43176ee676693232f2afe92b83b15233e Author: Roy Spliet <r.spliet@student.tudelft.nl> 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 <torvalds@linux-foundation.org> 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.
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...
Is there anything I can do to help fix this? Willing to provide any data and debug, including remote access if that would help.
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.
Is there a way I can help by providing more information or trying a new version?
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.
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
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
(In reply to comment #32) I confirm that this issue is present on the Thinkpad W510 with the driver from kernel 3.6.0.
The problem is still present in the git version of the driver.
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.
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
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).
This bug is likely fixed in current nouveau kernel git.
Can someone confirm that this is fixed in newer kernels as Ben said it should be?
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
What backlight driver is being used? Please post your dmesg. Are you booting with acpi_backlight=vendor ?
Created attachment 84974 [details] DMESG kernel 3.10.10
(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?
(In reply to comment #36) > Created attachment 68764 [details] [review] [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...
Created attachment 85010 [details] [review] 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.
Created attachment 85012 [details] [review] 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?
I can confirm that the patch "drm/nv50: Fix backlight[...](v2)" works for a HP 8530w. Any chance of getting this included upstream?
Created attachment 100635 [details] [review] 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.
Not to be a nag, but multiple people have confirmed that the patch fixes the problem. What are the prerequisites for merging this?
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?
(In reply to Erik Karlsson from comment #50) > Created attachment 113754 [details] [review] [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.
Is this reverse engineering something I could do myself using software, or does it require active fiddling with the registers?
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).
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.
According to a bisect, the commit f00f0e218b5d6347f28c0f2d80ee46c45b28f3c3 killed the patch.
Wrong commit, redid the bisect. 839ca903f12ef8f09374e0b655456482536a733e is the new suspect.
Created attachment 140871 [details] [review] drm/nv50: Fix backlight not working when PWM_DIV is uninitialised (v5) Patch modified to work with 4.17.9.
-- 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.
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.