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.
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.
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)
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.
Confirming problem with Fedora 14 on my Toshiba Portege 705.
See discussion here: http://forums.fedoraforum.org/showthread.php?t=254382
Any news regarding this? I'm experiencing this bug in 2.6.38 as well, and I've read of several new reports.
I can confirm the bug with the Toshiba Portégé R830 model (using 2.6.38)
Confirmed with Toshiba Satellite R830, 2.6.38
Same symptoms on Toshiba Portege r835-p50 using 2.6.38/2.6.39
Getting the same here on Toshiba Portégé R830 using 3.0-rc6
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)
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.
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
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.
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).
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.
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.
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
(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
(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.
> - 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
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?
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.
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
"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).
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
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.
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.
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.
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 !
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
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?
Not sure - you'd need to ask the distributions rather than kernel folks probably ?
Freedesktop bug, for fixing the Intel driver: https://bugs.freedesktop.org/show_bug.cgi?id=82634
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
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.
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.
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
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
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
(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".
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.
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
(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
The patches adding the quirk for the PORTEGE R700 and for the SATELLITE R830 have been merged to Linus' tree, closing.