Bug 60659
Summary: | Backlight control interface with nouveau driver for nVidia Quadro 1000m not works | ||
---|---|---|---|
Product: | Drivers | Reporter: | Charles-Antoine Couret (renault) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | NEW --- | ||
Severity: | normal | CC: | aaron.lu, alexey.brodkin, imirkin |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.11-rc3 and oldier | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Charles-Antoine Couret
2013-07-31 06:34:39 UTC
Does your dmesg log have a line like [drm] ACPI backlight interface available, not registering our own If so, that means that nouveau is skipping its backlight registration. There's some boot parameter that will force the acpi one to not register... acpi_backlight=vendor or something along those lines. Yes : [root@DiNozzo ~]# dmesg | grep backlight [ 11.400712] nouveau [ DRM] ACPI backlight interface available, not registering our own But, if I use the option : acpi_osi=Linux, acpi_backlight=vendor, acpi_backlight=vido or acpi_backlight=hp_acpi, the software acpi_listen can't detect Fn keys to change the brightness. In default, acpi_listen with Fn key to change brightness : [root@DiNozzo ~]# acpi_listen video/brightnessup BRTUP 00000086 00000000 K video/brightnessdown BRTDN 00000087 00000000 K And Gnome can detect the key pressure in default, but not with these options… OK, but does the provided driver effectively control backlight? (i.e. writing into /sys/class/backlight/...) With default option, after boot : [root@DiNozzo ~]# cat /sys/class/backlight/acpi_video0/brightness 20 Same conditions, after pressure of FN down brightness key : [root@DiNozzo ~]# cat /sys/class/backlight/acpi_video0/brightness 10 I suppose the driver can write this file after that. ;) I think we're not understanding each other... you filed this bug because nouveau wasn't registering a backlight interface. I pointed out why this was and told you how to make it register one (acpi_backlight=vendor). Then you go on to mention that booting without that, acpi_video0/brightness doesn't control the backlight... but I thought this bug was about using nouveau to control the backlight, not acpi_video... What happens when you boot with that option (but not acpi_osi=Linux/etc unless you normally boot with that)? Does the /sys/class/backlight/.../brightness registered by nouveau let you control the backlight or not? [Note, the Fn+whatever keys are entirely secondary to backlight control working.] Ah ok… Sorry, with acpi_backlight=vendor, I have /sys/class/backlight/nv_backlight/ folder (in place of /sys/class/backlight/acpi_video0/) and write in /sys/class/backlight/nv_backlight/brightness works ! It's not a bug ? No ? I am sorry, I don't find this explication on the Web… In the larger sense of "are you having a problem", yes there is a bug somewhere. But IMO it's not in the nouveau driver. Perhaps discuss this with the person on the other bug who suggested there was an issue in nouveau... I'm not sure what that is. Perhaps a quirk should be added in acpi_video, but I thought they were off of doing that... again, not sure. (In reply to Ilia Mirkin from comment #7) > In the larger sense of "are you having a problem", yes there is a bug > somewhere. > > But IMO it's not in the nouveau driver. Perhaps discuss this with the person > on the other bug who suggested there was an issue in nouveau... I'm not sure Oh, it's me who suggests there was an issue in nouveau since I don't know nouveau has a logic to check if ACPI video will support backlight control on this system and then do things accordingly. #ifdef CONFIG_ACPI if (acpi_video_backlight_support()) { NV_INFO(drm, "ACPI backlight interface available, " "not registering our own\n"); return 0; } #endif I'm not sure if this is correct, I think nouveau can always create backlight interface for user to use no matter if other module do that or not. Just my personal opinion. I have exactly the same laptop - HP Elitebook 8560w with a nVidia Quadro 1000M, NVC1 (GF108) in nouveau slang - and used to suffer from similar issue. But I've just tried Fedora 20 image for Graphics test day (http://fedorapeople.org/groups/qa/201310-Graphics_Test-mini-x86_64.iso) and with "acpi_backlight=vendor" specified I may confirm that in Gnome environment (it's 3.10) backlight controls work properly. Indeed without "acpi_backlight=vendor" (which is a default situation) Gnome shows brightness change animation and "/sys/class/backlight/acpi_video0/brightness" changes properly, but real screen brightness doesn't change. Here's my kernel version information: ========== Linux localhost 3.11.6-300.fc20.x86_64 #1 SMP Fri Oct 18 22:31:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ========== Boot command-line (from beginning of dmesg output) is: ========== Command line: initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 acpi_backlight=vendor BOOT_IMAGE=vmlinuz0 ========== So I assume this bug might be closed now as resolved. Let me know if there's a need for some more information/testing. |