Created attachment 290457 [details] 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.
Created attachment 290477 [details] acpidump.txt
Update: nvidia-legacy-390xx driver allows me to change the backlight via acpi_video0, however nouveau doesn't under any circumstances. No clue why.
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...
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.
Created attachment 290549 [details] mmiotrace for nvidia initialization
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?
Created attachment 290619 [details] 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.