| Bug ID | 100446 |
|---|---|
| Summary | Backlight control not working on Pascal / GP106 using nouveau= drivers |
| Product | xorg |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Driver/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | carlo@caione.org |
| QA Contact | xorg-team@lists.x.org |
I'm currently working on an ASUS GL702VMK. This machine is shi= pping a GeForce GTX 1060 GP106 (136000a1) connected to an internal DisplayPort on DFP-5 (us= ual AU Optronics Corporation). Using the unmodified latest nouveau drivers I have no backlight control. Modifying nouveau_backlight.c adding a case for NV_DEVICE_INFO_V0_PASCAL I finally get /sys/class/backlight/nv_backlight/ but changing the backlight v= alue in there is not working anyway. Trying to manually poke NV50_PDISP_SOR_PWM_CTL(1) with `nvapoke` has no eff= ect whatsoever on the brightness (on or=3D=3D1) Backlight control is not working using the proprietary 375 / 378 drivers either. Also in this case the value of NV50_PDISP_SOR_PWM_CTL is actually changed by `xbacklight` but with no visible effect. Any hint?
Created attachment 130784 =
[details]
vbios + mmiotrace
In attachment (tar + xz -9):
- vbios
- mmiotrace
- demmio'd mmiotrace
The trace was taken in pure Xorg with only xterm running and:
echo "XSET50IN" > /sys/kernel/debug/tracing/trace_marker
&& xbacklight -set 50 -steps 1
&& echo "XSET50OUT" > /sys/kernel/debug/tracing/tr=
ace_marker
sleep 2
echo "XSET100IN" > /sys/kernel/debug/tracing/trace_marker
&& xbacklight -set 100 -steps 1
&& echo "XSET100OUT" > /sys/kernel/debug/tracing/t=
race_marker
I forgot: the mmiotrace was taken using the proprietary NVIDIA= drivers 381.09 (beta). With this version I'm able to change the brightness using xbackligh= t.
For the sake of completeness some more info on this. The two settings differ only for couple of accesses: < MMIO32 W 0x00d980 0x000000ff PGPIO+0x980 <=3D 0xff --- > MMIO32 W 0x00d980 0x0000007f PGPIO+0x980 <=3D= 0x7f < MMIO32 W 0x619484 0x0000ff00 PDISPLAY.VGA.CR+0x84 <=3D 0xff00 --- > MMIO32 W 0x619484 0x00007000 PDISPLAY.VGA.CR+0x8= 4 <=3D 0x7000 The problem is that poking at those registers using nvapeek / nvapoke doesn= 't change the brightness. Also trying to use nvammiotracereplay to reply step-by-step the mmio trace = has no effect on the brightness.
I wont recommend using/keeping the GP106 (GTX 1060). It cant e= ver run with free software: https://www.theregister.co.uk/2015/04/15/nvidia_gtx_900_l= inux_driver_roadbloack/ https://www.phoronix.com/scan.php?page=3Dnews_item&px=3DNo= uveau-XDC2017 https://www.phoronix.com/scan.php?page=3Dnews_item&= px=3DNouveau-XDC2016-NVIDIA Sell this crappy GP102 card (in your case the notebook that contains this c= rap) away and go away from nvidia. Nvidia died with the 780ti card. Its the last end-user card that can be used normaly. Everything else is in some countries even a legal problem. Because the manufacturer (nvidia) blocks the users fr= om beeing able to boot the software they want on THEIR hardware - happyly ille= gal in some countries. Hopefully some layer would sue the heck out of nvidia so that they would have to release the private signing key or close their door= s. Blocking the freedom of the users on such way should not be accepted by any= one.
(In reply to caguduzexi from comment #5) > I wont recommend using/keeping the GP106 (GTX 10= 60). It cant ever run with > free software: > https://www.ther= egister.co.uk/2015/04/15/ > nvidia_gtx_900_linux_driver_roadbloack/ > https://www.phoronix.com/scan.php?page=3Dnews_item&= px=3DNouveau-XDC2017 > https://www.phoronix.com/scan.php?page=3Dnews_it= em&px=3DNouveau-XDC2016-NVIDIA >=20 > Sell this crappy GP102 card (in your case the notebook that contains t= his > crap) away and go away from nvidia. Nvidia died with the 780ti card. I= ts the > last end-user card that can be used normaly. Everything else is in some > countries even a legal problem. Because the manufacturer (nvidia) bloc= ks the > users from beeing able to boot the software they want on THEIR hardwar= e - > happyly illegal in some countries. Hopefully some layer would sue the = heck > out of nvidia so that they would have to release the private signing k= ey or > close their doors. > Blocking the freedom of the users on such way should not be accepted by > anyone. User banned
(In reply to Carlo Caione from comment #4) > For the sake of completeness some more info on t= his. >=20 > The two settings differ only for couple of accesses: >=20 > < MMIO32 W 0x00d980 0x000000ff PGPIO+0x980 <=3D 0xff > --- > > MMIO32 W 0x00d980 0x0000007f PGPIO+0x980 <=3D 0x7f >=20 > < MMIO32 W 0x619484 0x0000ff00 PDISPLAY.VGA.CR+0x84 <=3D 0xff00 > --- > > MMIO32 W 0x619484 0x00007000 PDISPLAY.VGA.CR+0x84 <=3D 0x7000 >=20 > The problem is that poking at those registers using nvapeek / nvapoke > doesn't change the brightness. >=20 > Also trying to use nvammiotracereplay to reply step-by-step the mmio t= race > has no effect on the brightness. Can you check that this is fixed in 4.16-rc6? A fix landed to address backl= ight problems and it might be the same you had: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= ?h=3Dv4.16-rc6&id=3D9e75dc61eaa9acd1bff83c3b814ac2af6dc1f64c
I have the same problem on an ASUS GL502VM with a GTX 1060 6GB= . UNFORTUNATELY this laptop shipped with G-SYNC enabled, which means that the Intel GPU is completely disabled and everything goes through/is controlled by the NVIDIA GPU. I would rather have no G-SYNC but having the Intel GPU driving the dis= play output and backlight. I'm sure that it would be a much less painful experie= nce. Well... Enough with ranting! Since you suggested that this may have been fi= xed by a recent kernel update, I have tested a Fedora 28 Workstation Live Image that comes with the 4.16rc6 kernel. But the problem persists. >From what I could understand, even if the 4.16 corrects the underlying issu= e, the nouveau driver still needs to be changed and manually recompiled as suggested by the OP because backlight support for Pascal-based cards is not enabled by that switch statement. The "NV_DEVICE_INFO_V0_PASCAL" = clause is missing in the "nvidia_backlight.c" file. Is this assessment corr= ect? Also, feel free to ask me for any further information that may help you to fully support backlight control for Pascal GPUs. I may need some instructio= ns on how to gather some lower level information, but I'll gladly do it if you think that it may help.
Still happens with 4.16.0 final on an hp omen 17-an0xx laptop.
GPU details from lspci:
01:00.0 0300: 10de:1be1 (rev a1) (prog-if 00 [VGA controller])
Subsystem: 103c:8393
Flags: bus master, fast devsel, latency 0, IRQ 132
Memory at db000000 (32-bit, non-prefetchable) [size=3D16M]
Memory at b0000000 (64-bit, prefetchable) [size=3D256M]
Memory at c0000000 (64-bit, prefetchable) [size=3D32M]
I/O ports at e000 [size=3D128]
Expansion ROM at dc000000 [disabled] [size=3D512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [250] Latency Tolerance Reporting
Capabilities: [258] L1 PM Substates
Capabilities: [128] Power Budgeting <?>
Capabilities: [420] Advanced Error Reporting
Capabilities: [600] Vendor Specific Information: ID=3D0001 Rev=3D1 =
Len=3D024
<?>
Capabilities: [900] #19
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
Additionally, the display doesn't turn on again after an "xset dpms fo=
rce off"
(bug #103383); this may well be rel=
ated.
Created attachm= ent 138646 [details] [review]= Proposed fix, relative to 4.16.0 The combination of the fix in 4.16-rc and the hint from the first comment on the bug did it -- backlight control works (at least on my hp Omen) with this patch on top of 4.16.0.
| What | Removed | Added |
|---|---|---|
| CC | reportbug@mailna.biz |
*** Bug 106305 has been marked as a du= plicate of this bug. ***
I confirm that adding the line "case NV_DEVICE_INFO_V0_PA= SCAL:" over latest kernel git makes it work on my MSI GT73VR 6RF Titan Pro. Will attach the fi= le for testing purposes.
Created attachment 139241 [details]
nouveau_backlight.c working on msi gt73vr 6rf titan pro
Related? https://bug= zilla.gnome.org/show_bug.cgi?id=3D688052
Any reason why this hasn't been fixed yet given that it seems = to be an easy fix?
(In reply to Pedro Albuquerque Santos from comment #15) > Any reason why this hasn't been fixed yet given = that it seems to be an easy > fix? This is in Ben's tree now: https://github.com/skeggsb/nouveau/commit/a9133adc009eb= 3b982fb27d073e5087e63187b23 And should make its way to kernel 5.1.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEW | RESOLVED |