Bug 1123661 - Backlight doesn't turn off anymore as of kernel 3.16 (Dell XPS 17/GeForce GT 555M)
Backlight doesn't turn off anymore as of kernel 3.16 (Dell XPS 17/GeForce GT ...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-27 16:27 EDT by Erik van Pienbroek
Modified: 2017-08-08 07:47 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 07:47:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg 3.15.10-201.fc20.x86_64 kernel (85.66 KB, text/plain)
2014-10-03 18:21 EDT, Erik van Pienbroek
no flags Details
dmesg 3.17.0-0.rc7.git3.1.fc22.x86_64 kernel (83.94 KB, text/plain)
2014-10-03 18:21 EDT, Erik van Pienbroek
no flags Details
Patch which resolves the issue (980 bytes, patch)
2015-03-08 10:12 EDT, Erik van Pienbroek
no flags Details | Diff
Logs belonging to comment 46 (3.96 MB, text/plain)
2016-11-21 13:18 EST, Erik van Pienbroek
no flags Details

  None (edit)
Description Erik van Pienbroek 2014-07-27 16:27:29 EDT
Starting with the early 3.16 kernel snapshots (which appeared mid-June) backlight control seems to have regressed on my Dell XPS 17 notebook which contains an GeForce GT 555M. On these 3.16 kernels the backlight on my internal notebook display doesn't turn off any more when my GNOME session is locked.

If I boot with the 3.15.0-1.fc21.x86_64 kernel then backlight control works fine and the display turns off properly when my GNOME session is locked.

The latest 3.16 kernel I tried is kernel-3.16.0-0.rc6.git0.1.fc21.1 (built July 22) but backlight control is still broken with it so I'm sticking with the 3.15 kernel for now.
Comment 1 Erik van Pienbroek 2014-08-22 19:10:36 EDT
Issue still exists with both kernel-3.16.1-300.fc21 and kernel-3.17.0-0.rc1.git0.1.fc22
Comment 2 Erik van Pienbroek 2014-09-28 16:46:34 EDT
Backlight control on my notebook's internal display is still broken with 3.17.0-0.rc6.git0.1.fc22.x86_64
Comment 3 Hans de Goede 2014-10-01 08:04:25 EDT
Hi Erik,

Can you please walk through the debugging instructions here:

http://hansdegoede.livejournal.com/13889.html

And provide all the data requested there here ?

Thanks,

Hans
Comment 4 Erik van Pienbroek 2014-10-03 18:20:23 EDT
Hi Hans,

Here are the observations which I've done based on your blog posting.

All tests were done against kernel 3.15.10-201.fc20.x86_64 and 3.17.0-0.rc7.git3.1.fc22.x86_64 with no external displays attached to this notebook.

The dmi command mentioned on the blogs returns for both kernels exactly the same output:

/sys/class/dmi/id/bios_date:09/07/2012
/sys/class/dmi/id/bios_vendor:Dell Inc.         
/sys/class/dmi/id/bios_version:A19
/sys/class/dmi/id/board_asset_tag:Base Board Asset Tag
/sys/class/dmi/id/board_name:03RG89
/sys/class/dmi/id/board_serial:.CW8ZQS1.CN4864322G0038.
/sys/class/dmi/id/board_vendor:Dell Inc.         
/sys/class/dmi/id/board_version:FAB1
/sys/class/dmi/id/chassis_asset_tag:        
/sys/class/dmi/id/chassis_serial:CW8ZQS1
/sys/class/dmi/id/chassis_type:8
/sys/class/dmi/id/chassis_vendor:Dell Inc.         
/sys/class/dmi/id/chassis_version:0.1
/sys/class/dmi/id/product_name:Dell System XPS L702X
/sys/class/dmi/id/product_serial:CW8ZQS1
/sys/class/dmi/id/product_uuid:44454C4C-5700-1038-805A-C3C04F515331
/sys/class/dmi/id/product_version:
/sys/class/dmi/id/sys_vendor:Dell Inc.  

The dmesg for both kernels is attached to this bug report


On kernel 3.15.10-201.fc20.x86_64:
----------------------------------

* The brightness keys don't work
* The tool evemu-record doesn't detect brightness keys (tried "AT Translated Set 2 keyboard", "Video Bus" and "Dell WMI hotkeys")
* When locking screen from GNOME the backlight turns off normally

[root@erik-laptop ~]# ls -la /sys/class/backlight
totaal 0
drwxr-xr-x.  2 root root 0  3 okt 23:39 .
drwxr-xr-x. 47 root root 0  3 okt 23:39 ..
lrwxrwxrwx.  1 root root 0  3 okt 23:39 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
lrwxrwxrwx.  1 root root 0  3 okt 23:39 nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/nv_backlight


[root@erik-laptop ~]# cd /sys/class/backlight/acpi_video0/
[root@erik-laptop acpi_video0]# ls -al
totaal 0
drwxr-xr-x. 3 root root    0  3 okt 23:55 .
drwxr-xr-x. 3 root root    0  3 okt 23:55 ..
-r--r--r--. 1 root root 4096  3 okt 23:56 actual_brightness
-rw-r--r--. 1 root root 4096  3 okt 23:56 bl_power
-rw-r--r--. 1 root root 4096  3 okt 23:55 brightness
lrwxrwxrwx. 1 root root    0  3 okt 23:56 device -> ../../../0000:01:00.0
-r--r--r--. 1 root root 4096  3 okt 23:55 max_brightness
drwxr-xr-x. 2 root root    0  3 okt 23:56 power
lrwxrwxrwx. 1 root root    0  3 okt 23:55 subsystem -> ../../../../../../class/backlight
-r--r--r--. 1 root root 4096  3 okt 23:55 type
-rw-r--r--. 1 root root 4096  3 okt 23:55 uevent
[root@erik-laptop acpi_video0]# cat actual_brightness 
1
[root@erik-laptop acpi_video0]# cat bl_power 
0
[root@erik-laptop acpi_video0]# cat brightness 
1
[root@erik-laptop acpi_video0]# cat max_brightness 
15


[root@erik-laptop acpi_video0]# cd /sys/class/backlight/nv_backlight/
[root@erik-laptop nv_backlight]# ls -la
totaal 0
drwxr-xr-x. 3 root root    0  3 okt 23:55 .
drwxr-xr-x. 4 root root    0  3 okt 23:55 ..
-r--r--r--. 1 root root 4096  3 okt 23:56 actual_brightness
-rw-r--r--. 1 root root 4096  3 okt 23:56 bl_power
-rw-r--r--. 1 root root 4096  3 okt 23:55 brightness
lrwxrwxrwx. 1 root root    0  3 okt 23:56 device -> ../../card0-eDP-1
-r--r--r--. 1 root root 4096  3 okt 23:55 max_brightness
drwxr-xr-x. 2 root root    0  3 okt 23:56 power
lrwxrwxrwx. 1 root root    0  3 okt 23:55 subsystem -> ../../../../../../../../class/backlight
-r--r--r--. 1 root root 4096  3 okt 23:55 type
-rw-r--r--. 1 root root 4096  3 okt 23:55 uevent
[root@erik-laptop nv_backlight]# cat actual_brightness 
72
[root@erik-laptop nv_backlight]# cat bl_power 
0
[root@erik-laptop nv_backlight]# cat brightness 
72
[root@erik-laptop nv_backlight]# cat max_brightness 
100


echo 1 > /sys/class/backlight/acpi_video0/bl_power -- no effect
echo 10 > /sys/class/backlight/acpi_video0/brightness -- no effect
echo 1 > /sys/class/backlight/nv_backlight/bl_power -- no effect
echo 20 > /sys/class/backlight/nv_backlight/brightness -- brightness is reduced (expected behaviour)
echo 0 > /sys/class/backlight/nv_backlight/brightness -- backlight gets fully turned off


========================================================================


On kernel 3.17.0-0.rc7.git3.1.fc22.x86_64:
------------------------------------------

* The brightness keys don't work
* The tool evemu-record doesn't detect brightness keys (tried "AT Translated Set 2 keyboard", "Video Bus" and "Dell WMI hotkeys")
* When locking screen from GNOME the brightness gets reduced to zero, but the backlight still remains on

[root@erik-laptop ~]# ls -la /sys/class/backlight
totaal 0
drwxr-xr-x.  2 root root 0  4 okt 00:05 .
drwxr-xr-x. 49 root root 0  4 okt 00:02 ..
lrwxrwxrwx.  1 root root 0  4 okt 00:02 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
lrwxrwxrwx.  1 root root 0  4 okt 00:02 nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/nv_backlight

[root@erik-laptop ~]# cd /sys/class/backlight/acpi_video0/
[root@erik-laptop acpi_video0]# ls -la
totaal 0
drwxr-xr-x. 3 root root    0  4 okt 00:02 .
drwxr-xr-x. 3 root root    0  4 okt 00:02 ..
-r--r--r--. 1 root root 4096  4 okt 00:05 actual_brightness
-rw-r--r--. 1 root root 4096  4 okt 00:05 bl_power
-rw-r--r--. 1 root root 4096  4 okt 00:02 brightness
lrwxrwxrwx. 1 root root    0  4 okt 00:05 device -> ../../../0000:01:00.0
-r--r--r--. 1 root root 4096  4 okt 00:02 max_brightness
drwxr-xr-x. 2 root root    0  4 okt 00:05 power
lrwxrwxrwx. 1 root root    0  4 okt 00:02 subsystem -> ../../../../../../class/backlight
-r--r--r--. 1 root root 4096  4 okt 00:02 type
-rw-r--r--. 1 root root 4096  4 okt 00:02 uevent
[root@erik-laptop acpi_video0]# cat actual_brightness 
1
[root@erik-laptop acpi_video0]# cat bl_power 
0
[root@erik-laptop acpi_video0]# cat brightness 
1
[root@erik-laptop acpi_video0]# cat max_brightness 
15


[root@erik-laptop acpi_video0]# cd /sys/class/backlight/nv_backlight/
[root@erik-laptop nv_backlight]# ls -al
totaal 0
drwxr-xr-x. 3 root root    0  4 okt 00:02 .
drwxr-xr-x. 4 root root    0  4 okt 00:02 ..
-r--r--r--. 1 root root 4096  4 okt 00:06 actual_brightness
-rw-r--r--. 1 root root 4096  4 okt 00:06 bl_power
-rw-r--r--. 1 root root 4096  4 okt 00:02 brightness
lrwxrwxrwx. 1 root root    0  4 okt 00:06 device -> ../../card0-eDP-1
-r--r--r--. 1 root root 4096  4 okt 00:02 max_brightness
drwxr-xr-x. 2 root root    0  4 okt 00:06 power
lrwxrwxrwx. 1 root root    0  4 okt 00:02 subsystem -> ../../../../../../../../class/backlight
-r--r--r--. 1 root root 4096  4 okt 00:02 type
-rw-r--r--. 1 root root 4096  4 okt 00:02 uevent
[root@erik-laptop nv_backlight]# cat actual_brightness 
72
[root@erik-laptop nv_backlight]# cat bl_power 
0
[root@erik-laptop nv_backlight]# cat brightness 
72
[root@erik-laptop nv_backlight]# cat max_brightness 
100

echo 1 > /sys/class/backlight/acpi_video0/bl_power -- no effect
echo 10 > /sys/class/backlight/acpi_video0/brightness -- no effect
echo 1 > /sys/class/backlight/nv_backlight/bl_power -- no effect
echo 20 > /sys/class/backlight/nv_backlight/brightness -- brightness is reduced (expected behaviour)
echo 0 > /sys/class/backlight/nv_backlight/brightness -- backlight gets fully turned off
Comment 5 Erik van Pienbroek 2014-10-03 18:21:23 EDT
Created attachment 943809 [details]
dmesg 3.15.10-201.fc20.x86_64 kernel
Comment 6 Erik van Pienbroek 2014-10-03 18:21:52 EDT
Created attachment 943810 [details]
dmesg 3.17.0-0.rc7.git3.1.fc22.x86_64 kernel
Comment 7 Hans de Goede 2014-10-04 05:07:49 EDT
Erik,

Can you try adding "acpi_backlight=vendor" to the kernel commandline, with 3,17 and then:

1) Provide ls /sys/class/backlight output
2) See if the screen now properly turns off when you lock
3) re-run evemu-record and see if the brightness keys now generate events

Thanks,

Hans
Comment 8 Erik van Pienbroek 2014-10-04 07:12:51 EDT
Hi Hans,

With acpi_backlight=vendor on 3.17 the only thing that changes is the name of the /sys/class/backlight/acpi_video0 folder. With acpi_backlight=vendor this folder is now called /sys/class/backlight/dell_backlight. Other than that the behaviour is exactly the same as without this kernel boot option:

On kernel 3.17.0-0.rc7.git3.1.fc22.x86_64 with acpi_backlight=vendor:
---------------------------------------------------------------------

* The brightness keys don't work
* The tool evemu-record doesn't detect brightness keys (tried "AT Translated Set 2 keyboard", "Video Bus" and "Dell WMI hotkeys")
* When locking screen from GNOME the brightness gets reduced to zero, but the backlight still remains on

[root@erik-laptop ~]# ls -la /sys/class/backlight
totaal 0
drwxr-xr-x.  2 root root 0  4 okt 12:55 .
drwxr-xr-x. 49 root root 0  4 okt 12:55 ..
lrwxrwxrwx.  1 root root 0  4 okt 12:51 dell_backlight -> ../../devices/platform/dell-laptop/backlight/dell_backlight
lrwxrwxrwx.  1 root root 0  4 okt 12:51 nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/nv_backlight
[root@erik-laptop ~]# cd /sys/class/backlight/dell_backlight
[root@erik-laptop dell_backlight]# ls -la
totaal 0
drwxr-xr-x. 3 root root    0  4 okt 12:51 .
drwxr-xr-x. 3 root root    0  4 okt 12:51 ..
-r--r--r--. 1 root root 4096  4 okt 12:56 actual_brightness
-rw-r--r--. 1 root root 4096  4 okt 12:56 bl_power
-rw-r--r--. 1 root root 4096  4 okt 12:51 brightness
lrwxrwxrwx. 1 root root    0  4 okt 12:56 device -> ../../../dell-laptop
-r--r--r--. 1 root root 4096  4 okt 12:51 max_brightness
drwxr-xr-x. 2 root root    0  4 okt 12:56 power
lrwxrwxrwx. 1 root root    0  4 okt 12:51 subsystem -> ../../../../../class/backlight
-r--r--r--. 1 root root 4096  4 okt 12:51 type
-rw-r--r--. 1 root root 4096  4 okt 12:51 uevent
[root@erik-laptop dell_backlight]# cat actual_brightness 
14
[root@erik-laptop dell_backlight]# cat bl_power 
0
[root@erik-laptop dell_backlight]# cat brightness 
14
[root@erik-laptop dell_backlight]# cat max_brightness 
15

[root@erik-laptop acpi_video0]# cd /sys/class/backlight/nv_backlight/
[root@erik-laptop nv_backlight]# ls -a
totaal 0
drwxr-xr-x. 3 root root    0  4 okt 12:51 .
drwxr-xr-x. 4 root root    0  4 okt 12:51 ..
-r--r--r--. 1 root root 4096  4 okt 12:59 actual_brightness
-rw-r--r--. 1 root root 4096  4 okt 12:59 bl_power
-rw-r--r--. 1 root root 4096  4 okt 12:51 brightness
lrwxrwxrwx. 1 root root    0  4 okt 12:59 device -> ../../card0-eDP-1
-r--r--r--. 1 root root 4096  4 okt 12:51 max_brightness
drwxr-xr-x. 2 root root    0  4 okt 12:59 power
lrwxrwxrwx. 1 root root    0  4 okt 12:51 subsystem -> ../../../../../../../../class/backlight
-r--r--r--. 1 root root 4096  4 okt 12:51 type
-rw-r--r--. 1 root root 4096  4 okt 12:51 uevent

[root@erik-laptop nv_backlight]# cat actual_brightness 
72
[root@erik-laptop nv_backlight]# cat bl_power 
0
[root@erik-laptop nv_backlight]# cat brightness 
72
[root@erik-laptop nv_backlight]# cat max_brightness 
100

echo 1 > /sys/class/backlight/dell_backlight/bl_power -- no effect
echo 10 > /sys/class/backlight/dell_backlight/brightness -- no effect
echo 1 > /sys/class/backlight/nv_backlight/bl_power -- no effect
echo 20 > /sys/class/backlight/nv_backlight/brightness -- brightness is reduced (expected behaviour)
echo 0 > /sys/class/backlight/nv_backlight/brightness -- backlight gets fully turned off
Comment 9 Hans de Goede 2014-10-11 09:37:58 EDT
Hi,

I've started a scratchbuild with a kernel with a quirk for your model, you can find this scratch build here:

 http://koji.fedoraproject.org/koji/taskinfo?taskID=7832541

Note this is still building atm.

The added quirk tell the kernel to always use the native (nv_backlight) interface on your machine.

Can you please download the kernel-3.16.5-....x86_64.rpm file, and then install it with:
sudo rpm -ivh kernel-3.16.5-....x86_64.rpm

And boot into it without specifying any special kernel commandline parameters.

After booting this kernel please do:

ls /sys/class/backlight

It should now only list nv_backlight, after that please check if the bug is gone now, and report back here.

Also please try to see if this somehow magically fixes your brightness up/down keys not working.

Thanks,

Hans
Comment 10 Hans de Goede 2014-10-12 06:36:55 EDT
Ugh, that scratchbuild has failed because the release field was too long, here is a new build I've just started:

https://koji.fedoraproject.org/koji/taskinfo?taskID=7839906

Please follow the previous testing instructions using this build (once it has finished building).
Comment 11 Erik van Pienbroek 2014-10-12 10:09:10 EDT
Hi Hans,

Your scratch kernel doesn't seem to give any improvement. In /sys/class/backlight there still are 2 subfolders, acpi_video0 and nv_backlight. The observations with this kernel are the same as I mentioned earlier with the 3.17 kernel (without using any additional kernel boot options).
Comment 12 Hans de Goede 2014-10-12 10:16:40 EDT
(In reply to Erik van Pienbroek from comment #11)
> Hi Hans,
> 
> Your scratch kernel doesn't seem to give any improvement. In
> /sys/class/backlight there still are 2 subfolders, acpi_video0 and
> nv_backlight. The observations with this kernel are the same as I mentioned
> earlier with the 3.17 kernel (without using any additional kernel boot
> options).

Ah, double checking my code I see why. Can you boot that kernel with acpi_backlight=vendor please, that should work around the bug in my code and only give you nv_backlight without needing to do a new scratchbuild.

Thanks,

Hans
Comment 13 Erik van Pienbroek 2014-10-12 11:25:46 EDT
Okay, with your kernel and 'acpi_backlight=vendor' there's now only one folder: /sys/class/backlight/nv_backlight. The gnome-shell widget for controlling the backlight now also works.

The keys for controlling the backlight on my keyboard still don't work. evemu-record also doesn't register anything although the other function keys like 'disable internal touchpad' and the volume keys are working fine (I can see their low level identifiers in evemu-record). Perhaps something in the kernel is filtering the backlight keys? I could try some more older kernels (pre 3.15) to see if it has worked in the past (with nouveau enabled).

The original issue mentioned in this bug report still stands: the backlight still doesn't fully turn off when the GNOME session is locked.
Comment 14 Hans de Goede 2014-10-16 09:25:58 EDT
(In reply to Erik van Pienbroek from comment #13)
> Okay, with your kernel and 'acpi_backlight=vendor' there's now only one
> folder: /sys/class/backlight/nv_backlight. The gnome-shell widget for
> controlling the backlight now also works.

Ok, so the gnome widget working is an improvement over the 3.15 situation, right ?

> The keys for controlling the backlight on my keyboard still don't work.
> evemu-record also doesn't register anything although the other function keys
> like 'disable internal touchpad' and the volume keys are working fine (I can
> see their low level identifiers in evemu-record). Perhaps something in the
> kernel is filtering the backlight keys? I could try some more older kernels
> (pre 3.15) to see if it has worked in the past (with nouveau enabled).

Ok, so the keys issue is going to need some more debugging. Can you add:

atkbd.softraw=0

To your kernel commandline, then boot and login as root to a text console
(ctrl + alt +f2) and then run:

showkey -s

And then see if anything shows up when you press the brightness key combos ?

If something shows up, please report exactly what shows up here.\

> The original issue mentioned in this bug report still stands: the backlight
> still doesn't fully turn off when the GNOME session is locked.

Bummer, so this seems to be a nouveau issue, which Ben will have to help you with further. One last thing which you could do, which will be a tremendous help, but also is a lot of work, is to git bisect the problem and then let us know which commit exactly has caused the problem.
Comment 15 Erik van Pienbroek 2014-10-16 11:55:34 EDT
(In reply to Hans de Goede from comment #14)
> (In reply to Erik van Pienbroek from comment #13)
> > Okay, with your kernel and 'acpi_backlight=vendor' there's now only one
> > folder: /sys/class/backlight/nv_backlight. The gnome-shell widget for
> > controlling the backlight now also works.
> 
> Ok, so the gnome widget working is an improvement over the 3.15 situation,
> right ?

Correct, the quirk gives an improvement in the gnome-shell brightness control

> > The keys for controlling the backlight on my keyboard still don't work.
> > evemu-record also doesn't register anything although the other function keys
> > like 'disable internal touchpad' and the volume keys are working fine (I can
> > see their low level identifiers in evemu-record). Perhaps something in the
> > kernel is filtering the backlight keys? I could try some more older kernels
> > (pre 3.15) to see if it has worked in the past (with nouveau enabled).
> 
> Ok, so the keys issue is going to need some more debugging. Can you add:
> 
> atkbd.softraw=0
> 
> To your kernel commandline, then boot and login as root to a text console
> (ctrl + alt +f2) and then run:
> 
> showkey -s
> 
> And then see if anything shows up when you press the brightness key combos ?
> 
> If something shows up, please report exactly what shows up here.\

Sure, will do. I'll let you know

> > The original issue mentioned in this bug report still stands: the backlight
> > still doesn't fully turn off when the GNOME session is locked.
> 
> Bummer, so this seems to be a nouveau issue, which Ben will have to help you
> with further. One last thing which you could do, which will be a tremendous
> help, but also is a lot of work, is to git bisect the problem and then let
> us know which commit exactly has caused the problem.

If I remember correctly the regression was first observed in kernel-3.16.0-0.rc0.git1.1.fc21 and the last working kernel before that was kernel-3.15.0-1.fc21. I'm familiar with git bisecting, but bisecting the kernel itself will take an awful lot of time to do so I'll try to check the kernel git logs first for potential candidates
Comment 16 Erik van Pienbroek 2014-10-16 16:23:56 EDT
(In reply to Hans de Goede from comment #14)
> Ok, so the keys issue is going to need some more debugging. Can you add:

Unfortunately the 'showkey -s' command doesn't show anything and other FN-keys work fine... I'll try some older kernels to be able to confirm whether it has worked fine in the past with nouveau
Comment 17 Erik van Pienbroek 2014-10-16 16:29:04 EDT
I did some more testing and the 'backlight not powering off' regression seems to be introduced between kernel git tags v3.15-8981-g5c02c392cd23 (3.16.0-0.rc0.git9.1) and v3.15-9837-g682b7c1c8ea8 (3.16.0-0.rc0.git10.1). A quick look at the git log between these two tags indicates that a large amount of changes from drm-next were pulled in. In these drm-next changes there are more than 60 nouveau related commits, most of which are from Ben. Here's a rough list:

[erik@erik linux-stable(git::master)]$ git log --pretty=format:"%h %an %s" v3.15-8981-g5c02c392cd23..v3.15-9837-g682b7c1c8ea8 | grep -e nouveau -e drm/nv
bc1dfff Dave Airlie Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
1ae5a62 Ben Skeggs drm/nouveau/disp/dp: fix tmds passthrough on dp connector
8777c5c Ben Skeggs drm/nouveau/dp: probe dpcd to determine connectedness
efa366f Ben Skeggs drm/nv50-: trigger update after all connectors disabled
e84a35a Ben Skeggs drm/nv50-: prepare for attaching a SOR to multiple heads
c33ba68 Ben Skeggs drm/nouveau/disp/dp: make use of postcursor when its available
7a14bc7 Ben Skeggs drm/nouveau/bios/dp: parse lane postcursor data
4874322 Ben Skeggs drm/nouveau/dp: fix support for dpms
8894f49 Ben Skeggs drm/nouveau: register a drm_dp_aux channel for each dp connector
55f083c Ben Skeggs drm/nouveau/disp/dp: maintain link in response to hpd signal
1ecee1c Ben Skeggs drm/nouveau/disp/dp: split link config/power into two steps
b17932c Ben Skeggs drm/nv50/disp: train PIOR-attached DP from second supervisor
3b52a1f Ben Skeggs drm/nouveau/disp/dp: make use of existing output data for link training
415f12e Ben Skeggs drm/nv50/disp: start removing direct vbios parsing from supervisor
bb7ef1e Ben Skeggs drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal
b8407c9 Ben Skeggs drm/nouveau/disp/dp: create subclass for dp outputs
456b057 Ben Skeggs drm/nouveau: use connector events for HPD instead of GPIO watching
7a014a8 Ben Skeggs drm/nouveau/disp: add internal representaion of output paths and connectors
20014cb Ben Skeggs drm/nouveau/bios: extend connector table parsing
377b1f1 Ben Skeggs drm/nouveau/disp: nothing to see here
37da5b8 Ben Skeggs drm/nouveau/i2c/anx9805: add debugging to aux transactions
9efc583 Ben Skeggs drm/nouveau/i2c: introduce locking at a per-port level
d2ae2eb Ben Skeggs drm/nouveau/i2c: balance port acquire/release
3668a33 Ben Skeggs drm/nouveau/i2c: add interfaces to support handling aux channel interrupts
c26fe84 Ben Skeggs drm/nouveau/i2c: start hiding subdev-internal interfaces
0bac987 Ben Skeggs drm/nouveau/i2c: remove unnecessary i2c_set_adapdata()
842c295 Ben Skeggs drm/nouveau/i2c: properly hand aux reply back to caller, and only retry on defer
febb844 Ben Skeggs drm/nv50-/mc: also pass PMGR interrupts onto I2C subdev
20a8007 Ben Skeggs drm/nouveau/gpio: send separate event types for high/low transitions
bc3b0c4 Ben Skeggs drm/nouveau/gpio: use base constructor for all implementations
f4277a0 Ben Skeggs drm/nouveau/gpio: move on-reset intr disable-and-ack to common code
5693c0f Ben Skeggs drm/nouveau/gpio: split "toggled" interrupt into "went high" / "went low"
7356859 Ben Skeggs drm/nouveau/gpio: split g92 class from nv50
d93174e Ben Skeggs drm/nouveau/gpio: use indirect pointer to base class definition
1f86ca1 Ben Skeggs drm/nouveau/disp/dp: support training to highest rate, rather than a target
04e7e92 Ben Skeggs drm/nouveau/disp/dp: support postcursor in link training
8e8832e Ben Skeggs drm/nouveau/core: allow event source to handle multiple event types per index
b06c47a Dave Airlie Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
af4870e Mario Kleiner drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
dcfb100 Mario Kleiner drm/nv50-/mc: fix kms pageflip events by reordering irq handling order.
e291af3 Mario Kleiner drm/nouveau/disp/nv04-nv40: abort scanoutpos query on vga analog.
56d237d Ben Skeggs drm/nv50-/kms: wait for enough ring space in crtc_prepare()
6e8e268 Ben Skeggs drm/nouveau/disp/dp: support training pattern 3
fb7c2a7 Ben Skeggs drm/nouveau/disp/dp: support aux read interval during link training
964f85e Ben Skeggs drm/nouveau/core: punt all object state change messages to trace level
ed05ba7 Ilia Mirkin drm/nouveau/clk: allow end-user reclocking for nv40, nvaa, and nve0 clock types
d2ed15b Ilia Mirkin drm/nouveau/fb: default NvMemExec to on, turning it off is used for debugging only
29ba8c8 Martin Peres drm/nouveau/bios: fix a potential NULL deref in the PROM shadowing function
9044fa6 Martin Peres drm/nouveau/i2c: bump the i2c delay for the adt7473
30af6aa Martin Peres drm/nouveau/therm/fan/tach: default to 2 pulses per revolution
5edcf1c John Rowley drm/nvf0/device: enable video decoding engines on gk110/gk208
9abdbab John Rowley drm/nvf1/device: add support for 0xf1 (gk110b)
52e98f1 Alexandre Courbot drm/nouveau/device: support for probing GK20A
a4d4bbf Alexandre Courbot drm/nouveau/graph: add GK20A support
370eec7 Alexandre Courbot drm/nouveau/graph: pad firmware code at load time
b7c852a Alexandre Courbot drm/nouveau/graph: enable when using external fw
86ebef7 Alexandre Courbot drm/nouveau/fifo: add GK20A support
fef94f6 Alexandre Courbot drm/nouveau/fb: add GK20A support
90a5500 Alexandre Courbot drm/nouveau/ibus: add GK20A support
88ff3f5 Alexandre Courbot drm/nvc0/bar: support chips without BAR3
53d206b Alexandre Courbot drm/nouveau/bar: only ioremap BAR3 if it exists
4c0dae5 Damien Lespiau drm/doc: Fix nouveau typo
8c6c361 Jani Nikula drm/nouveau: replace drm_get_connector_name() with direct name field use

I'm not familiar enough with nouveau to be able to tell which one of these commits could be the possible culprit, but perhaps it can help you for further research..
Comment 18 Erik van Pienbroek 2014-11-14 17:00:00 EST
Backlight control is still broken with kernel 3.18.0-0.rc4.git2.1.fc22.x86_64 (which was built today: Nov 14 2014)
Comment 19 André Martins 2014-11-15 22:37:13 EST
Hi,
I'm having the same problem. My laptop isn't a Dell but I have a nvidia card with the nouveau drivers. I've always used the acpi_backlight=vendor flag.

Erik, I don't have any problems with 3.16.7-200.fc20.x86_64. The kernel that is giving me problems for me is 3.17.2-200.fc20.x86_64.

Let me know if I can help with anything.
Thanks
Comment 20 André Martins 2014-11-21 10:18:18 EST
Hello,
for me, the problem is solved in 3.17.3-200.fc20.x86_64.
Thank you
Comment 21 Erik van Pienbroek 2014-11-21 12:22:19 EST
I just tested with kernel 3.17.3-301.fc21.x86_64 (built Wednesday November 19) but for me the issue still remains with that kernel.

@Hans: Is the quirk which you prepared some time ago already upstreamed in the Fedora kernel? Without any additional boot parameters there still are 2 folders in /sys/class/backlight when using kernel 3.17.3-301.fc21.x86_64
Comment 22 Hans de Goede 2014-11-21 14:18:18 EST
(In reply to Erik van Pienbroek from comment #21)
> I just tested with kernel 3.17.3-301.fc21.x86_64 (built Wednesday November
> 19) but for me the issue still remains with that kernel.
> 
> @Hans: Is the quirk which you prepared some time ago already upstreamed in
> the Fedora kernel? Without any additional boot parameters there still are 2
> folders in /sys/class/backlight when using kernel 3.17.3-301.fc21.x86_64

No, I've not send that patch upstream, since it only fixes half the issue, so it might very well be wrong.
Comment 23 Erik van Pienbroek 2014-11-21 15:41:02 EST
Okay thanks, I'll wait for Ben to continue research on this issue
Comment 24 Erik van Pienbroek 2015-01-04 17:05:14 EST
This issue is still valid with kernel 3.18.1-2 (which was built Thursday December 18 2014)
Comment 25 Justin M. Forbes 2015-01-27 10:02:24 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.18.3-201.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 26 Erik van Pienbroek 2015-01-27 12:01:28 EST
See last comment, issue still exists with recent rawhide kernels
Comment 27 Jaroslav Reznik 2015-03-03 11:09:44 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 28 Erik van Pienbroek 2015-03-07 20:08:59 EST
I just tried to 'git bisect' the kernel to find out what exact commit introduced the regression.

The first bisect attempt pointed to the range 04e7e92..7a14bc7 (which consists of about 34 commits). This is such a large range because I had to skip a large amount of commits due to nouveau not being able to properly initialize with the various commits in this range (blank screen and INVALID_STATE errors).

Once I had this range I decided to re-arrange some commits to see if I could reduce this range even more. This turned out to give the desired outcome and pointed to the following commit as being the culprit for the backlight regression I'm having (and which still does exist in the latest 4.0.0-rc2 kernel):

commit 8894f4919bc43f821775db2cfff4b917871b2102
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri May 30 16:20:58 2014 +1000

    drm/nouveau: register a drm_dp_aux channel for each dp connector
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


Does this provide enough information to continue research?
Comment 29 Erik van Pienbroek 2015-03-08 10:11:30 EDT
After more debugging I think the following commit is the real culprit:

commit 4874322e78d505d38c8d4481118af5c9f0e8306d
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Sat May 31 01:48:06 2014 +1000

    drm/nouveau/dp: fix support for dpms
    
    SOR_PWR has no effect to power-off DP links, unlike other SOR protocols.
    
    Instead, on the source side, we cut power to the lanes after having put
    the sink into D3.  Link training takes care of everything required to
    bring it back again.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


I just did some more research against the latest kernel git and found out that it seems that all calls to nv50_sor_dpms try to turn ON a DisplayPort based display even when this function is called with mode=0. This is due to a hardcoded "args.pwr.state = 1;". I don't know why this is hardcoded (perhaps some debugging remains?) but I just tried removing this line and now the backlight can be turned OFF again when using the latest 4.0 kernel!

I just uploaded a patch which resolves the issue for me. I'll do some more testing later today to make sure external DisplayPort based displays also remain working properly with this change. Feel free to merge this in the kernel git.
Comment 30 Erik van Pienbroek 2015-03-08 10:12:31 EDT
Created attachment 999342 [details]
Patch which resolves the issue
Comment 31 Erik van Pienbroek 2015-03-08 17:55:34 EDT
I just did some more testing with the scratch kernel build @ https://koji.fedoraproject.org/koji/taskinfo?taskID=9172516 and both the internal display and an externally connected monitor using DisplayPort work fine now. When I execute the command 'xset dpms force off' both the internal display and the external display go blank and the backlight of the internal display gets turned off.

I do see a nouveau INVALID_STATE state message in my dmesg but given the fact that it happens quite early during boot and I've also seen it in earlier testing (without my patch) I suspect that to be a separate unrelated issue:
[   28.901239] nouveau E[   PDISP][0000:01:00.0] INVALID_STATE [UNK05] chid 0 mthd 0x0080 data 0x00000000
Comment 32 Erik van Pienbroek 2015-05-06 17:40:15 EDT
Upstream bug filed @ https://bugs.freedesktop.org/show_bug.cgi?id=90351
Comment 33 Justin M. Forbes 2015-10-20 15:45:29 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.
Comment 34 Erik van Pienbroek 2015-11-01 17:19:15 EST
This bug still exists with kernel 4.3.0-0.rc7.git0.1.fc24.x86_64

I can also confirm that the patch mentioned earlier in this bz can still be applied on top of kernel 4.3 and makes turning off the backlight on my internal display work again (but powering off externally connected DP displays doesn't work properly any more with the patch applied)

Is there anything I can do to help in resolving/further diagnosing this issue?
Comment 35 Fedora End Of Life 2016-07-19 07:58:38 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 36 Erik van Pienbroek 2016-07-19 08:33:36 EDT
Issue still exists with kernel 4.7.0-0.rc7.git4.1.fc25

Re-opening and re-assigning to xorg-x11-drv-nouveau conform https://fedoraproject.org/wiki/KernelBugTriage#Video_Subsystem_bugs
Comment 37 Hans de Goede 2016-08-26 05:28:03 EDT
Hi,

(In reply to Erik van Pienbroek from comment #36)
> Issue still exists with kernel 4.7.0-0.rc7.git4.1.fc25
> 
> Re-opening and re-assigning to xorg-x11-drv-nouveau conform
> https://fedoraproject.org/wiki/KernelBugTriage#Video_Subsystem_bugs

Thanks for the update. This is probably best resolved upstream. There are a number of people who are actively following the upstream bug-tracker now a days.

It is probably best if you rebase your patch to a recent kernel and then attach the updated version to the upstream bug, together with a ping message of some sort, then hopefully someone will take a look and either apply your patch or work with you to find another solution.

Thanks & Regards,

Hans
Comment 38 Erik van Pienbroek 2016-11-16 08:51:52 EST
The issue still exists with recent 4.9 rawhide kernels. However I noticed that some days ago various changes were applied to the nouveau kernel driver which allows it to use atomic modesetting [1]. A look at the changes themselves has shown that the DPMS code was also rewritten because of this so I decided to perform a git checkout of the drm-next tree and do some testing with it.

With the drm-next tree (git rev d8c1abd, 20161111) I can confirm that the DPMS issue I was having where the backlight would not turn off is finally resolved with the atomic modeset changes!

I still need to do more testing with it (like attaching an additional monitor to my notebook) and wait for the drm-next nouveau atomic modeset changes to land in the Fedora kernels, but things look very promising so far.

[1]: http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Atomic-Testing



@Hans de Goede: the second part of this bug which was discussed with you here earlier still exists: controlling the backlight using gnome-shell or the hotkeys are still broken (even with the latest drm-next kernel).

Regarding controlling the backlight using gnome-shell:
The latest drm-next kernel (as mentioned above) and no additional boot options shows two devices in /sys/class/backlight:
acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/nv_backlight
The gnome-shell backlight widget doesn't work with this setup

When I use the boot option 'video.use_native_backlight=1' the effect is the same, two backlight devices in /sys/class/backlight and the gnome-shell backlight widget doesn't have any effect

When I use the boot option 'acpi_backlight=vendor' then there's only 1 backlight device in /sys/class/backlight:
nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/nv_backlight
This allows the gnome-shell backlight widget to work correctly.

Would it be possible to add a quirk to the kernel for this?


Regarding the brightness hotkeys:
Tools like evemu-record (and thus also gnome-shell) still fail to detect the brightness hotkeys (most other hotkeys are registered normally using the input device 'AT Translated Set 2 keyboard'). I discovered that a different key (called 'instant launch control') on my notebook does map to KEY_BRIGHTNESSDOWN. This incorrect behaviour was also described at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1001026

I've also noticed that there is a Dell WMI input device registered. When kernel debugging is enabled for the dell_wmi kernel module (echo "file dell-wmi.c +p" > ${debugfs}/dynamic_debug/control) the keys for 'fn+f2/toggle wireless antenna', 'fn+f6', 'fn+f11/volume down', 'fn+f12/volume up', 'mute volume', 'instant launch control' and 'audio control panel' are successfully detected by the dell_wmi kernel module (although they're not visible in evemu-record when listening on events from the Dell WMI input device), but the brightness keys are not detected by this kernel module.

When I enable debugging for the i8042 kernel module (echo 'Y' > /sys/module/i8042/parameters/debug) then I see kernel messages appearing whenever I press any regular key, but unfortunately pressing the 'brightness up' or 'brightness down' hotkeys ('fn+f4' and 'fn+f5') doesn't result in any kernel messages.

Do you have any other ideas where I can search for the root cause of this issue?


BTW, do you think it would be better to move the discussion about the preferred /sys/class/backlight device and the hotkey detection to a separate bug report and leave this one open until the nouveau atomic modeset changes have arrived in the Fedora kernel? If so, would you like to have one or two separate bugs (the root cause for these issues might be the same)?
Comment 39 Hans de Goede 2016-11-16 09:22:04 EST
(In reply to Erik van Pienbroek from comment #38)
> The issue still exists with recent 4.9 rawhide kernels. However I noticed
> that some days ago various changes were applied to the nouveau kernel driver
> which allows it to use atomic modesetting [1]. A look at the changes
> themselves has shown that the DPMS code was also rewritten because of this
> so I decided to perform a git checkout of the drm-next tree and do some
> testing with it.
> 
> With the drm-next tree (git rev d8c1abd, 20161111) I can confirm that the
> DPMS issue I was having where the backlight would not turn off is finally
> resolved with the atomic modeset changes!
> 
> I still need to do more testing with it (like attaching an additional
> monitor to my notebook) and wait for the drm-next nouveau atomic modeset
> changes to land in the Fedora kernels, but things look very promising so far.

Great that is good news, we plan to backport these changes to the Fedora kernel and we hope to have a copr with a kernel with the backport available for testing soon.

> @Hans de Goede: the second part of this bug which was discussed with you
> here earlier still exists: controlling the backlight using gnome-shell or
> the hotkeys are still broken (even with the latest drm-next kernel).
> 
> Regarding controlling the backlight using gnome-shell:
> The latest drm-next kernel (as mentioned above) and no additional boot
> options shows two devices in /sys/class/backlight:
> acpi_video0 ->
> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
> nv_backlight ->
> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/
> nv_backlight
> The gnome-shell backlight widget doesn't work with this setup
> 
> When I use the boot option 'video.use_native_backlight=1' the effect is the
> same, two backlight devices in /sys/class/backlight and the gnome-shell
> backlight widget doesn't have any effect

video.use_native_backlight=1 is no  longer recognized by the kernel, can you try: acpi_backlight=native instead ?

> 
> When I use the boot option 'acpi_backlight=vendor' then there's only 1
> backlight device in /sys/class/backlight:
> nv_backlight ->
> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/
> nv_backlight
> This allows the gnome-shell backlight widget to work correctly.
> 
> Would it be possible to add a quirk to the kernel for this?

First lets see if video.use_native_backlight=1 works, if it does then that would be the proper quirk to add.

> Regarding the brightness hotkeys:
> Tools like evemu-record (and thus also gnome-shell) still fail to detect the
> brightness hotkeys (most other hotkeys are registered normally using the
> input device 'AT Translated Set 2 keyboard'). I discovered that a different
> key (called 'instant launch control') on my notebook does map to
> KEY_BRIGHTNESSDOWN. This incorrect behaviour was also described at
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1001026
> 
> I've also noticed that there is a Dell WMI input device registered. When
> kernel debugging is enabled for the dell_wmi kernel module (echo "file
> dell-wmi.c +p" > ${debugfs}/dynamic_debug/control) the keys for
> 'fn+f2/toggle wireless antenna', 'fn+f6', 'fn+f11/volume down',
> 'fn+f12/volume up', 'mute volume', 'instant launch control' and 'audio
> control panel' are successfully detected by the dell_wmi kernel module
> (although they're not visible in evemu-record when listening on events from
> the Dell WMI input device), but the brightness keys are not detected by this
> kernel module.
> 
> When I enable debugging for the i8042 kernel module (echo 'Y' >
> /sys/module/i8042/parameters/debug) then I see kernel messages appearing
> whenever I press any regular key, but unfortunately pressing the 'brightness
> up' or 'brightness down' hotkeys ('fn+f4' and 'fn+f5') doesn't result in any
> kernel messages.
> 
> Do you have any other ideas where I can search for the root cause of this
> issue?

I'm afraid not, you've tried all things I can come up with.

> BTW, do you think it would be better to move the discussion about the
> preferred /sys/class/backlight device and the hotkey detection to a separate
> bug report and leave this one open until the nouveau atomic modeset changes
> have arrived in the Fedora kernel? If so, would you like to have one or two
> separate bugs (the root cause for these issues might be the same)?

Lets keep things in this bug for now, we can always open a new bug later.
Comment 40 Erik van Pienbroek 2016-11-16 09:38:13 EST
Thanks for the quick response!

(In reply to Hans de Goede from comment #39)
> (In reply to Erik van Pienbroek from comment #38)
> > When I use the boot option 'video.use_native_backlight=1' the effect is the
> > same, two backlight devices in /sys/class/backlight and the gnome-shell
> > backlight widget doesn't have any effect
> 
> video.use_native_backlight=1 is no  longer recognized by the kernel, can you
> try: acpi_backlight=native instead ?

With 'acpi_backlight=native' the gnome-shell backlight widget works normally and there's only 1 device in /sys/class/backlight:
nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/nv_backlight

So both 'acpi_backlight=native' and 'acpi_backlight=vendor' give the desired effect for the gnome-shell backlight widget.

> > Regarding the brightness hotkeys:
<<snip>>
> > Do you have any other ideas where I can search for the root cause of this
> > issue?
> 
> I'm afraid not, you've tried all things I can come up with.

Okay, that's unfortunate. Could it be an issue with the ACPI implementation in the BIOS? There have been no recent BIOS releases for this notebook lately, but a custom (unofficial) BIOS has showed up which contain various ACPI fixes which are needed to run Mac OS X on this notebook: http://www.insanelymac.com/forum/topic/293246-osx-on-dell-vostro-3450-inspiron-n4110-xps-l702x-uefi-clover/ Perhaps these fixes could benefit the Linux support as well (although I'm a bit sceptical of running an unofficial BIOS..)
Comment 41 Hans de Goede 2016-11-19 06:12:42 EST
Hi,

(In reply to Erik van Pienbroek from comment #40)
> Thanks for the quick response!
> 
> (In reply to Hans de Goede from comment #39)
> > (In reply to Erik van Pienbroek from comment #38)
> > > When I use the boot option 'video.use_native_backlight=1' the effect is the
> > > same, two backlight devices in /sys/class/backlight and the gnome-shell
> > > backlight widget doesn't have any effect
> > 
> > video.use_native_backlight=1 is no  longer recognized by the kernel, can you
> > try: acpi_backlight=native instead ?
> 
> With 'acpi_backlight=native' the gnome-shell backlight widget works normally
> and there's only 1 device in /sys/class/backlight:
> nv_backlight ->
> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-eDP-1/
> nv_backlight
> 
> So both 'acpi_backlight=native' and 'acpi_backlight=vendor' give the desired
> effect for the gnome-shell backlight widget.

Ok, can you please run (in a terminal):

for i in `ls /sys/class/dmi/id/*_* | grep -E -v 'tag|serial|uuid'`; do echo $i >> dmi.log && cat $i >> dmi.log; done

And then attach the generated dmi.log file here, then I'll write a kernel patch to make the kernel automatically apply 'acpi_backlight=native' as quirk on your model laptop.

> > > Regarding the brightness hotkeys:
> <<snip>>
> > > Do you have any other ideas where I can search for the root cause of this
> > > issue?
> > 
> > I'm afraid not, you've tried all things I can come up with.
> 
> Okay, that's unfortunate. Could it be an issue with the ACPI implementation
> in the BIOS? There have been no recent BIOS releases for this notebook
> lately, but a custom (unofficial) BIOS has showed up which contain various
> ACPI fixes which are needed to run Mac OS X on this notebook:
> http://www.insanelymac.com/forum/topic/293246-osx-on-dell-vostro-3450-
> inspiron-n4110-xps-l702x-uefi-clover/ Perhaps these fixes could benefit the
> Linux support as well (although I'm a bit sceptical of running an unofficial
> BIOS..)

I do not think that running a custom BIOS is a good idea; and it is not really a solution, as it will only help, people who flash such a custom BIOS. I'm afraid I still do not have any ideas how to further debug this though. You could try asking for help in a mail send to the platform-driver-x86@vger.kernel.org list.

Regards,

Hans
Comment 42 Erik van Pienbroek 2016-11-19 09:19:21 EST
Here's the contents of the generated dmi.log file:

/sys/class/dmi/id/bios_date
09/07/2012
/sys/class/dmi/id/bios_vendor
Dell Inc.         
/sys/class/dmi/id/bios_version
A19
/sys/class/dmi/id/board_name
03RG89
/sys/class/dmi/id/board_vendor
Dell Inc.         
/sys/class/dmi/id/board_version
FAB1
/sys/class/dmi/id/chassis_type
8
/sys/class/dmi/id/chassis_vendor
Dell Inc.         
/sys/class/dmi/id/chassis_version
0.1
/sys/class/dmi/id/product_name
Dell System XPS L702X
/sys/class/dmi/id/product_version

/sys/class/dmi/id/sys_vendor
Dell Inc.
Comment 43 Erik van Pienbroek 2016-11-20 17:29:07 EST
I just did some more testing (with drm-next rev d8c1abd) using both the internal monitor and an external (mini-DP-to-DP connected) monitor, but I'm afraid there still an issue regarding DPMS poweroff. Here are my findings so far:

With only the internal monitor enabled (no external monitors connected) the backlight turns off normally (when I lock the GNOME session) and stays off

When both the internal monitor and an external monitor are enabled and I try to lock the GNOME session both displays initially turn off normally (including the backlight of the internal monitor), but after about 7 seconds the backlight of both the internal monitor and the external monitor get re-enabled while the image stays black. When I move the mouse cursor or press any key the GNOME unlock screen gets shown.

Here's a timed example:

nov 20 23:18:08 - GNOME session locked and both displays turn off
nov 20 23:18:15 - Backlight of both monitors turns back on
nov 20 23:18:31 - I unlock the GNOME session

The systemd journal contains these messages in that timeframe:

nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop gnome-shell[1395]: Failed to apply DRM plane transform 0: Ongeldig argument
nov 20 23:18:15 erik-laptop gnome-shell[1395]: Failed to apply DRM plane transform 0: Ongeldig argument
nov 20 23:18:15 erik-laptop gnome-shell[1012]: Failed to apply DRM plane transform 0: Toegang geweigerd
nov 20 23:18:15 erik-laptop gnome-shell[1012]: Failed to apply DRM plane transform 0: Toegang geweigerd
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop gnome-shell[1012]: Failed to apply DRM plane transform 0: Toegang geweigerd
nov 20 23:18:15 erik-laptop gnome-shell[1012]: Failed to apply DRM plane transform 0: Toegang geweigerd
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output eDP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output eDP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output eDP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output eDP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop kernel: [drm:drm_edid_block_valid [drm]] *ERROR* EDID has major version 0, instead of 1
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output DP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output DP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop org.gnome.Shell.desktop[1012]: Window manager warning: Failed to read EDID of output DP-1: Bestand of map bestaat niet
nov 20 23:18:15 erik-laptop gnome-shell[1395]: Failed to apply DRM plane transform 0: Ongeldig argument
nov 20 23:18:15 erik-laptop gnome-shell[1395]: Failed to apply DRM plane transform 0: Ongeldig argument
nov 20 23:18:15 erik-laptop kernel: snd_hda_codec_hdmi hdaudioC1D3: HDMI: audio coding type 0 not expected
nov 20 23:18:31 erik-laptop audit[2760]: USER_AUTH pid=2760 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix,pam_gnome_keyring acct="erik" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty2 res=success'

There were no systemd journal entries between nov 20 23:18:08 and nov 20 23:18:15

I'm unsure whether this side-effect comes from the kernel/nouveau driver or from GNOME, but I'll try to do some more testing tomorrow with debug output enabled for gnome-settings-daemon (which I believe is responsible for switching monitors/backlights on/off) and report back here
Comment 44 Erik van Pienbroek 2016-11-21 02:14:14 EST
One additional thing I noticed is that when I manually power off the external monitor before locking the GNOME session then the backlight of the internal monitor stays off (instead of automatically switching back on after about 7 seconds as mentioned in my previous comment)
Comment 45 Hans de Goede 2016-11-21 04:40:45 EST
Hi,

(In reply to Erik van Pienbroek from comment #44)
> One additional thing I noticed is that when I manually power off the
> external monitor before locking the GNOME session then the backlight of the
> internal monitor stays off (instead of automatically switching back on after
> about 7 seconds as mentioned in my previous comment)

This behavior is likely caused by spurious KEY_SWITCHVIDEOMODE key presses being reported, I've recently fixed something very similar with this patch:

https://github.com/skeggsb/nouveau/commit/672575a95506511af26f924f11ce04256534041d

Here is a copr repo which has a kernel with that patch (as well as other nouveau fixes):

https://copr.fedorainfracloud.org/coprs/bskeggs/nouveau-atomic-mst/

Please give the kernel from there a try, it should fix the problem with the wakeup after locking with an external monitor connected.

Regards,

Hans
Comment 46 Erik van Pienbroek 2016-11-21 13:16:38 EST
I just tested with the nouveau-atomic-mst kernel, but the issue (where the backlight of my internal notebook automatically turns back on after 7 seconds) can also be reproduced with that one.

As suggested in the copr link I also added the boot flags 'log_buf_len=8M nouveau.debug=disp=trace,i2c=trace drm.debug=0x14' to generate more debug output. I also enabled debug output of gnome-settings-daemon.

I just uploaded a systemd journal log file which contains all the kernel and userspace logging (including nouveau and gnome-settings-daemon) which was generated while reproducing the issue. Here are the related timestamps:

nov 21 19:05:53 - Boot of kernel 4.8.8-300.nvmst.fc25.x86_64
nov 21 19:07:00 - Pressed Super+L to lock the GNOME session
(both monitors turns off now including both backlights)
nov 21 19:07:08 - Backlight of both the internal and the external monitors turn back on automatically showing just a blank screen
nov 21 19:07:29 - Unlock of the GNOME session

Perhaps I should also forward this information to the upstream bug?
Comment 47 Erik van Pienbroek 2016-11-21 13:18 EST
Created attachment 1222464 [details]
Logs belonging to comment 46
Comment 48 Hans de Goede 2016-11-23 05:16:30 EST
Hi,

Thanks for the DMI info, before I add the quirk though, I would like you to run one more test.

As for things waking up again after 7 seconds, this might be a gnome bug (there used to a bug which did this) is your gnome-shell fully up2date ?

So some (long long in the making) patches which are known to fix the brightness keys not working on some laptops have finally landed in drm-intel-next. These might also fix the backlight-control without needing the quirk.

Unfortunately creating a rpm from a random git kernel tree is not so easy, so I would like to ask you to manually build the kernel yourself, by following these instructions:

sudo dnf install -y git gcc make
git clone git://anongit.freedesktop.org/drm-intel
cd drm-intel
wget https://fedorapeople.org/~jwrdegoede/config-4.9.0-rc5
mv config-4.9.0-rc5 .config
make oldconfig
<the make oldconfig may ask some questions, simply hit enter to choose the defaults>
make -j4 bzImage && make -j4 modules && sudo make modules_install && sudo make install
<this is going to take a while, say approx. an hour or so>

And now you can reboot, note grub will default to your latest normally installed kernel, to pick this one you need to explictly select it.

Then see if:
a) The brightness keys now work
b) This perhaps also fixes brightness control without needing acpi_backlight=native

Thanks & Regards,

Hans
Comment 49 Erik van Pienbroek 2016-11-26 08:05:26 EST
Hi Hans,

I just looked at the git log differences between the DRM tree I was using earlier (drm-next rev d8c1abd) and the drm-intel fork you mentioned (I assume you were referring to the drm-intel-next-queued branch of the drm-intel git repo). In this list of differences I only found one ACPI/hotkey related commit (8e1b56a4, drm/i915: make i915 the source of acpi device ids for _DOD). That commit is specific for the i915 module which isn't used on my environment, so I don't think that using the drm-intel kernel will improve the situation. I'll give it a shot nevertheless to be certain and will report back the results.

Regards,

Erik
Comment 50 Erik van Pienbroek 2016-11-26 10:53:57 EST
As expected the drm-intel kernel (git rev a3f79ca) doesn't help in detection of the brightness hotkeys. I've tried both with and without the kernel option acpi_backlight=native and using evemu-record on multiple input devices, but none of that seems to improve the situation.

I also forwarded the debug logging (which was mentioned in comment 46) to the upstream bugreport.

Regarding your question in comment 48: All my tests were done using Fedora 25 with all current updates. I always update my system at least once a week. I also frequently monitor git activity of key components like the nouveau kernel driver and gnome-settings-daemon and when interesting commits show up (which may help in resolving this issue like the recent nouveau atomic modesetting commits) then I'll perform tests using them, so you can say that I'm not afraid of building custom kernels and running experimental software :)
Comment 51 Hans de Goede 2016-11-29 09:34:05 EST
Thanks for the testing of intel-drm, too bad it does not help :| I'm afraid I'm all out of clues / ideas for the brightness keys issue then.

I've submitted a patch with a quirk upstream to automatically apply acpi_backlight=native to this model in future kernels.
Comment 52 Fedora End Of Life 2017-07-25 14:41:20 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 53 Fedora End Of Life 2017-08-08 07:47:46 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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