Created attachment 104639 [details] kernel 3.16 dmesg I experienced issues with the backlight adjustment after installing Fedora on a TOSHIBA PORTEGE R830 laptop. The full detail of the issue is available on https://bugzilla.redhat.com/show_bug.cgi?id=1126159 To summarize: after booting the Fedora 21 kernel (3.16), 3 backlight interfaces are available (acpi_video0, intel_backlight, toshiba). The acpi_video0 and toshiba interfaces are not working after suspend/resume. Only the intel_backlight can change the backlight value after resume. Red Hat engineer Hans de Goede suggested as a fix to disable the acpi_video0 and toshiba at the kernel level to keep only the intel_backlight. He built a patched kernel with that change, but that change keeps the backlight unlit after suspend/resume (and changing the backlight value through sysfs has no effect). So he suggested I open a bug on the Intel driver here. I did the following tests with the result files in attachment. 1) Boot the Fedora 21 3.16.0 kernel (without X) with drm.debug=0x06 - do a register intel_reg_dump before suspend (intel_reg_dump_before_3.16.0-1.fc21.x86_64.txt) - suspend/resume, then dump the registers again (intel_reg_dump_after_3.16.0-1.fc21.x86_64.txt) - demsg: dmesg_3.16.0-1.fc21.x86_64.txt In this case, the backlight is working after suspend / resume (through the intel interface). 2) Boot the Fedora kernel patched by Hans with a change to disable the acpi_video0 and toshiba backlight interfaces. - register dump before suspend: intel_reg_dump_before_3.15.9-200.rhbz1126159.fc20.x86_64.txt - register dump after resume: intel_reg_dump_after_3.15.9-200.rhbz1126159.fc20.x86_64.txt - dmesg: dmesg_3.15.9-200.rhbz1126159.fc20.x86_64.txt In this case, the backlight is black after resuming.
Created attachment 104640 [details] intel_reg_dump before suspend 3.16
Created attachment 104641 [details] intel_reg_dump after resume 3.16
Created attachment 104642 [details] kernel 3.15 dmesg
Created attachment 104643 [details] intel_reg_dump before suspend 3.15
Created attachment 104644 [details] intel_reg_dump after resume 3.15
I noticed a way to turn the backlight on after resuming with the "intel backlight only" kernel: close and reopen the lid. But if you close the lid to put the laptop in standby, you still have to close/open the lid twice (once to resume, once to switch the backlight on).
Long time no updates, and I think we've fixed some related backlight issues. Is this still a problem with current upstream kernels, v3.19-rc or drm-intel-nightly of http://cgit.freedesktop.org/drm-intel?
Hopefully fixed. Unfortunately we still haven't found a way to permanently disable 8xx machines and automatically ship newer ones.
Err sorry this is SNB... those are generally better behaved but OEMs still put curses on them before shipment sometimes.
I'm still having the same issue with kernel 4.0 from Fedora 22 (4.0.4-301.fc22.x86_64). It's a bit more annoying now because the xorg workaround doesn't work with Gnome 3.16 (https://bugzilla.gnome.org/show_bug.cgi?id=747781). Do you need more information for fixing this issue?
I have the same issue on a Toshiba Sattelite R830. This problem has been present since I installed Ubuntu 2 years ago. I'm now using Arch Linux and I still have the issue. https://bugzilla.kernel.org/show_bug.cgi?id=21012 is the same bug.
Hi Sylvain, (In reply to Sylvain Pasche from comment #10) > I'm still having the same issue with kernel 4.0 from Fedora 22 > (4.0.4-301.fc22.x86_64). It's a bit more annoying now because the xorg > workaround doesn't work with Gnome 3.16 > (https://bugzilla.gnome.org/show_bug.cgi?id=747781). > > Do you need more information for fixing this issue? First of all make sure you are using Fedora 22 kernel version 4.0.2-300 or newer and that you do NOT have any backlight related options like "acpi_backlight=vendor" on your kernel commandline. If things do not work with F-22 kernel >= 4.0.2-300 without any special kernel commandline options, try booting F-22 kernel >= 4.0.2-300 with "video.use_native_backlight=1" added to the kernel commandline. After booting with "video.use_native_backlight=1" please do: ls /sys/class/backlight You should then only see "intel_backlight" there, if this fixes things please run the following from a terminal: grep '.*' /sys/class/dmi/id/*_* 2> /dev/null > dmi.log And copy and paste the output here so that a quirk for your model can be added to the kernel.
Hi Hans, Thanks for your reply. Indeed, with the "video.use_native_backlight=1" kernel parameter, only the intel_backlight interface is available. However, there is still the issue that after suspend+resume, there is no backlight (black screen), and I have to close and reopen the lid to turn it back on. (the laptop dmi results are the same as https://bugzilla.redhat.com/attachment.cgi?id=923510)
Hi, (In reply to Sylvain Pasche from comment #13) > Hi Hans, > > Thanks for your reply. Indeed, with the "video.use_native_backlight=1" > kernel parameter, only the intel_backlight interface is available. > > However, there is still the issue that after suspend+resume, there is no > backlight (black screen), and I have to close and reopen the lid to turn it > back on. > > (the laptop dmi results are the same as > https://bugzilla.redhat.com/attachment.cgi?id=923510) Hmm, what does "ls /sys/class/backlight" give as output with the latest F-22 kernels without anything on the kernel commandline? And what are the problem symptoms when not having anything on the kernel commandline ? Does brightness control after boot work then? And what about after suspend/resume? Can you also try booting without "video.use_native_backlight=1" and with: acpi_osi="!Windows 2012" on the kernel commandline?
Hi Hans, (In reply to Hans de Goede from comment #14) > Hmm, what does "ls /sys/class/backlight" give as output with the latest F-22 > kernels without anything on the kernel commandline? And what are the problem > symptoms when not having anything on the kernel commandline ? Does > brightness control after boot work then? And what about after suspend/resume? So, with kernel 4.0.4-301.fc22.x86_64 and nothing specific on the kernel command line: After boot, these two interfaces are available: ls -l /sys/class/backlight/ lrwxrwxrwx. 1 root root 0 May 26 2015 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 lrwxrwxrwx. 1 root root 0 May 26 2015 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight I can change the brightness on both. After a suspend+resume: The backlight is turned on. changing brightness of acpi_video0 has no effect changing brightness of intel_backlight works > Can you also try booting without "video.use_native_backlight=1" and with: > > acpi_osi="!Windows 2012" > > on the kernel commandline? I tried that and I have the same behavior as above. Gnome 3.16 gives priority on the acpi_video0 (firmware) interface over intel_backlight (raw), so I can't change the brightness using Gnome after suspend+resume.
(In reply to Sylvain Pasche from comment #15) <snip> > I can change the brightness on both. > > After a suspend+resume: > > The backlight is turned on. > changing brightness of acpi_video0 has no effect > changing brightness of intel_backlight works Ok, so it seems that the 2 backlight control methods are getting in each others way, and disabling the acpi_video0 one is not an option as then the backlight does not go back on after a suspend/resume. So lets try disabling the intel backlight control. I've done a scratch kernel build for F-22 with a patch which adds a module param which allows you to tell the intel driver to not touch the backlight: http://koji.fedoraproject.org/koji/taskinfo?taskID=9865887 Please install this kernel and then boot into it with: "i915.enable_backlight_control=0" (and no other backlight related options) added to the kernel commandline, then do: ls /sys/class/backlight And you should only see acpi_video0 there, then try if backlight control works, then suspend/resume and check if backlight control still works. I'll attach the patch I did here in case anyone following this wants to take a look, I'll submit it upstream once we've confirmed that it helps :) Regards, Hans
Created attachment 116122 [details] [review] [PATCH] drm: i915: Add an enable_backlight_control module parameter
(In reply to Hans de Goede from comment #17) > Created attachment 116122 [details] [review] [review] > [PATCH] drm: i915: Add an enable_backlight_control module parameter Hans, while I truly appreciate your efforts in fixing backlight issues, I really *really* would like to exhaust all other options before adding such module parameters. It should be made to Just Work(tm). All the cargo culting forum posts telling people to tweak their i915 module parameters are giving us headaches. We've even made some of our module parameters taint the kernel, and we won't look at bugs if people changed them from their platform specific defaults. Just wanted to let you know my opinion right from the start. ...but let's see if it helps. :)
Hi Jani, (In reply to Jani Nikula from comment #18) > (In reply to Hans de Goede from comment #17) > > Created attachment 116122 [details] [review] [review] [review] > > [PATCH] drm: i915: Add an enable_backlight_control module parameter > > Hans, while I truly appreciate your efforts in fixing backlight issues, I > really *really* would like to exhaust all other options before adding such > module parameters. It should be made to Just Work(tm). I understand and I agree, but it seems that there just is not enough manpower to look into backlight breaking on (somewhat) older machines such as this one. The reporter has attached register dumps of the i915 both before and after suspend / resume and no one seems to have seriously looked into these... Also having 2 pieces of code (the i915 driver and the firmware) poling at the same registers during suspend / resume is just wrong, that it happens to often work does not make it less wrong, we really should always be loading either the i915 or the acpi-video backlight driver and not both. > All the cargo culting forum posts telling people to tweak their i915 module > parameters are giving us headaches. We've even made some of our module > parameters taint the kernel, and we won't look at bugs if people changed > them from their platform specific defaults. Just wanted to let you know my > opinion right from the start. Note that my plan (if this helps) includes a follow up patch which allows getting the same result via a quirk and then to add a quirk for this (and likely also some other Toshiba models). So things will just work, and we won't have people referencing ancient ubuntu form posts and taking dark magic settings from there to make things work. Regards, Hans
(In reply to Hans de Goede from comment #16) [...] > Please install this kernel and then boot into it with: > "i915.enable_backlight_control=0" (and no other backlight related options) > added to the kernel commandline, then do: > > ls /sys/class/backlight > > And you should only see acpi_video0 there, then try if backlight control > works, then suspend/resume and check if backlight control still works. Hi Hans, I really appreciate your effort in trying to find a solution for this. Unfortunately, the situation with the patch is not very promising :-( After booting with that kernel + commandline option, I see only the acpi_video0 driver indeed. However, changing the brightness has no effect (the actual screen brightness doesn't change). After suspend / resume, the backlight is off. And closing / reopening the lid doesn't bring it back on.
(In reply to Hans de Goede from comment #19) > Also having 2 pieces of code (the i915 driver and the firmware) poling at > the same registers during suspend / resume is just wrong, that it happens to > often work does not make it less wrong, we really should always be loading > either the i915 or the acpi-video backlight driver and not both. Depending on the machine, the firmware might actually ask i915 to adjust the brightness through the ACPI opregion. So only one entity actually touches the backlight registers, with locks held, but there are two interfaces for it. This appears to be the case here too, and your patch disables the ACPI interface as well. One could try disabling just the registering of the intel_backlight sysfs interface. (Of course, there are also machines where the firmware messes with the backlight registers directly also. I don't know how to distinguish those.)
Hi, (In reply to Jani Nikula from comment #21) > (In reply to Hans de Goede from comment #19) > > Also having 2 pieces of code (the i915 driver and the firmware) poling at > > the same registers during suspend / resume is just wrong, that it happens to > > often work does not make it less wrong, we really should always be loading > > either the i915 or the acpi-video backlight driver and not both. > > Depending on the machine, the firmware might actually ask i915 to adjust the > brightness through the ACPI opregion. So only one entity actually touches > the backlight registers, with locks held, but there are two interfaces for > it. Ah I did not know that, that is good to know. Given the test results it looks like you're right and my patch is a bad idea. > This appears to be the case here too, and your patch disables the ACPI > interface as well. One could try disabling just the registering of the > intel_backlight sysfs interface. I deliberately disabled all of it and not just the sysfs interface, AFAICT nothing should touch the sysfs interface if the acpi_video0 interface is registered, as both the intel ddx and gnome will prefer acpi_video0 over the intel interface. Sylvain, do you still have an xorg.conf file hanging around telling the intel ddx to use the intel_backlight interface? Can you try running the latest Fedora-22 kernel without such a file and without any special kernel commandline arguments? If that does not help then I'm afraid I'm all out of ideas and one of the intel devs will need to look at reg-dumps and figure out what exactly is going on at a much lower level. If we need to get one of the Intel devs to look into the reg-dumps it would be good if you could provide new register dumps from both pre and post resume with the latest F-22 kernel without any special kernel commandline args. Regards, Hans
(In reply to Hans de Goede from comment #22) > Sylvain, do you still have an xorg.conf file hanging around telling the > intel ddx to use the intel_backlight interface? Can you try running the > latest Fedora-22 kernel without such a file and without any special kernel > commandline arguments? If that does not help then I'm afraid I'm all out of > ideas and one of the intel devs will need to look at reg-dumps and figure > out what exactly is going on at a much lower level. Hi Hans. I didn't have a xorg.conf file lying around. In fact, I also tested with the Fedora Workstation 22 installation DVD to make sure that I have nothing interfering. In this situation, I have the behavior described above: * two backlight interfaces are exposed: acpi_video0 and intel_backlight * they both work after boot * after suspend / resume, only the intel_backlight interface works * backlight is turned on after boot or resume Maybe we could implement the workaround in user space: set a udev device property telling Gnome that it should ignore the acpi_video0 interface and fall back to the intel_backlight one.
Hi, (In reply to Sylvain Pasche from comment #23) > (In reply to Hans de Goede from comment #22) > > Sylvain, do you still have an xorg.conf file hanging around telling the > > intel ddx to use the intel_backlight interface? Can you try running the > > latest Fedora-22 kernel without such a file and without any special kernel > > commandline arguments? If that does not help then I'm afraid I'm all out of > > ideas and one of the intel devs will need to look at reg-dumps and figure > > out what exactly is going on at a much lower level. > > Hi Hans. I didn't have a xorg.conf file lying around. In fact, I also tested > with the Fedora Workstation 22 installation DVD to make sure that I have > nothing interfering. In this situation, I have the behavior described above: > * two backlight interfaces are exposed: acpi_video0 and intel_backlight > * they both work after boot > * after suspend / resume, only the intel_backlight interface works > * backlight is turned on after boot or resume Ok, so while working on some other backlight stuff my mind drifted to this bug, and I think I've a solution for it now. It is not really pretty, but hopefully I will be able to sell it to the other upstream kernel devs. But first lets see if it actually works :) I've started another Fedora-22 scratch kernel build, with another patch (which I will attach shortly): http://koji.fedoraproject.org/koji/taskinfo?taskID=9945627 This is still building atm, but give it a try when it has finished building and let me know if that fixes things for you (I think it will). Regards, Hans
Created attachment 116288 [details] [review] [PATCH] acpi-video: Allow using acpi-video backlight control on resume only
Hi Hans, your fix does the trick :-). I see only the intel_backlight device and it works after resume. Thank you so much! :-)
Hi, (In reply to Sylvain Pasche from comment #26) > Hi Hans, your fix does the trick :-). I see only the intel_backlight device > and it works after resume. Good. Here is another scratch build (again still building atm): http://koji.fedoraproject.org/koji/taskinfo?taskID=9955471 With a polished version of the patch, which only enables the new behavior on your model laptop (based on dmi strings), if you can give this a test-run, then I'll submit this upstream as soon as I hear from you that I got the dmi matching right (iow it still works) Please also check that the backlight level gets restored correctly after a suspend/resume. E.g. set backlight to 50% suspend/resume, backlight should be back at 50%. Thanks & Regards, Hans
Created attachment 116317 [details] [review] [PATCH] acpi-video: Add a parameter to not register the backlight sysfs interface
Hi Hans, The latest version works well and the brightness level is restored on resume. Thanks a lot.
(In reply to Sylvain Pasche from comment #29) > Hi Hans, > The latest version works well and the brightness level is restored on > resume. Thanks a lot. Thanks for testing this, I've submitted the patch upstream.
acpidump please: # dnf install acpidump # acpidump > acpidump.txt Thanks.
Created attachment 116397 [details] ACPI dump
The acpidump shows that _BCM makes use of SMM code to do the backlight handling by writing some values to some fixed memory address and then write a value to IO port 0xB2: _BCM -> SMBR -> BIOT(arg0, arg1, ..., arg6) Method (BIOT, 7, Serialized) { IEAX = Arg0 IEBX = Arg1 IECX = Arg2 IEDX = Arg3 IESI = Arg4 IEDI = Arg5 SSMP = Arg6 } The IEXX are fields defined in an operation region of memory type and from their names, they seem to be meant to pass their values to the corresponding registers. And SSMP is defined as: OperationRegion (SPRT, SystemIO, 0xB2, 0x02) Field (SPRT, ByteAcc, Lock, Preserve) { SSMP, 8 } And the final write to it should trigger SMI. The SMM code may do something magical and I have no idea what would happen there. Sylvain also said that a LID status change could bring up the backlight, I suspect that has something to do with intel_lid_notify, perhaps this function bring up the backlight? Sylvain, I'll attach a test patch to disable the register of intel_lid_notify and then please test if open/close the LID, you can still turn the backlight on, thanks. You may get a black screen with this test patch, please prepare for that. If the result is no, then perhaps that means intel_lid_notify has the knowledge of turning the backlight on and we should use that somewhere in i915 driver to turn on the backlight during resume?
Created attachment 116413 [details] [review] Disable intel_lid_notify Sylvain, Please keep the LID open while doing the test except the last step when you will close and open it after resume to see if this patch makes any difference(previously the backlight will be turned on but now it may not). Thanks.
(In reply to Aaron Lu from comment #34) > Created attachment 116413 [details] [review] [review] > Disable intel_lid_notify > > Sylvain, > Please keep the LID open while doing the test except the last step when you > will close and open it after resume to see if this patch makes any > difference(previously the backlight will be turned on but now it may not). > Thanks. Sylvain, I hope that you can build your own kernels with the patches Aaron is providing so that I do not need to be in the middle. But if you've trouble building your own kernels, I can do scratch builds of the Fedora kernel with Aaron's patches for you.
@Hans: thanks for the proposal, I managed to build one myself. @Aaron: so I applied your patch on top of Fedora Rawhide's kernel (4.1.0-0.rc7.git0) and booted with the video.use_native_backlight=1 kernel parameter (in order to have the backlight off after resume). In this situation, closing and reopening the lid still turns the backlight on (as if the patch had no effect). I saw these kernel messages after resume (not sure if they were also there before): Jun 10 21:17:31 tosh kernel: pci 0000:00:1c.6: PCI bridge to [bus 07] Jun 10 21:17:41 tosh kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jun 10 21:17:41 tosh kernel: pci 0000:00:1c.6: PCI bridge to [bus 07] Jun 10 21:17:53 tosh kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jun 10 21:17:53 tosh kernel: pci 0000:00:1c.6: PCI bridge to [bus 07]
OK, thanks. So it means it's something else that made the backlight on, I don't know what it is, let's go with Hans patch then.
I would like to test this patch on Arch Linux. I've a Toshiba Satellite R830 which seems very similar to the Portège R830. I've never built a kernel, let alone patched it and I don't have the time to learn that kind of stuff at the moment.
Hi, (In reply to To Do from comment #38) > I would like to test this patch on Arch Linux. I've a Toshiba Satellite R830 > which seems very similar to the Portège R830. > > I've never built a kernel, let alone patched it and I don't have the time to > learn that kind of stuff at the moment. I'm afraid that I can only provide Fedora pre-built test kernels. For help with building a kernel for Arch I suggest you ask help on he usual places for Arch help.
I'm now using Fedora kernel 4.1.3-200.fc22.x86_64 and all is working fine. Thanks a lot Hans for fixing it :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.