Bug 1126159

Created attachment 923510 [details]
dmi.log

*** Bug 1126161 has been marked as a duplicate of this bug. ***

Hi again,

So to get a clear overall picture here, we have 4 cases by default without any kernel parameters:

F-20 - before suspend/resume: backlight controlable through slider, keys don't work
F-20 - after suspend/resume: backlight not controlable
F-21 - before suspend/resume: backlight control fully works
F-21 - after suspend/resume: backlight not controlable (did you test the slider ?)

And then there is the case when using acpi_backlight=vendor, where for F-20 you write:
"This fixes the issue. I can control the backlight even after suspending / resuming."

Does this mean that the slider now works after suspend/resume or that everything, including the keys works ?

Some more questions:

1) Which kernel (version) are you using in the F-20 tests?
2) Which kernel (version) are you using in the F-21 tests?
3) For F-20 booted without kernel options, can you for each of
/sys/class/backlight/acpi_video0
/sys/class/backlight/intel_backlight
/sys/class/backlight/toshiba
Please do (as root):
3a) cd into the dir
3b) cat max_brightness
3c) echo <half-of-max> > brightness
3d) echo <max> > brightness
3e) note if 3c / 3d change the brightness, write down max brightness + if echo-ing changes the brightness for this dir
4) Repeat 3 after suspend resume
5) Repeat 3 + 4 when booted with acpi_backlight=vendor
6) Repeat 3-5 with F-21

And then add a comment here with the results of all these tests.

Thanks,

Hans

Hi Hans,

Thanks for taking care of this.

I tried to analyze the situation a bit more. I'll try to separate the kernel behavior from the xorg/GNOME one to make things clearer (hopefully).

F20 (kernel 3.15.7-200.fc20.x86_64+debug) with no kernel parameter:

When I boot with the default options I have three backlight interfaces that all work (backlight changes when I echo values to them):
/sys/class/backlight/acpi_video0/actual_brightness:7
/sys/class/backlight/acpi_video0/brightness:7
/sys/class/backlight/acpi_video0/max_brightness:7
/sys/class/backlight/intel_backlight/actual_brightness:4539
/sys/class/backlight/intel_backlight/brightness:4539
/sys/class/backlight/intel_backlight/max_brightness:4539
/sys/class/backlight/toshiba/actual_brightness:7
/sys/class/backlight/toshiba/brightness:7
/sys/class/backlight/toshiba/max_brightness:7

After a suspend/resume only the intel_backlight interface works (echoing anything to toshiba or acpi_video has no effect).

F20 with acpi_backlight=vendor:

In this case, I only have two interfaces: intel_backlight and toshiba.

These interfaces behave the same way as above (both work after boot, only intel_backlight works after a suspend/resume).


Now with F21 (3.16.0-1.fc21.x86_64) with no kernel parameters:

Same behavior as the F20 kernel (three interfaces, same values as above, all work after boot). Same situation after a suspend/resume: only intel_backlight works.

F21 with acpi_backlight=vendor:

Two interfaces like F20: intel_backlight and toshiba.
*difference from F20*: the toshiba interface doesn't work just after boot!


Preliminary analysis: intel_backlight always work in any condition. toshiba and acpi_video only work after the first boot. "acpi_backlight=vendor" parameter disables the acpi_video interface and causes the toshiba interface to not work after boot on 3.16.


Now from the Xorg point of view:

xorg + F20:

when the three interfaces are available, xorg picks acpi_video0:
[    12.308] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
  -> that explains why the backlight doesn't work after suspend/resume by default.

If there are only toshiba and intel_backlight available, it picks intel:
[    11.466] (--) intel(0): found backlight control interface /sys/class/backlight/intel_backlight
  -> that's why the backlight always works with acpi_backlight=vendor on F20.


xorg + F21:

when the three interfaces are available, it picks acpi_video0:
gdm-Xorg-:0[944]: (--) intel(0): Found backlight control interface acpi_video0 (type 'firmware') for output LVDS1
  -> backlight doesn't work after resume

with only toshiba and intel_backlight:
gdm-Xorg-:0[939]: (--) intel(0): Found backlight control interface toshiba (type 'platform') for output LVDS1
  -> difference from F20: it doesn't pick intel, which is why the backlight doesn't work after resume even with acpi_backlight=vendor


Finally for the Gnome + backlight keys that sometime don't work even though the slider does: I tried to strace the xorg process and I could notice that when the max_brightness is 7, xorg always write the same values to sysfs when activating a brightness key. I think this is https://bugzilla.gnome.org/show_bug.cgi?id=729500 which should be fixed in F21 and explains why the keys work after boot there.

Another issue that I came across: after a resuming from hibernate, the brightness keys don't work any more (xorg writes nothing to sysfs when the keys are activated and no osd is visible). I guess that should be an issue with either GNOME or xorg (the slider still works).

Sorry for the long rant ;-)

Hi,

Thanks for the detailed analysis. I've been thinking about this for a bit, and my conclusion is that the proper way to fix this is to simply disable the thosiba and acpi_video interfaces from within the toshiba driver, after which everything should just work.

In order to add a quirk for this I need some info to dmi match your laptop model, can you please do:

for i in /sys/class/dmi/id/*; do echo "$i: $(cat $i 2> /dev/null)"; done > log

And then attach the generated log file here.

Regards,

Hans

Hi Hans,

Ok, that sounds like a good plan. You can find the dmi information in attachment 923510 [details].

Thanks,
Sylvain

Hi Sylvain,

Sorry for being a bit slow on this one. I was at a conference (Flock) and I was hoping to be able to get this done there.

I've prepared a kernel scratch build with a patch as described in comment 5:

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

Note this is currently still building. Please download kernel-3.15.9...rpm for your architecture, then install it using: "sudo rpm -ivh kernel-3.15.9...rpm", and reboot into the new kernel.

After this your backlight controls should just work both before and after suspend, both through the keys and through the slider.

Please let me know if this fixes things, then I'll send the patch upstream and add it to the official Fedora kernel packages.

Thanks & Regards,

Hans

Hi Hans,

I hope you had fun at Flock ;-)

With your prepared kernel, I get only the intel backlight interface as expected. But there's another issue after suspend/resume: the screen is black (no backlight) and echoing to the sysfs intel brightness file has no effect.

I tried with a pristine 3.15.9 kernel from https://admin.fedoraproject.org/updates/kernel-3.15.9-200.fc20 to make sure it wasn't about a regression between 3.15.7 and 3.15.9, but both kernels behave the same way (i.e. no black screen after resume).

So I would guess that even if the toshiba interface doesn't work well, it might still be needed to initialize the backlight after resume?

Bummer (that the backlight is now off after suspend/resume).

Can you try booting F-21 with the standard F-21 kernel with
"acpi_osi=Linux" on the kernel commandline (and without any acpi_backlight=...)

And see if that fixes things ?

Thanks,

Hans

Hi Hans,

Unfortunately that doesn't seem to help, I have the same behavior with or without that parameter with kernel 3.16.0-1.fc21.x86_64.

The workaround that works for me at the moment is the "Backlight"       "intel_backlight" option in /etc/X11/xorg.conf.d/20-intel.conf. But ideally things should work without it.

Hi,

(In reply to Sylvain Pasche from comment #10)
> The workaround that works for me at the moment is the "Backlight"      
> "intel_backlight" option in /etc/X11/xorg.conf.d/20-intel.conf. But ideally
> things should work without it.

Does that also fixes the brightness keys not working after suspend / resume ?

Note I'm with vacation next week, so if you don't hear back from me that is why.

Regards,

Hans

Yes, brightness keys work after resume when xorg is forced to use the intel interface.

Ok.

I think the best way to proceed with this is to get the intel developers involved directly, have them fix the backlight off after resume when only the intel backlight is loaded issue, and then go with my patch on top of that.

Can you please file a bug with the intel devs as described here:

https://01.org/linuxgraphics/documentation/how-report-bugs

They will likely want a reg dumps both before and after suspend / resume, both with a working kernel,
and with the scratch build kernel I've given you.

So please also do "yum install intel-gpu-tools" and then make a register dump using intel_reg_dump both before and after suspend, with both a standard kernel + my scratch build (so 4 dumps in total),
gzip those and attach them to the bug upstream.

Once the bug is filed please add a comment here with the link to the upstream bug.

Regards,

Hans

I opened https://bugs.freedesktop.org/show_bug.cgi?id=82634

Thanks,
Sylvain

*********** 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 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  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 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Fixed upstream in kernel 4.1 (https://bugs.freedesktop.org/show_bug.cgi?id=82634).