Bug 1126159 - Backlight brightness issue with Toshiba Portege R830
Summary: Backlight brightness issue with Toshiba Portege R830
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
: 1126161 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-02 21:15 UTC by Sylvain Pasche
Modified: 2015-08-15 13:28 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1126161 (view as bug list)
Last Closed: 2014-12-10 14:59:20 UTC

Attachments (Terms of Use)
dmesg.log (67.36 KB, text/plain)
2014-08-02 21:15 UTC, Sylvain Pasche
no flags Details
dmi.log (783 bytes, text/plain)
2014-08-02 21:15 UTC, Sylvain Pasche
no flags Details

Description Sylvain Pasche 2014-08-02 21:15:03 UTC
Created attachment 923509 [details]

Description of problem:

I installed F20 on this laptop and I can't change the backlight brightness using the function keys (it stays between 97-100%. I can still change it using the slider on the top menu, but if I suspend/resume I can't change the brightness any more).

I followed the instructions from http://hansdegoede.livejournal.com/13889.html:

With the default kernel parameters
  ls /sys/class/backlight/
  acpi_video0  intel_backlight  toshiba

With the video.use_native_backlight=1 parameter
  The issue is still present.

  ls /sys/class/backlight/
  acpi_video0  intel_backlight  toshiba

With the acpi_backlight=vendor parameter:
  This fixes the issue. I can control the backlight even after suspending / resuming.

  ls /sys/class/backlight/
  intel_backlight  toshiba

Comment 1 Sylvain Pasche 2014-08-02 21:15:56 UTC
Created attachment 923510 [details]

Comment 2 Hans de Goede 2014-08-04 18:12:00 UTC
*** Bug 1126161 has been marked as a duplicate of this bug. ***

Comment 3 Hans de Goede 2014-08-04 18:23:01 UTC
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
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.



Comment 4 Sylvain Pasche 2014-08-05 20:52:59 UTC
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):

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 ;-)

Comment 5 Hans de Goede 2014-08-07 13:53:43 UTC

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.



Comment 6 Sylvain Pasche 2014-08-07 15:20:30 UTC
Hi Hans,

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


Comment 7 Hans de Goede 2014-08-12 10:01:29 UTC
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:


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,


Comment 8 Sylvain Pasche 2014-08-12 19:18:46 UTC
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?

Comment 9 Hans de Goede 2014-08-12 22:25:12 UTC
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 ?



Comment 10 Sylvain Pasche 2014-08-13 19:10:24 UTC
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.

Comment 11 Hans de Goede 2014-08-14 09:20:10 UTC

(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.



Comment 12 Sylvain Pasche 2014-08-14 09:51:40 UTC
Yes, brightness keys work after resume when xorg is forced to use the intel interface.

Comment 13 Hans de Goede 2014-08-14 10:05:32 UTC

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:


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.



Comment 14 Sylvain Pasche 2014-08-14 21:59:46 UTC
I opened https://bugs.freedesktop.org/show_bug.cgi?id=82634


Comment 15 Justin M. Forbes 2014-11-13 15:59:13 UTC
*********** 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.

Comment 16 Justin M. Forbes 2014-12-10 14:59:20 UTC
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.

Comment 17 Sylvain Pasche 2015-08-15 13:28:59 UTC
Fixed upstream in kernel 4.1 (https://bugs.freedesktop.org/show_bug.cgi?id=82634).

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