Bug 60659 - Backlight control interface with nouveau driver for nVidia Quadro 1000m not works
Summary: Backlight control interface with nouveau driver for nVidia Quadro 1000m not w...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-31 06:34 UTC by Charles-Antoine Couret
Modified: 2013-10-29 08:49 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.11-rc3 and oldier
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Charles-Antoine Couret 2013-07-31 06:34:39 UTC
Hello, I created the bug #60654 (https://bugzilla.kernel.org/show_bug.cgi?id=60654) in subject of backlight control not works with my laptop. But the problem is complex and I receive an advice to create another bug here to solve this problem.

I have a laptop HP Elitebook 8560w with a nVidia video card and the nouveau driver. In fact the backlight control by keyboard was recognized (a GNOME's pop-up appeared) but no effect on the backlight.

Use xbacklight or write in /sys/class/backlight/XXXX/ files did nothing.

Do you need more informpation about that ? 
Thank you in advance.
Comment 1 Ilia Mirkin 2013-07-31 07:04:23 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.
Comment 2 Charles-Antoine Couret 2013-07-31 15:54:40 UTC
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…
Comment 3 Ilia Mirkin 2013-07-31 16:01:14 UTC
OK, but does the provided driver effectively control backlight? (i.e. writing into /sys/class/backlight/...)
Comment 4 Charles-Antoine Couret 2013-07-31 16:13:38 UTC
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. ;)
Comment 5 Ilia Mirkin 2013-07-31 16:40:39 UTC
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.]
Comment 6 Charles-Antoine Couret 2013-07-31 20:56:50 UTC
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…
Comment 7 Ilia Mirkin 2013-07-31 21:00:00 UTC
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.
Comment 8 Aaron Lu 2013-08-06 08:41:04 UTC
(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.
Comment 9 Alexey Brodkin 2013-10-29 08:49:00 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.