I'm currently working on an ASUS GL702VMK. This machine is shipping a GeForce GTX 1060 GP106 (136000a1) connected to an internal DisplayPort on DFP-5 (usual 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 value in there is not working anyway.
Trying to manually poke NV50_PDISP_SOR_PWM_CTL(1) with `nvapoke` has no effect whatsoever on the brightness (on or==1)
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.
Created attachment 130784 [details]
vbios + mmiotrace
In attachment (tar + xz -9):
- 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/trace_marker
echo "XSET100IN" > /sys/kernel/debug/tracing/trace_marker
&& xbacklight -set 100 -steps 1
&& echo "XSET100OUT" > /sys/kernel/debug/tracing/trace_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 xbacklight.
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 <= 0xff
> MMIO32 W 0x00d980 0x0000007f PGPIO+0x980 <= 0x7f
< MMIO32 W 0x619484 0x0000ff00 PDISPLAY.VGA.CR+0x84 <= 0xff00
> MMIO32 W 0x619484 0x00007000 PDISPLAY.VGA.CR+0x84 <= 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 ever run with free software: https://www.theregister.co.uk/2015/04/15/nvidia_gtx_900_linux_driver_roadbloack/
Sell this crappy GP102 card (in your case the notebook that contains this crap) 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 from beeing able to boot the software they want on THEIR hardware - 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 key or close their doors.
Blocking the freedom of the users on such way should not be accepted by anyone.
(In reply to caguduzexi from comment #5)
> I wont recommend using/keeping the GP106 (GTX 1060). It cant ever run with
> free software:
> Sell this crappy GP102 card (in your case the notebook that contains this
> crap) 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 from beeing able to boot the software they want on THEIR hardware -
> 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 key or
> close their doors.
> Blocking the freedom of the users on such way should not be accepted by
(In reply to Carlo Caione from comment #4)
> 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 <= 0xff
> > MMIO32 W 0x00d980 0x0000007f PGPIO+0x980 <= 0x7f
> < MMIO32 W 0x619484 0x0000ff00 PDISPLAY.VGA.CR+0x84 <= 0xff00
> > MMIO32 W 0x619484 0x00007000 PDISPLAY.VGA.CR+0x84 <= 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.
Can you check that this is fixed in 4.16-rc6? A fix landed to address backlight problems and it might be the same you had: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.16-rc6&id=9e75dc61eaa9acd1bff83c3b814ac2af6dc1f64c
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 display output and backlight. I'm sure that it would be a much less painful experience.
Well... Enough with ranting! Since you suggested that this may have been fixed 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 issue, 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 correct?
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 instructions 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])
Flags: bus master, fast devsel, latency 0, IRQ 132
Memory at db000000 (32-bit, non-prefetchable) [size=16M]
Memory at b0000000 (64-bit, prefetchable) [size=256M]
Memory at c0000000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Expansion ROM at dc000000 [disabled] [size=512K]
Capabilities:  Power Management version 3
Capabilities:  MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities:  Express Endpoint, MSI 00
Capabilities:  Virtual Channel
Capabilities:  Latency Tolerance Reporting
Capabilities:  L1 PM Substates
Capabilities:  Power Budgeting <?>
Capabilities:  Advanced Error Reporting
Capabilities:  Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Capabilities:  #19
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
Additionally, the display doesn't turn on again after an "xset dpms force off" (bug #103383); this may well be related.
Created attachment 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.
*** Bug 106305 has been marked as a duplicate of this bug. ***
I confirm that adding the line "case NV_DEVICE_INFO_V0_PASCAL:" over latest kernel git makes it work on my MSI GT73VR 6RF Titan Pro. Will attach the file for testing purposes.
Created attachment 139241 [details]
nouveau_backlight.c working on msi gt73vr 6rf titan pro
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
This is in Ben's tree now:
And should make its way to kernel 5.1.
Er, make that 5.0. It's in 5.0-rc2.