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.
Issue still exists with both kernel-3.16.1-300.fc21 and kernel-3.17.0-0.rc1.git0.1.fc22
Backlight control on my notebook's internal display is still broken with 3.17.0-0.rc6.git0.1.fc22.x86_64
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
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
Created attachment 943809 [details] dmesg 3.15.10-201.fc20.x86_64 kernel
Created attachment 943810 [details] dmesg 3.17.0-0.rc7.git3.1.fc22.x86_64 kernel
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
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
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
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).
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).
(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
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.
(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.
(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
(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
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..
Backlight control is still broken with kernel 3.18.0-0.rc4.git2.1.fc22.x86_64 (which was built today: Nov 14 2014)
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
Hello, for me, the problem is solved in 3.17.3-200.fc20.x86_64. Thank you
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
(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.
Okay thanks, I'll wait for Ben to continue research on this issue
This issue is still valid with kernel 3.18.1-2 (which was built Thursday December 18 2014)
*********** 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.
See last comment, issue still exists with recent rawhide kernels
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
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> 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> Does this provide enough information to continue research?
After more debugging I think the following commit is the real culprit: commit 4874322e78d505d38c8d4481118af5c9f0e8306d Author: Ben Skeggs <bskeggs> 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> 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.
Created attachment 999342 [details] Patch which resolves the issue
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
Upstream bug filed @ https://bugs.freedesktop.org/show_bug.cgi?id=90351
*********** 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.
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?
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.
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
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
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)?
(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.
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..)
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.org list. Regards, Hans
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.
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
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)
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
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?
Created attachment 1222464 [details] Logs belonging to comment 46
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
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
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 :)
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.
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.
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.