Bug 21012

Summary: post-resume, backlight controls stop working (Toshiba Portege R700)
Product: Platform Specific/Hardware Reporter: Jon Dowland (jon+bugzilla.kernel.org)
Component: i386Assignee: platform_i386
Status: RESOLVED CODE_FIX    
Severity: normal CC: alan.pater, alan, alexl, Alex_kernel, entodoays, erusan, gokcen.eraslan, gregory.clemenceau, john, jop, jwrdegoede, lukescharf, m, martin-kernel-bugzilla, Martin.Corley, mendoza.ricardo, nt1277, sylvain.pasche, theo148, vadim.bich, wicke
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.2 Subsystem:
Regression: No Bisected commit-id:
Attachments: output of acpidump
workaround without toshset

Description Jon Dowland 2010-10-23 22:51:08 UTC
Hello,

On a Toshiba Portege R700 laptop, the backlight control works fine, until a suspend, and does not work post suspend to RAM/resume.

Tested in single user mode, manipulating /sys/class/backlight/toshiba/brightness directly, using /sys/power/state to trigger suspend;  as well as gnome-power-manager invoked suspend in a multiuser mode GNOME desktop session.
Comment 1 Jon Dowland 2010-10-23 22:53:41 UTC
Created attachment 34592 [details]
output of acpidump

Output generated via acpidump prior to a suspend (no suspends since boot).  The output is identical post-resume.
Comment 2 Jon Dowland 2010-10-23 23:08:22 UTC
I originally reported this downstream at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599768

Debian since backported http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6335e4d56681f6f08f24f4b812a72d402793d393 to their kernel but that did not resolve the problem.

So I have found this bug in:

2.6.32
2.6.32 + 6335e4d56681...
2.6.36-rc6

I have read of some people discovering it in Ubuntu, cf http://ubuntuforums.org/showthread.php?t=1550219

They seem to have workaround scripts that resolve the issue, using the "toshset" utility which uses an out-of-tree patch to toshiba-acpi (I think related to this one: http://git.debian.org/?p=users/derevko-guest/toshset.git;a=blob;f=debian/toshiba-acpi/2.6.28/toshiba_acpi.c;h=4f682fb1784c7a446e06d36d60ea3c2621e83315;hb=HEAD)
Comment 3 Gabriel Wicke 2011-01-15 08:03:18 UTC
I experience the same problem on 2.6.32 and 2.6.37 (Debian kernels), using a Satellite R630 which is the same basic hardware as the Portege R705 and R700 (minus the 3G and fingerprint reader).

Interestingly, brightness controls are restored after returning from hibernate, even if they were non-functional after a suspend before.
Comment 4 alexl 2011-01-22 22:47:10 UTC
Confirming problem with Fedora 14 on my Toshiba Portege 705.
Comment 5 alexl 2011-01-22 22:48:02 UTC
See discussion here: http://forums.fedoraforum.org/showthread.php?t=254382
Comment 6 Ricardo Mendoza 2011-05-15 12:02:57 UTC
Any news regarding this? I'm experiencing this bug in 2.6.38 as well, and I've read of several new reports.
Comment 7 Alexandre 2011-05-17 22:40:38 UTC
I can confirm the bug with the Toshiba Portégé R830 model (using 2.6.38)
Comment 8 Martin Corley 2011-05-30 11:38:24 UTC
Confirmed with Toshiba Satellite R830, 2.6.38
Comment 9 vadim.bich 2011-06-28 01:46:52 UTC
Same symptoms on Toshiba Portege r835-p50 using 2.6.38/2.6.39
Comment 10 John Cooper 2011-07-12 16:00:36 UTC
Getting the same here on Toshiba Portégé R830 using 3.0-rc6
Comment 11 gregory.clemenceau 2011-08-14 12:41:32 UTC
I can confirm the bug with the Toshiba Portégé R700 (2.6.35/2.6.36/2.6.37/2.6.38/2.6.39 and 3.0.1-1)
Comment 12 Jose Pereira 2011-08-15 22:53:39 UTC
Created attachment 68972 [details]
workaround without toshset

The attached patch provides a workaround without toshset, as it is becoming increasingly difficult to make toshset work post 2.6.39. It makes wirting to /sys/class/backlight/toshiba/brightness work by reproducing the effect of toshset -bl on. Using the acpi video backlight control does not work.

This patch works best with the acpi_backlight=vendor kernel command line option to disable /sys/class/backlight/acpi*, making desktop tools use the toshiba brightness control by default. I tested it on Fedora 15 with kernel 3.0 (aka kernel-2.6.40-4) and KDE.
Comment 13 Martin Ling 2012-02-02 15:57:50 UTC
I tested the patch in comment #12, applied to the Ubuntu 3.0.0-15 kernel tree.

It did not fix the problem on my Toshiba Satellite R830, with or without acpi_backlight=vendor.

I have been searching around, people are also reporting this problem in kernels at least as late as 3.1.1. I haven't tried 3.2.x yet.

This is being tracked for Ubuntu at:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606547
Comment 14 Martin Ling 2012-02-02 16:54:50 UTC
In case it's of use to anyone reading, here's a summary of the situation as far as I've been able to understand it so far:

- Brightness control for Toshiba laptops used to be done with the toshset tool, via the 'toshiba' module and a /dev/toshiba device which exposed the Toshiba HCI (hardware config interface?) to user space.

- We are (rightly) trying to get rid of vendor-specific hacks like this and support all hardware through the same standard kernel interfaces.

- The 'toshiba_acpi' module, which replaces the 'toshiba' module, no longer provides the /dev/toshiba device. It controls brightness itself and exposes this through standard interfaces without needing the toshset tool.

- On some machines, this stops working after suspend and stays broken until a power cycle.

- There is a patch around for the toshiba_acpi module which adds the /dev/toshiba device back so that toshset can control the brightness the old fashioned way, which works after suspend on at least some systems. Most of the workarounds found for this problem are therefore based on applying that patch to the kernel and writing scripts that use toshset to control the brightness when required. This is not a real solution though and is getting harder to maintain as the kernel moves on. The patch has been rejected from mainline.

- Jose Pereira's patch in comment #12 tries to solve the problem without needing /dev/toshiba and toshset, by adding code to toshiba_acpi that reproduces what toshset does. This apparently works for his model (he doesn't say which it is) but unfortunately does not work on my R830. However, something like this is much more likely to be the right solution.

- There are some other patches by Niv Sardi on the Debian bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599768#55). These are also based on trying to get toshiba_acpi to do the same as toshset. He reports that on his R800 after his patch, adjusting the backlight via /sys/class/backlight/toshiba/brightness after suspend works but setting it via the hotkeys does not.

- Nobody has reported anywhere that this is fixed yet, it was still a problem as of at least 3.1.1.

- I think the next step is to look at Jose and Niv's patches, and the toshset code, and try to develop a working patch for the toshiba_acpi module based on all these sources.
Comment 15 Tamás Németh 2012-02-18 20:49:47 UTC
I still observe thist problem with openSUSE 12.1's 3.1.9 kernel. The interesting thing is that backlight control gets broken ONLY during suspend (to RAM)/resume cycles. Hibernating (to disk) does not break backlight control, moreover it fixes backlight being broken by s2ram! It always behaved this way as fas as I can remember (and I've been using a Toshiba R700 Portege).
Comment 16 Martin Ling 2012-04-10 11:24:45 UTC
This is still broken as of 3.3.1 according to a report at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606547

Seth Forshee has made some progress reported here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778

It sounds like his results may be similar to Niv Sardi's from the Debian report - he has a means to control the backlight after resume but needs more work to integrate properly.

I've asked him to have a look at the other patches and report here.
Comment 17 Luke Scharf 2012-04-10 16:45:45 UTC
This bug affects me on a Toshiba R835-P56X, as well.

I'll help if I can, but my day job is keeping me quite busy.
Comment 18 Jorge A. 2012-05-18 20:49:34 UTC
I can confirm this bug as well
uname -a
3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Comment 19 Jose Pereira 2012-06-13 14:25:44 UTC
(In reply to comment #14)
> 
> - Jose Pereira's patch in comment #12 tries to solve the problem without
> needing /dev/toshiba and toshset, by adding code to toshiba_acpi that
> reproduces what toshset does. This apparently works for his model (he doesn't
> say which it is) but unfortunately does not work on my R830. However,
> something
> like this is much more likely to be the right solution.

My model is a 2010 R700. Actually, I'm no longer using this workaround. With Fedora 17 and kernel 3.4, I'm using toshiba_acpi-0.20 from:

https://github.com/malaterre/PublicRep

together with the following recipe:

 - add acpi_backlight=vendor in the kernel command line
 - place the attached script in /etc/pm/sleep.d/

This makes KDE use the intel_backlight interface (instead of acpi_video, which is still broken), providing smooth fine-grained setting of brightness. On wakeup from suspend, poking the toshiba interface is needed to turn backlight back on.

-----------------
#!/usr/bin/env sh
# /etc/pm/sleep.d/99toshiba

if [ $1 == suspend ]
then
        cat /sys/class/backlight/intel_backlight/brightness > /var/run/brightness
elif [ $1 == resume ]
then
        echo 3 > /sys/class/backlight/toshiba/brightness
        cat /var/run/brightness > /sys/class/backlight/intel_backlight/brightness
fi
Comment 20 Martin Ling 2012-06-13 14:35:52 UTC
(In reply to comment #19)
> 
> together with the following recipe:
> 
>  - add acpi_backlight=vendor in the kernel command line
>  - place the attached script in /etc/pm/sleep.d/

I forgot to mention on this bug report that I've now been using this same workaround successfully for some time on my Satellite R830. However I didn't make any changes to toshiba_acpi - it worked out of the box for me (at least on a Ubuntu-built kernel). All I needed was acpi_backlight=vendor and a resume script to poke the toshiba interface.
Comment 21 gregory.clemenceau 2013-01-25 11:31:05 UTC
>  - add acpi_backlight=vendor in the kernel command line
>  - place the attached script in /etc/pm/sleep.d/

works for me !

Arch linux,kernel 3.7.4-1 x86_64
Comment 22 To Do 2013-06-05 07:42:57 UTC
I have a Satellite R830 running Ubuntu 13.04 and kernel 3.8.0. I have the same problem in this bug.

In Ubuntu 12.10 and kernek 3.5.0, simply adding the acpi_backlight=vendor and acpi_osi=Linux kernel commands solved the issue. Note that I needed both arguments for it to work.

With the new kernel this workaround no longer works. Furthermore, the brightness steps are the same as without the kernel arguments.

I tried adding the script in /etc/pm/sleep.d/ but this prevented the laptop from going to sleep.

Any ideas how to solve the issue?
Comment 23 m 2013-07-20 13:18:40 UTC
My Satellite Z830 running kernel 3.8.0 (Ubuntu 13.04) has this issue. Adding the script to /etc/pm/sleep.d/ does NOT help.
Comment 24 To Do 2013-07-20 13:58:21 UTC
I worked around this problem by writing two scripts to increase and decrease brightness, modifying permissions of the /sys/class/backlight/intel_backlight/brightness file to 646, and assigning shortcut keys to brightness control.

Decrease brightness script:
actual=`cat "/sys/class/backlight/intel_backlight/actual_brightness"`
max=`cat "/sys/class/backlight/intel_backlight/max_brightness"`
new=$(($actual-100))
percent=`echo "$new/$max*100" | bc -l`
percent=$( printf "%.0f" $percent )%
echo $new | tee /sys/class/backlight/intel_backlight/brightness
for i in {0..100..10}
    do
          killall notify-osd
          notify-send " " $percent -i notification-display-brightness-low
          sleep 1
    done

Increase brightness script:
actual=`cat "/sys/class/backlight/intel_backlight/actual_brightness"`
max=`cat "/sys/class/backlight/intel_backlight/max_brightness"`
new=$(($actual+100))
percent=`echo "$new/$max*100" | bc -l`
percent=$( printf "%.0f" $percent )%
echo $new | tee /sys/class/backlight/intel_backlight/brightness
for i in {0..100..10}
    do
          killall notify-osd
          notify-send " " $percent -i notification-display-brightness-high
          sleep 1
    done
Comment 25 gregory.clemenceau 2014-01-09 17:20:31 UTC
"Jose Pereira" script does not work anymore since update kernel.
I have a 64-bit kernel 3.12.6-1 (arch linux)
After resume, the line:
echo 3> /sys/class/backlight/toshiba/brightness
does no work.
The value in /var/run/brightness remains the same.

"To Do" solution seems to me less clean (change /sys/class/backlight/intel_backlight/brightness).
It works but I have strange effects with notifications (xfce).
Comment 26 gregory.clemenceau 2014-01-10 11:41:18 UTC
The scripts are no longer useful.
Just add the acpi_backlight=vendor (grub) and put in /etc/X11/xorg.conf.d/80-backlight.conf :

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "Backlight"       "intel_backlight" # use your backlight that works here
EndSection

ArchWiki:
https://wiki.archlinux.org/index.php/Backlight

Kernel 3.12.6-1 (x86_64) under Archlinux, xorg-server 1.14.5-2
Comment 27 To Do 2014-01-10 15:12:31 UTC
I managed to solve the problem in a much cleaner way.

I tried to create a custom xorg.conf file with the above content but my system didn't boot.

Finally, I tried the following procedure: 
http://askubuntu.com/a/281685/27968

I got errors when starting lightdm BUT it created a xorg.conf.failsafe file.

I opened it and modified it by adding the option line under "Device" as follows:

Section "Device"
       Identifier      "Configured Video Device"
       Driver          "intel"
       Option          "Backlight"       "intel_backlight"
EndSection
#
Section "Monitor"
       Identifier      "Configured Monitor"
EndSection
#
Section "Screen"
       Identifier      "Default Screen"
       Monitor         "Configured Monitor"
       Device          "Configured Video Device"
EndSection

And bingo! Everything is working as it should.
Comment 28 Alan Pater 2014-10-26 16:20:22 UTC
My Portege R700 has this issue. I reported it on Launchpad: 
    https://bugs.launchpad.net/linux/+bug/1385453

I tested up to kernel 3.17.1.
Comment 29 Alan Pater 2014-10-26 16:43:43 UTC
Also tried blacklisting the toshica_acpi module as per 
  https://bugzilla.kernel.org/show_bug.cgi?id=45421

That did not make any difference. After resume Fn-F6 & Fn-F7 do not control the backlight.
Comment 30 gregory.clemenceau 2014-11-04 21:00:22 UTC
you must removed "acpi_backlight=vendor" in the "grub" and leave a file /etc/X11/xorg.conf.d/80-backlight.conf (comment 26).

It's OK !
Comment 31 gregory.clemenceau 2014-11-04 21:01:58 UTC
you must removed "acpi_backlight=vendor" in the "grub" and leave a file /etc/X11/xorg.conf.d/80-backlight.conf (comment 26).

It's OK : Arch linux / kernel 3.17.2-1
Comment 32 Alan Pater 2014-11-04 22:45:58 UTC
As a workaround, creating the xorg.conf file works on Ubuntu as well, but I would love for this to work out of the box. Does something need to be changed in the kernel to recognize that this model of Toshiba uses the Intel Backlight?
Comment 33 Alan 2015-02-19 16:00:23 UTC
Not sure - you'd need to ask the distributions rather than kernel folks probably ?
Comment 34 Sylvain Pasche 2015-05-25 16:33:46 UTC
Freedesktop bug, for fixing the Intel driver: https://bugs.freedesktop.org/show_bug.cgi?id=82634
Comment 35 Hans de Goede 2015-06-05 09:56:17 UTC
Hi All,

I've a kernel patch to fix this, see:
https://bugs.freedesktop.org/show_bug.cgi?id=82634

This is the patch:
https://bugs.freedesktop.org/attachment.cgi?id=116317

I would appreciate it if people could test this on affected models other then the Portege R830, and if it works provide me with dmi info for your laptop by copy and pasting the output of this command:

grep '.*' /sys/class/dmi/id/*_* 2> /dev/null

here, then I can enable this workaround by default on your model laptop too.

To test this, build a kernel with the patch, remove any special backlight options you may have like
acpi_backlight=vendor from the kernel commandline, and add: "video.disable_backlight_sysfs_if=1".

Also make sure that you do not have:

Option      "Backlight"       "intel_backlight"

In any xorg.conf files, or any other userspace workarounds active and then boot into the new kernel.

Regards,

Hans
Comment 36 Hans de Goede 2016-01-11 13:48:27 UTC
I've just gotten a report by email, including dmi strings, conforming that "video.disable_backlight_sysfs_if=1" fixing the backlight issues for the R700 as well.

I've send a patch upstream adding a quirk for the Portege 700. This bug can be closed once that patch has been merged.
Comment 37 To Do 2016-01-13 20:56:50 UTC
I can confirm that adding this parameter on a Toshiba Satellite R830 (P32LE) solves the problem. The toshiba backlight device disappears and the only one remaining in intel-backlight, the one that works. Please add this model to the patch.
Comment 38 Hans de Goede 2016-01-14 08:09:16 UTC
Hi,

(In reply to To Do from comment #37)
> I can confirm that adding this parameter on a Toshiba Satellite R830 (P32LE)
> solves the problem. The toshiba backlight device disappears and the only one
> remaining in intel-backlight, the one that works. Please add this model to
> the patch.

Can you please collect the dmi strings for your model by copy and pasting the output of this command:

grep '.*' /sys/class/dmi/id/*_* 2> /dev/null

here, then I can enable this workaround by default on your model laptop too.

Note that the _serial and _asset_tag bits contain information unique to your laptop and as such may be considered privacy sensitive data, feel free to omit those lines.

Thanks & Regards,

Hans
Comment 39 To Do 2016-01-14 08:32:40 UTC
Output of grep '.*' /sys/class/dmi/id/*_* 2> /dev/null on Toshiba R830:


/sys/class/dmi/id/bios_date:01/08/2013
/sys/class/dmi/id/bios_vendor:TOSHIBA
/sys/class/dmi/id/bios_version:Version 4.10  
/sys/class/dmi/id/board_asset_tag:0000000000
/sys/class/dmi/id/board_name:Portable PC
/sys/class/dmi/id/board_vendor:TOSHIBA
/sys/class/dmi/id/board_version:Version A0
/sys/class/dmi/id/chassis_asset_tag:0000000000
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:TOSHIBA
/sys/class/dmi/id/chassis_version:Version 1.0
/sys/class/dmi/id/product_name:SATELLITE R830
/sys/class/dmi/id/product_version:PT32LE-01Y00DFR
/sys/class/dmi/id/sys_vendor:TOSHIBA
Comment 40 To Do 2016-01-14 08:35:10 UTC
Here are the results of grep '.*' /sys/class/dmi/id/*_* 2> /dev/null:

/sys/class/dmi/id/bios_date:01/08/2013
/sys/class/dmi/id/bios_vendor:TOSHIBA
/sys/class/dmi/id/bios_version:Version 4.10
/sys/class/dmi/id/board_name:Portable PC
/sys/class/dmi/id/board_vendor:TOSHIBA
/sys/class/dmi/id/board_version:Version A0
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:TOSHIBA
/sys/class/dmi/id/chassis_version:Version 1.0
/sys/class/dmi/id/product_name:SATELLITE R830
/sys/class/dmi/id/product_version:PT32LE-01Y00DFR
/sys/class/dmi/id/sys_vendor:TOSHIBA
Comment 41 Hans de Goede 2016-01-14 13:25:31 UTC
(In reply to To Do from comment #40)
> Here are the results of grep '.*' /sys/class/dmi/id/*_* 2> /dev/null:

Thanks, I've added the SATELLITE R830 to the list of devices needing "video.disable_backlight_sysfs_if=1".
Comment 42 erusan 2016-01-19 22:02:55 UTC
I'm having this backlight problem on a Dell 5737. The user space workaround (Option "Backlight" "intel_backlight") used to work, and now I patch gnome-settings-daemon (instructions found here: https://bbs.archlinux.org/viewtopic.php?id=195967) to make the user space workaround work again.

I've tried the four boot parameters suggested at Hans' blog (http://hansdegoede.livejournal.com/13889.html), but each has the same result as no parameters at all:

OSD works, backlight does not change, and output of ls /sys/class/backlight is "dell_backlight  intel_backlight"

This is on Debian with kernel 4.3.
Comment 43 Hans de Goede 2016-01-20 08:58:29 UTC
Hi,

(In reply to erusan from comment #42)
> I'm having this backlight problem on a Dell 5737. The user space workaround
> (Option "Backlight" "intel_backlight") used to work, and now I patch
> gnome-settings-daemon (instructions found here:
> https://bbs.archlinux.org/viewtopic.php?id=195967) to make the user space
> workaround work again.
> 
> I've tried the four boot parameters suggested at Hans' blog
> (http://hansdegoede.livejournal.com/13889.html), but each has the same
> result as no parameters at all:
> 
> OSD works, backlight does not change, and output of ls /sys/class/backlight
> is "dell_backlight  intel_backlight"
> 
> This is on Debian with kernel 4.3.

This seems like a similar, yet unrelated issue. Can you please file a new bug for this (and put me in the Cc), and provide the output of: "ls /sys/class/backlight" when not specifying any kernel parameters, as well as with "acpi_backlight=native" on on the kernel commandline. Also can you let me know if using "acpi_backlight=native" on on the kernel commandline allows things to work for you with an unpatched userspace?

Regards,

Hans
Comment 44 Hans de Goede 2016-01-20 09:03:33 UTC
(In reply to Hans de Goede from comment #43)
> Hi,
> 
> (In reply to erusan from comment #42)
> > I'm having this backlight problem on a Dell 5737. The user space workaround
> > (Option "Backlight" "intel_backlight") used to work, and now I patch
> > gnome-settings-daemon (instructions found here:
> > https://bbs.archlinux.org/viewtopic.php?id=195967) to make the user space
> > workaround work again.
> > 
> > I've tried the four boot parameters suggested at Hans' blog
> > (http://hansdegoede.livejournal.com/13889.html), but each has the same
> > result as no parameters at all:
> > 
> > OSD works, backlight does not change, and output of ls /sys/class/backlight
> > is "dell_backlight  intel_backlight"
> > 
> > This is on Debian with kernel 4.3.
> 
> This seems like a similar, yet unrelated issue. Can you please file a new
> bug for this (and put me in the Cc), and provide the output of: "ls
> /sys/class/backlight" when not specifying any kernel parameters, as well as
> with "acpi_backlight=native" on on the kernel commandline. Also can you let
> me know if using "acpi_backlight=native" on on the kernel commandline allows
> things to work for you with an unpatched userspace?

Quick follow up, I just found this commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=08a56226d

Which seems like it may be the culprit of your issues, can you try building a kernel with that commit reverted, and provide the output of "ls /sys/class/backlight" with that kernel, as well as check if things will work with an unpatched userspace with that kernel ?

Thanks & Regards,

Hans
Comment 45 Hans de Goede 2016-01-21 13:31:04 UTC
The patches adding the quirk for the PORTEGE R700 and for the SATELLITE R830 have been merged to Linus' tree, closing.