https://bugzilla.kernel.org/show_bug.cgi?id=208661
Bug ID: 208661 Summary: Backlight doesn't work with both nv_backlight and acpi_video Product: Drivers Version: 2.5 Kernel Version: 5.7.0-1-amd64 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: iknstudio@protonmail.com Regression: No
Created attachment 290457 --> https://bugzilla.kernel.org/attachment.cgi?id=290457&action=edit vbios.rom
Hi,
I'm trying to get backlight working on this laptop. I am using the nouveau driver, and kernel 5.7. I tried a few different parameters for acpi_osi=, like the following: - acpi_osi=linux - acpi_osi=! acpi_osi="Windows 2012" - acpi_osi=! acpi_osi="Windows 2015" however, none of them worked. /sys/class/backlight/*/bl_power is 0 for both devices at boot. acpi_video0 has a max_brightness of 10 while nv_backlight has a max brightness of 100.
I am attaching the vbios. The graphics card is nVidia GT540M.
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #1 from Shannon Gaines (iknstudio@protonmail.com) --- Created attachment 290477 --> https://bugzilla.kernel.org/attachment.cgi?id=290477&action=edit acpidump.txt
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #2 from Shannon Gaines (iknstudio@protonmail.com) --- Update: nvidia-legacy-390xx driver allows me to change the backlight via acpi_video0, however nouveau doesn't under any circumstances. No clue why.
https://bugzilla.kernel.org/show_bug.cgi?id=208661
Ilia Mirkin (imirkin@alum.mit.edu) changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imirkin@alum.mit.edu
--- Comment #3 from Ilia Mirkin (imirkin@alum.mit.edu) --- So given that this works via acpi_video with NVIDIA's drivers, this suggests to me that nouveau is either doing something it shouldn't, which breaks the acpi method, or it doesn't do something which enables the acpi method to work.
Unfortunately I'm not an expert on the ACPI stuff, so we need to
1. Figure out how acpi_video works (BCL method? something like that) 2. Find the method in the acpi dump, and decode it 3. Profit...
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #4 from Shannon Gaines (iknstudio@protonmail.com) --- As suggested in IRC, I tried nouveau.modeset=0. It didn't help with the backlight issue, without or without non-free firmware. So I believe the issue isn't related to modesetting.
To be clear, I tested: - nouveau + modeset=0 + no firmware - nouveau + no firmware - nouveau + modeset=0 + firmware - nouveau + firmware
And nothing helped.
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #5 from Shannon Gaines (iknstudio@protonmail.com) --- Created attachment 290549 --> https://bugzilla.kernel.org/attachment.cgi?id=290549&action=edit mmiotrace for nvidia initialization
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #6 from Ilia Mirkin (imirkin@alum.mit.edu) --- After a lot of debugging on IRC, here are a few facts that are worth recording:
1. The nv_backlight "method" works -- i.e. the backlight is hooked up to the GPU. Adjusting brightness via acpi_video connects to the same mechanism somehow. We didn't dig too deep to figure out how, since it's not really important.
2. At the start of the mmiotrace, the NVIDIA driver fixes up 0xe100 ("PNVIO.GPIO_MODE_0") to be have the 0x4 bit set of the SOR mask. On bootup it's 0x00180100, while it should be 0x001c0100.
3. This is equivalent to what we do in nv50_gpio_reset. This function is called in response to the "GPIO" init table method (which, one might mention, is present in the init tables).
4. Manually setting this value (via nvapoke) makes nv_backlight work. Doing suspend/resume, which causes init tables to be re-run, makes nv_backlight also work, since the init table contains the GPIO opcode.
5. Regular boot with NvForcePost=1 kills the panel (and maybe other things).
Not sure what the solution is. Right now we run nv50_gpio_reset unconditionally on MBP10,1. We can start extending the DMI table with random laptops, or maybe we can just run that function unconditionally. Is there a downside?
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #7 from Shannon Gaines (iknstudio@protonmail.com) --- Created attachment 290619 --> https://bugzilla.kernel.org/attachment.cgi?id=290619&action=edit Patch to add NvForceGpioReset config option
I created a patch that allows users to force a GPIO reset everytime the GPU is initialized as a work-around for this bug. I've attached it.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org