Toshiba Tecra R840 - brightness controls work on first boot, but do nothing after suspend/resume

[James Troup]

Overview -

This bug affects many Toshiba laptops including R700, R705, R800, R830, R835, R840, R850, Z930 models - please update this description if your model is also affected, but make sure the symptoms match exactly.

The symptoms are that brightness control operates normally when the system is first booted, but after a suspend-to-RAM and resume cycle the brightness controls have no effect.

After a normal reboot, or hibernate & resume cycle, the brightness controls operate normally again.

This bug is tracked for the kernel at:

http://bugzilla.kernel.org/show_bug.cgi?id=21012

And for Debian at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599768

Please try to keep all info together and pass any progress to the upstream trackers.

Original report for #935778 follows:

On my Toshiba R840, the brightness controls work fine on first boot,
but do nothing after suspend/resume. This is particularly frustrating
if I suspend with the screen at all dimmed, because once I resume, I
have no way of increasing the brightness short of a reboot.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-generic 3.2.0.16.16
ProcVersionSignature: Ubuntu 3.2.0-16.25-generic 3.2.6
Uname: Linux 3.2.0-16-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: james 2251 F.... pulseaudio
 /dev/snd/pcmC0D0p: james 2251 F...m pulseaudio
CRDA:
 country EU:
  (2402 - 2482 @ 40), (N/A, 20)
  (5170 - 5250 @ 40), (N/A, 20)
  (5250 - 5330 @ 40), (N/A, 20), DFS
  (5490 - 5710 @ 40), (N/A, 27), DFS
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xc4820000 irq 50'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:10ec0269,1179062a,00100100 HDA:80862805,11790001,00100000'
   Controls : 30
   Simple ctrls : 12
Date: Sat Feb 18 21:27:12 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MachineType: TOSHIBA TECRA R840
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-16-generic root=UUID=16b08eff-30c4-4fe0-bede-cf8cb31270bf ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-16-generic N/A
 linux-backports-modules-3.2.0-16-generic N/A
 linux-firmware 1.69
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
StagingDrivers: mei
UpgradeStatus: Upgraded to precise on 2012-01-09 (39 days ago)
dmi.bios.date: 07/12/2011
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 2.90
dmi.board.asset.tag: 0000000000
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion2.90:bd07/12/2011:svnTOSHIBA:pnTECRAR840:pvrPT42GE-00N006EN:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: TECRA R840
dmi.product.version: PT42GE-00N006EN
dmi.sys.vendor: TOSHIBA

[Kaelinphilipp (kaelinphilipp)]

Created an attachment (id=445026)
dmesg

User-Agent: Opera/9.80 (X11; Linux x86_64; U; de) Presto/2.9.168 Version/11.50

After a fresh restart the adjustment of the lcd brightness works correctly. After putting the system to suspend this won't work. Also after a second time putting to suspend it won't work.

Reproducible: Always

Steps to Reproduce:
1. Restart if you've done a suspend recently.
2. Try Adjusting brightness (on my Notebook using Fn+F6/F7), this should work.
3. Put the system to suspend mode.
4. Wake up the system from suspend and try the steps named in 2 again
Actual Results:
In both cases (before and after suspend) the KDE brightness widget is shown correctly but brightness won't change after suspend.

Expected Results:
Adjusting brightness should work like after a fresh restart.

System:
Toshiba Tecra R850-11M
openSuse 11.4 / 2.6.37.6-0.7-desktop / KDE 4.7

The actual state is also after a suspend shown correctly in the following file:

cat /proc/acpi/toshiba/lcd
brightness: 5
brightness_levels: 8

When adjusting the brightness using the keys the value in the file above is actualized corrctly.

In /var/log/messages and dmesg (also as attachment) the following line appears:
Aug 9 20:38:02 linux-h81p kernel: [ 899.913018] ACPI: Failed to switch the brightness

[Kaelinphilipp (kaelinphilipp)]

This Problem also exist in Vanilla-Kernel
# uname -a
Linux linux-h81p.site 3.1.0-rc4-131-g9e79e3e-1-vanilla #1 SMP Wed Aug 31 06:01:54 UTC 2011 (e100209) x86_64 x86_64 x86_64 GNU/Linux

[Kaelinphilipp (kaelinphilipp)]

Created an attachment (id=450630)
/var/log/pm-suspend.log

Linux linux-h81p.site 3.0.4-43-desktop #1 SMP PREEMPT Wed Aug 31 09:30:44 UTC 2011 (a432f18) x86_64 x86_64 x86_64 GNU/Linux

[Kaelinphilipp (kaelinphilipp)]

To find the problem I attached the file /var/log/pm-suspend.log. I also found out, that this machine is not known by s2ram, although suspend works except the screen brightness.

# /usr/sbin/s2ram -n
  Machine unknown
  This machine can be identified by:
      sys_vendor = "TOSHIBA"
      sys_product = "TECRA R850"
      sys_version = "PT525E-00D00SS4"
      bios_version = "Version 3.00 "
  See http://en.opensuse.org/SDB:Suspend_to_RAM for details.

By the way to things:
1) Because I have 8GB RAM and an SSD Harddrive I have no SWAP Partition, but by my side this shouldn't be a problem.

2) As described here (http://memebeam.org/toys/ToshibaAcpiDriver) I tried to edit /proc/acpi/toshiba/lcd manually using the following command:
  # sudo echo "brightness:4" > /proc/acpi/toshiba/lcd
But also with sudo rights I can not write to the file, the error message says "bash: /proc/acpi/toshiba/lcd: Keine Berechtigung" even tough I should have rights for sudo
  # -rw-r--r-- 1 root root 0 14. Sep 11:19 lcd

[Jim (jim-redhat-bugs)]

Description of problem:
Screen cannot be brightened or dimmed after suspend.

Version-Release number of selected component (if applicable):
?

How reproducible:
Suspend, then resume. After resume, neither function buttons nor screen setting in gnome will allow screen brightness to be changed.

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:
Computer: Toshiba Portege Z830

Specifics:
[jim@toshiba ~]$ uname -r
3.1.1-2.fc16.i686
[jim@toshiba ~]$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

[Kaelinphilipp (kaelinphilipp)]

Created an attachment (id=471331)
Files in /sys/containig bright and their values

[Kaelinphilipp (kaelinphilipp)]

I loked in /sys/ for all files containing the value "bright". Then I changed the brightness of the screen using the Keys Fnn+F6/F7 and watched for the changes in the files. The tabular is in the attached file:"Files in /sys/containig bright and their values"

I mentioned that the value of /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/actual_brightness is always constant after a suspend. Before the suspend it changed.

To change the brightness after suspend I did the following:

#su
#echo 320 > /sys/class/backlight/intel_backlight/brightness

Now the file
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/actual_brightness

contains the same value as given in the above comand and display brightness is really changed.

I tested this with 3.1.0-1.2-desktop and 3.2.0.6449 Vanilla. On both this workaround works fine to change brightness, but the keys Fn+F6/F7 are stil not working.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[James Troup (elmo)]

Still present:

Linux ornery 3.2.0-17-generic #26-Ubuntu SMP Fri Feb 17 21:35:49 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[James Troup (elmo)]

FWIW, Seth mentioned this patch when I talked to him on IRC about this bug,
but he says it would need work.

http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/2616

[Seth Forshee (sforshee)]

It's hard to tell much from your ACPI tables, essentially they just seem to be handing everything off to the embedded controller. We'll have to experiment a little.

If you look in /sys/class/backlight you'll have a directory for each of the backlight interfaces available on your system. You should see at minimum one named acpi_video0, and probably another one named toshiba. In each directory there will be files named brightness and max_brightness, among others. The allowed range of brightness values are 0 to max_brightness, and you can change the brightness by writing one of these values to the brightness file (as root).

Can you tell me what interfaces you see in /sys/class/backlight, and try writing values to the brightness file to see which of them work after a fresh boot (i.e. without any suspend/resume)? Then do a suspend resume and test them again. Let me know which of them work before the suspend and whether or not any of them work after the suspend. Thanks!

[James Troup (elmo)]

Seth Forshee <email address hidden> writes:

> It's hard to tell much from your ACPI tables, essentially they just seem
> to be handing everything off to the embedded controller. We'll have to
> experiment a little.

[...]

On first boot.

| root@ornery:/sys/class/backlight# ls -l
| total 0
| lrwxrwxrwx 1 root root 0 Feb 21 18:33 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
| lrwxrwxrwx 1 root root 0 Feb 21 18:33 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
| lrwxrwxrwx 1 root root 0 Feb 21 18:33 toshiba -> ../../devices/LNXSYSTM:00/device:00/TOS6208:00/backlight/toshiba
| root@ornery:/sys/class/backlight#

Default levels (maximum brightness) after first boot:

| root@ornery:/sys/class/backlight# for i in *; do for j in brightness actual_brightness max_brightness; do echo -n ${i}/${j}: ; cat ${i}/${j}; done; echo; done
| acpi_video0/brightness:7
| acpi_video0/actual_brightness:7
| acpi_video0/max_brightness:7
|
| intel_backlight/brightness:4539
| intel_backlight/actual_brightness:4539
| intel_backlight/max_brightness:4539
|
| toshiba/brightness:7
| toshiba/actual_brightness:7
| toshiba/max_brightness:7
|
| root@ornery:/sys/class/backlight#

After pressing 'Fn-F6' (decrease brightness):

| root@ornery:/sys/class/backlight# for i in *; do for j in brightness actual_brightness max_brightness; do echo -n ${i}/${j}: ; cat ${i}/${j}; done; echo; done
| acpi_video0/brightness:5
| acpi_video0/actual_brightness:5
| acpi_video0/max_brightness:7
|
| intel_backlight/brightness:4539
| intel_backlight/actual_brightness:2723
| intel_backlight/max_brightness:4539
|
| toshiba/brightness:7
| toshiba/actual_brightness:5
| toshiba/max_brightness:7
|
| root@ornery:/sys/class/backlight#

I put the brightness back to maxmium, and then suspended and resumed. I
then tried 'Fn-F6' (decrease brightness) again:

| root@ornery:/sys/class/backlight# for i in *; do for j in brightness actual_brightness max_brightness; do echo -n ${i}/${j}: ; cat ${i}/${j}; done; echo; done
| acpi_video0/brightness:5
| acpi_video0/actual_brightness:5
| acpi_video0/max_brightness:7
|
| intel_backlight/brightness:4539
| intel_backlight/actual_brightness:4539
                                    ^^^^
| intel_backlight/max_brightness:4539
|
| toshiba/brightness:7
| toshiba/actual_brightness:5
| toshiba/max_brightness:7
|
| root@ornery:/sys/class/backlight#

Interesting, let's try setting that manually:

| root@ornery:/sys/class/backlight# echo 2723 > intel_backlight/brightness

And the brightness decreases...

| root@ornery:/sys/class/backlight# for i in *; do for j in brightness actual_brightness max_brightness; do echo -n ${i}/${j}: ; cat ${i}/${j}; done; echo; done
| acpi_video0/brightness:5
| acpi_video0/actual_brightness:5
| acpi_video0/max_brightness:7
|
| intel_backlight/brightness:2723
| intel_backlight/actual_brightness:2723
| intel_backlight/max_brightness:4539
|
| toshiba/brightness:7
| toshiba/actual_brightness:5
| toshiba/max_brightness:7
|
| root@ornery:/sys/class/backlight#

Please let me know if this is enough, or if you need more information.

--
James

[Seth Forshee (sforshee)]

It would be useful to test each individual interface before and after resume by writing directly to the brightness files in sysfs to see which work and which don't at any point in time.

Based on the first time you pressed Fn+F6 it looks like acpi_video0 is being used to adjust brightness, since it's the one that shows a change in the brightness file (this one reads a cached value, whereas actual_brightness forces the driver to go and read the brightness). Interestingly, before you suspend acpi_video0 reports the brightness as 5, then after you resume and press Fn+F6 again it still says 5, as though no value was written. If you write values manually to acpi_video0/brightness, does the brightness change, and do the values in brightness and actual_brightness change? Does anything interesting show up in dmesg?

It's interesting too that intel_backlight/brightness has reset to 4539 after resume. Does the screen brightness appear to be at maximum or at the value it was when you suspended? There can be a bit of a problem of coordination between platform and graphics card backlight interfaces, which may account for the difference here.

I'll get you a build tomorrow with a cleaned-up version of that patch for you to try. If it works okay for you I'll try to distribute it for broader testing to see whether or not it breaks any other machines.

[Seth Forshee (sforshee)]

I've put together some changes to toshiba_acpi based on my best guess as to what's needed to fix this problem. Please install the dkms package linked to below, then run "sudo modprobe -r toshiba_acpi; sudo modprobe toshiba_acpi" to reload the driver. Please let me know whether or not /sys/class/backlight/toshiba is still present, and test the various backlight interfaces as described in #5 before and after suspend to see if they work.

Also, _before_ installing the driver, can you test the toshiba backlight interface by writing directly to its brightness file? It will be helpful to know whether or not it works with the current driver.

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201202221517_all.deb

[jowi (jowi)]

My Tecra R840 shows the exact symptoms as described before. I'm on precise with all current updates (Linux brahms 3.2.0-20-generic #32-Ubuntu SMP Thu Mar 22 02:22:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux).

With and without Seth' patched driver from #8 (Thanks, Seth, for your fine work. I already appreciated your alps patch while on oneiric.) I'm able to manipulate the brightness files of all three interfaces under /sys/class/backlight (acpi_video0, intel_backlight, toshiba). Before suspend the display respects all these changes and sets the brightness accordingly. After resume changes in acpi_video0 and toshiba are ignored, changes in intel_backlight still effectively change the brightness of the display. This is what I currently use as workaround by means of the little script attached, which translates the different values of intel_backlight and acpi_video0/toshiba.

With Seth' driver installed my Tecra freezes on suspend or the backlight stays off on resume. Before suspend I recognized that changing the brightness via Fn-F6/7 uses all 8 levels, whereas without the patched driver one keystroke always takes two at a time. AFAICT the logs don't give any hint.

[Seth Forshee (sforshee)]

jowi: Thanks for providing your test results. Can you clarify what you mean by, "freezes on suspend or the backlight stays off on resume"? Do you mean that sometimes one happens, and sometimes the other, or that you just can't tell which is happening. The driver has quite a few changes besides just those for the backlight, so if it's really hanging on suspend it may or may not be related to the attempted fix for the backlight.

[jowi (jowi)]

@Seth: Sorry for not having been clear enough.

Without your patched driver:

Suspend and resume work out of the box when suspend is initiated via panel menu entry and without closing the lid. When I suspend by closing the lid I have to disable the "lock screen after screen turns off" setting, otherwise the backlight stays off after resume.

Before suspend I can change the brightness by directly putting some value into the brightness file of any of the three interfaces under /sys/class/backlight. After resume this only works with the brightness file of the intel_backlight interface.

With your driver:

Suspend is successful when initiated via lid close. But after resume the backlight stays off, even with the above mentioned "lock screen" setting disabled. But besides that, the resume seems to be successful. I can blindly switch to console, log in and shutdown. Yet I couldn't manage to get the backlight back on without reboot. Switching to console and back or vbetool dpms on/off cycles didn't help.

When I try to suspend via menu entry the system locks up. The backlight stays on with blank screen and the fan starts running at high speed. Even the magic SysRq key as last resort withholds support. I have to hard power-off the machine. The logs (dmesg, syslog, pm-suspend, Xorg) don't show any failure entries.

Before suspend all three interfaces in /sys/class/backlight are still present and the display brightness still changes when writing directly to any of their brightness files. In the case of the backlight staying off after resume I also tried blindly writing to the brightness files. But the backlight stayed off, so I can't tell whether the brightness would have changed. Of course seeing nothing but a blank screen there is certain possibility that I instead posted all my hidden secrets to Launchpad.

I tested this several times and the behaviour is reproducable. With your driver the system either locks up on soft suspend or the backlight stayes off on resume after lid close suspend.

[Seth Forshee (sforshee)]

Thanks for clarifying. I have a new package that strips out the backlight changes but keeps in the others, so we can see what's causing your suspend regression. Please let me know whether you still see the suspend issues with this build. Thanks!

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201203272119_all.deb

[jowi (jowi)]

Thanks for the new build. With this version of the module my Tecra suspends and resumes successfully again. Before suspend pressing Fn-F6/7 still changes the brightness in all 8 steps as implied by the toshiba interface. Besides that, I didn't recognize any other obvious difference against the unpatched original version of the Precise kernel.

[Seth Forshee (sforshee)]

Bug 962142 reports a suspend problem with the R840, so the changes you're testing may also have nothing to do with the suspend problem, or may only affect it indirectly (e.g. changes the timing of suspend to make the problem more prevalent).

[Seth Forshee (sforshee)]

I've put up a new test build. I'm slowly reintroducing the backlight changes. I expect this one to have no functional impact for you; it should only affect models that can't change the backlight settings via toshiba_acpi. Please test and see if you notice any regressions from the last build. Thanks!

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201203280920_all.deb

[jowi (jowi)]

The Tecra R840 affected by bug #962142 has an ATI graphics card and uses the proprietary fglrx module, whereas James', who opened this bug here, and mine have Intel processor graphics, which might also make at least partly the difference between suspend failure and success. Of course that's just a guess. Indeed the error description in bug #962142 is very similar to what I could notice when my machine locked up on suspend.

As you predicted with your new version from comment #15 suspend and resume still works and there is no noticeable difference against the version before from comment #12. Thanks for your continuous efforts.

[Seth Forshee (sforshee)]

Good. Now for the next test build. What I did this time was add a new file:

  /sys/bus/acpi/devices/TOS1900:00/backlight

which I will simply call "the backlight file." This file will let you read and write values directly to the register that is supposed to fix the backlight issues after suspend. This way we can try a variety of things without requiring new builds each time. The build is at:

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201203281156_all.deb

Please start with the following things in order. It's probably a good idea to do this over ssh so you can continue trying things if the backlight turns off.

1. After installing the new driver, reboot. Use cat to read the value of the backlight file after rebooting and let me know what the value is.

2. Write 0 to the backlight file (i.e. echo 0 | sudo tee .../backlight). What happens? Can you change the brigtness via the acpi_video0 and toshiba backlights after doing this?

3. Write 1 to the backlight file. What happens? Can you change the brightness via the acpi_video0 and toshiba backlights after doing this?

4. Write 0 to the backlight file, then suspend and resume. Does either of the methods of suspending cause a hang?

5. Reboot, then suspend and resume the machine. What's the value of the backlight file after resuming?

6. Write 1 to the backlight file. Do either of the acpi_video0 and toshiba backlight interfaces work after doing this?

7. If the backlights do not work after 6, try writing a new brightness to /sys/class/backlight/toshiba/brightness and then writing 1 to the backlight file. Does anything happen?

Feel free to try anything additional that occurs to you. Thanks!

[jowi (jowi)]

I'm sorry, but the backlight file doesn't get created. There is no /sys/bus/acpi/devices/TOS1900:00. To be on the safe side I searched the whole /sys tree, but didn't find any "backlight" file.

[Seth Forshee (sforshee)]

Sorry, I gave you the wrong path for your machine, but there _should_ be a backlight file somewhere if you've got the toshiba_acpi module loaded from the package I supplied. Try /sys/bus/acpi/devices/TOS6208, or if that's not there /sys/bus/acpi/devices/TOS6200.

[Seth Forshee (sforshee)]

Both of the paths in comment #19 should have had :00 at the end. Sorry again.

[jowi (jowi)]

It's TOS6208:00. In there is no "backlight" file, but a "backlight" directory. This contains nothing but the single subdirectory "toshiba", which is the link target of /sys/class/backlight/toshiba. A directory listing is attached.

I hope you understand that I don't want to play with those files without your explicit request. Jonathan Buzzard said on the linux-acpi mailing list "The Toshiba provided Windows user space programs go to some length to establish what models they are running on before attempting any funny business. Over the years a number of users have tried randomly poking the HCI without knowing what they are doing and bricked their laptops. If you understood how the HCI really works under the hood, you would understand. The error checking in it last time I looked is virtually none existent." See http://www.spinics.net/lists/linux-acpi/msg20355.html

[jowi (jowi)]

I recreated the directory listing with LANG=C, because the content-type setting "text/plain; charset=utf-8" doesn't seem to be respected with firefox.

[Seth Forshee (sforshee)]

Hrm, seems the name I picked was a bad choice since a directory gets created with the same name. I'll have to generate a new package with a different name, but I'm not at the machine right now that has the code. I'll post something a little bit later.

[Seth Forshee (sforshee)]

Okay, I changed the name to hci_backlight. Please try the build below.

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201203282134_all.deb

[jowi (jowi)]

Thanks again. The value of hci_backlight is 1 after a fresh boot and 0 after supend and resume. I can't change it by writing to the file. "echo 0 | sudo tee hci_backlight" yields "tee: hci_backlight: Invalid argument". Same result with "echo 1 ...".

[Seth Forshee (sforshee)]

Doh, silly logic error reading the value being written. That's why it's helpful when you're able to test your code :)

Fixed, please try the package below. It's useful to know that the value is reset to 0 after suspend, and it will be interesting to see whether simply writing 1 gets both the acpi_video0 and toshiba backlights working again. If they aren't working after you write 1 to hci_backlight, be sure to check whether or not the value it reads is still 1.

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201203291004_all.deb

[jowi (jowi)]

I'm afraid it's not that easy. The machine locks up immediately when writing to hci_backlight as with your first patched version from comment #8 on soft suspend. Regardless of whether I try to write a value of 0 after boot or 1 after suspend and resume. Not a single line in the logs, it looks like a sudden death.

[Seth Forshee (sforshee)]

So as I understand your comment the machine is locking up any time you try to write 0 or 1 to hci_backlight. Is that correct? If so, this isn't looking very promising.

Just fyi, the process of what happens when HCI_BACKLIGHT is written is completely opaque to us. The actual operations are handled by the computer's embedded controller, and we can't really see what it's doing. Writing 1 to HCI_BACKLIGHT has been reported to work on some machines, but if it turns out to be problematic on this one we may be stuck.

[jowi (jowi)]

To be exact, I tried to write 1 when the value was 0 and vice versa. In both cases the machine locked up.

I already read a bit about the problem on the net, so I think I have a basic idea of what you mean about the problem behind.

Albeit not satisfying, at least the intel_backlight interface works after resume, and I usually don't change the brightness every few minutes. Therefore I can live with the workaround mentioned. Furthermore I tried to work around with the acpi_backlight=vendor kernel parameter. To my surprise with this parameter set intel_backlight seems to be used behind the scenes when the Fn-F6/7 keys are pressed. But after resume the backlight stayed off, hence I don't followed this approach any further.

Thank you once again.

[Seth Forshee (sforshee)]

jowi: I've got one more build I'd like you to try, if you don't mind. This is a technique that some people have reported as working, writing 1 to HCI_BACKLIGHT right after setting the brightness level. It may well lock up your machine like the other attempts, but I'd like to at least try it before giving up. Thanks!

http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-dkms_0.6~lp935778v201203291607_all.deb

[jowi (jowi)]

Thanks, great! The machine suspends and resumes without failure. And after resume the display brightness can now be changed by writing to the toshiba interface's brightness file. The brightness file of acpi_video0 still doesn't work after resume, what probably causes the Fn-F6/7 keys to not work either. A lesser problem? In any case, a definite progress.

I'll be glad to do more testing tomorrow. For today I'm away now.

[Seth Forshee (sforshee)]

That's very puzzling. It's good that it works, but I don't understand the difference in behavior.

I'll think about it a little more, but right now I can't think of anything else to test that will make a practical difference. It seems like there ought to be a better way to fix this after suspend, something that gets acpi_video0 working as well, but as of right now I don't have any idea what that would be.

[jowi (jowi)]

I don't know whether it may be helpful or even makes things more complicated, I had another look to the values of the brightness and actual_brightness files of the acpi_video0, toshiba and intel_backlight interfaces under /sys/class/backlight, and how they change when writing to it. A little script and its output are attached.

The results show that before suspend as well as after resume the actual_brightness files of acpi_video0 and toshiba respect the changes in the brightness files of each other. The difference to be observed is the behaviour of the actual_brightness file of intel_backlight. Before suspend it respects the changes of both other interfaces' brightness files, whereas after resume it respects only the changes of the toshiba one. By the way, that's exactly what's new with your latest version of the module. With the unpatched module after resume it doesn't respect the changes of toshiba/brightness either.

It could be concluded that the actual brightness of the display is neither represented by the value of acpi_video0/actual_brightness nor toshiba/actual_brightness, but the value of intel_backlight/actual_brightness. Before suspend it is modified by changes of acpi_video/brightness, after resume this fails. The Fn-F6/7 keys seem to modify the acpi_video0 interface only.

Perhaps all this was obvious the whole time and I didn't realize it, but doesn't the solution have to be searched in keeping the connection between modifications of acpi_video0/brightness and the thereby changed values of intel_backlight/actual_brightness over a suspend/resume cycle? With your patched module it is no longer broken between toshiba/brightness and intel/actual_brightness. But the system tools and hardware keys apparently only read and change the acpi0_video interface.

Please feel free to modify the script, if I should post further results.

[jowi (jowi)]

I couldn't manage to post three attachments in one comment. So here comes the output before suspend.

[jowi (jowi)]

And the output after resume.

[jowi (jowi)]

Oh, and I forgot something that could be of interest: I had to insert a short sleep after modifying the brightness files before reading the value of intel_backlight/actual_brightness. It seemed to need a little amount of time before it reached its new value.

[Seth Forshee (sforshee)]

jowi: I've got one more thing I'd like for you to test, if possible. It's a bit of a guess based off of an observation, but I'd like to know if it makes a difference.

Please remove toshiba-acpi-dkms and install the kernel from the link below. Then reboot and see if there's any change in the backlight behavior following suspend. Thanks!

http://people.canonical.com/~sforshee/lp935778/linux-3.2.0-22.35~lp935778v201204041419/

[jowi (jowi)]

Thanks! I'm afraid, with this patched kernel there isn't any noticeable difference against the standard precise one. After suspend and resume the acpi_video0 and toshiba interface still respect writing to each other's brightness file, respectively, whereas intel_backlight/actual_brightness still exclusively honors the changes of its own brightness file, but doesn't respond to changes in neither of the two other interfaces.

[Seth Forshee (sforshee)]

And I assume that writing to the acpi_video0 and toshiba brightness files still has no effect on the screen brightness with the kernel from comment #37?

[jowi (jowi)]

Yes, after resume the screen brightness can only be changed by writing to intel_backlight/brightness, not by writing to the respective brightness file of either of the two other interfaces.

[Seth Forshee (sforshee)]

Thanks. I'll study the DSDT a bit more to see if I can identify anything else worth trying. There _must_ be some way to get everything working after S3 like it was before ...

[Martin Ling (martin-launchpad)]

Seth & Jowi, well done on your progress with this bug which I have been tracking for a while on duplicate reports. Since you have the most progress on the problem I have merged the various reports into this one and updated the title & description to reflect the various models affected.

Seth, there are some attempted patches & results in the linked kernel & Debian bug reports that might be useful to you if you've not already seen them. Also if you could pass your own patches & results upstream (particularly the code beind the working kernel in comment #30), some of the others tracking those reports might have ideas on finishing the job.

[Seth Forshee (sforshee)]

Martin: Thanks for gathering all the data.

I'm hesitating on the solution from comment #30 because writing to HCI_BACKLIGHT seems to sometimes cause the machine to lock up, and because it's only a partial fix (acpi_video backlight still doesn't work). I'm hoping we can do better, when I have a little more time to look into this. Fwiw, most of the solutions posted on the other bug trackers are variations of what I used in comment #30.

[Martin Ling (martin-launchpad)]

Jowi wrote in comment #29:
"I tried to work around with the acpi_backlight=vendor kernel parameter. To my surprise with this parameter set intel_backlight seems to be used behind the scenes when the Fn-F6/7 keys are pressed. But after resume the backlight stayed off, hence I don't followed this approach any further."

Actually it seems that following this approach just a little further yields a passable solution.

It seems that with acpi_backlight=vendor the backlight is off after a suspend, but it can be turned back on by writing to /sys/class/backlight/toshiba/brightness, and then everything works normally again.

To all those suffering from this bug: there are instructions at http://www.linlap.com/wiki/toshiba+portege+z830-10f that explain how to enable the acpi_backlight=vendor option and set things up with a script that restores the backlight on resume. This fixes the problem for me on my R830.

[Seth Forshee (sforshee)]

Martin: The instructions you linked to work without the HCI_BACKLIGHT patch to the kernel? Interesting. Have you tried it without passing acpi_backlight=vendor to see if the acpi backlight works as well? What about writing values other than 7?

The way that toshiba_acpi currently handles the backlight ends up with something virtually identical to what the bios is doing when the backlight is changed via the acpi_video backlight interface, at least on the Tecra R840. So it would be interesting to try doing the same thing with the script, but using the acpi_video0 backlight instead.

[jowi (jowi)]

Martin: With acpi_backlight=vendor and writing to toshiba/brightness after resume the backlight actually turns on, but leaves me with an empty screen. Xorg shows the following log entries:

[ 211.813] (WW) intel(0): flip queue failed: Invalid argument
[ 211.813] (WW) intel(0): Page flip failed: Invalid argument

I can change to a still working console and back to X, but X stays blank. By killing X I get back a working X server. The Fn-F6/7 keys still manipulate the intel_backlight interface and the screen brightness is changed thereby.

Seth: Without acpi_backlight=vendor nothing has changed. There isn't any difference between writing to toshiba/brightness manually or by script. The behaviour of the three interfaces is the same as before, see comment #33.

[Aaron Taylor (aaronfacetaylor)]

Hiya,

Just confirming that the fix suggested in #50 works in Fedora 16 kernel 3.3.5-2.x86_64, so I'm guessing it'll work in Ubuntu also.

Can't thank you guys enough for exploring this one; been a real headache for me and I'm nowhere near knowledgeable enough to even begin to attempt to fix it.

[Luke Scharf (lukescharf)]

Wohoo! I'll give a post 3.3.5 PPA a try when I get a chance, and report back.

[Luke Scharf (lukescharf)]

It's still broken for me.

Running the following pre-release kernel: Linux version 3.4.0-030400-generic (apw@gomeisa) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) ) #201205210521 SMP Mon May 21 09:22:02 UTC 2012

Obtained from here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/

Toshiba R835-P56X

[Luke Scharf (lukescharf)]

Oops, I forgot to add the acpi_backlight=vendor kernel parameter. I'm now seeing the same behavior as everyone else, with the above configuration.

[luca (llucax)]

Here is a nice resource of workarounds for toshiba z830:
http://www.linlap.com/wiki/toshiba+portege+z830-10f

[amirhoshangi (amirhoshangi)]

I have Toshiba Satellite R630, and this BUG is really bothering.

[amirhoshangi (amirhoshangi)]

I compiled all the latest patches for toshiba_acpi.c but no success. When this BUG's going to be closed ?

[Tom (tom-redhat-bugs)]

Hi

I can second that!

Got the same model and same issue.

In case Fedora-crew need some system output, let me know.

Thanks!

Tom

[Tom (tom-redhat-bugs)]

Hmm

I can see I were a bit too fast - I use an up-to-date Fedora 17.
Got the latest Intel graphics drivers 2.20.7-1.fc17 32bit.

Cheers!

[Felix Vollmer (felixvollmer)]

Bug still exists under 3.6 rc6. (tested with z930)

[Abhinay Mukunthan (lexxonnet)]

I tried the workaround suggested in #57, and it doesn't work on an R840 using Quantal. Not sure if anyone else has had luck on any other laptop on Quantal.

[Marc Tommasi (marc-tommasi)]

I have the same problem with portege Z930 with quantal (amd64). A workaround is to do as root

cd /sys/class/backlight/intel_backlight
echo some_value > brightness

with some_value an integer lower than 4539.

[MaTachi (matachi)]

I'm experiencing the same bug on my Toshiba R830-13D, running Ubuntu 12.10. The workaround suggested in #57 worked for me.

[camden lindsay (camden-lindsay+launchpad)]

Comment/link in #57 worked for me on my Portege r705-P25

[nfsd (in4mer+launchpad)]

Toshiba portege M400 here,

3.5.0-21-generic #32-Ubuntu SMP

Brightness keys stop working after suspend/resume, first time. However, in a departure from others' observed behavior, my backlight/toshiba/brightness controls work. When the system is running after a resume, the 'brightness' value is '7', no matter what the screen dimness actually is. But, if you echo '7' >brightness, or any other number for that matter, the brightness changes immediately, and that brightness file does reflect the value that the brightness was set to.

HTH. Sure seems like toshibas have been the redheaded stepchild of motherboard feature support since they stopped compiling toshiba support into the default kernels.

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Fedora (fedora-redhat-bugs)]

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Matthieu TC (matthieutc)]

I am experiencing the same problem. I'm on a Dell XPS ultrabook with the Dell Sputnik PPAs. In my case, I hibernate the computer (I do not suspend) bu the symptoms are the same.

Also, after coming back from hibernation, the bluetooth widget shows that bluetooth is enabled even though I had disabled it before going into hibernation.

# uname -a
Linux hostname 3.2.0-38-generic-pae #61+kamal14~DellXPS-Ubuntu SMP Fri Feb 22 20:53:54 UTC 2013 i686 i686 i386 GNU/Linux

[doeus (doeus)]

This proposed solution worked for me:

### SYSTEM INFO ###
# Model: Toshiba SATELLITE R830
# Kernel: 3.5.0-23-generic x86_64
# OS: Ubuntu 12.10 quantal

### KERNEL PARAMETER ###
$ grep vendor /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_backlight=vendor"

### SCRIPT ###
#!/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

[cmtsij (cmtsij)]

I try to write a udev script to workaround.
When user press Fn-F6 or Fn-F7, a uevent would be generated from acpi_video0.
I wrote a udev rule to hook this uevent to config intel_backlight brightness.

diff --git a/etc/udev/rules.d/00-tosh-backlight.rules b/etc/udev/rules.d/00-tosh-backlight.rules
new file mode 100644
index 0000000..dd38aa2
--- /dev/null
+++ b/etc/udev/rules.d/00-tosh-backlight.rules
@@ -0,0 +1 @@
+DEVPATH=="*/acpi_video0", SUBSYSTEM=="backlight", ACTION=="change", RUN+="/etc/udev/rules.d/tosh-backlight.sh"
diff --git a/etc/udev/rules.d/tosh-backlight.sh b/etc/udev/rules.d/tosh-backlight.sh
new file mode 100755
index 0000000..c7dc5b2
--- /dev/null
+++ b/etc/udev/rules.d/tosh-backlight.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+acpi_max=$(cat /sys/class/backlight/acpi_video0/max_brightness)
+acpi_curr=$(cat /sys/class/backlight/acpi_video0/brightness)
+intel_max=$(cat /sys/class/backlight/intel_backlight/max_brightness)
+intel_curr=$(($intel_max*$acpi_curr/$acpi_max))
+echo $intel_curr > /sys/class/backlight/intel_backlight/brightness

[Klaus Wölfel (k-woelfel)]

Thanks, cmtsij. This is the only solution which works for my Toshiba Z960 on kernel 3.8.0-16-generic.

[Klaus Wölfel (k-woelfel)]

In the recent ubuntu 13.04 Beta 2, /sys/class/backlight/acpi_video0 did not exist anymore on my toshiba satellite Z930 (acpi_backlight=vendor is NOT set). Therefore I had to change the udev script proposed by @cmtsij like this:

diff --git a/etc/udev/rules.d/00-tosh-backlight.rules b/etc/udev/rules.d/00-tosh-backlight.rules
new file mode 100644
index 0000000..dd38aa2
--- /dev/null
+++ b/etc/udev/rules.d/00-tosh-backlight.rules
@@ -0,0 +1 @@
+DEVPATH=="*/toshiba", SUBSYSTEM=="backlight", ACTION=="change", RUN+="/etc/udev/rules.d/tosh-backlight.sh"
diff --git a/etc/udev/rules.d/tosh-backlight.sh b/etc/udev/rules.d/tosh-backlight.sh
new file mode 100755
index 0000000..c7dc5b2
--- /dev/null
+++ b/etc/udev/rules.d/tosh-backlight.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+acpi_max=$(cat /sys/class/backlight/toshiba/max_brightness)
+acpi_curr=$(cat /sys/class/backlight/toshiba/brightness)
+intel_max=$(cat /sys/class/backlight/intel_backlight/max_brightness)
+intel_curr=$(($intel_max*$acpi_curr/$acpi_max))
+echo $intel_curr > /sys/class/backlight/intel_backlight/brightness

[manmi (tic)]

Just got a Z930 and cannot change display brightness at all.

Set acpi_backlight=vendor in /etc/default/grub which resulted in displaying a widget that shows the "current" setting for display brightness and the change when I press FN-F6 or FN-F7 but the display itself remains at full power.

Creating /etc/udev/rules.d/00-tosh-backlight.rules and resulted in a black screen at login that I could not change at all.

Runninng Kubuntu 13.04 with latest updates as of today:
Linux mamo 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Mathieu Poussin (kedare)]

Same problem on Tosihba R930.
Looks like it don't only affects brighness, but after a first sleep/resume , it won't sleep again or shutdown properly (just shutdown the hard drive but not the computer)
Do you also have the same issue ?

[penalvch (penalvch)]

James Troup, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

[Swesemeyer (swesemeyer)]

Hi,

I have exactly the same problem on my Toshiba Satellite R830.

This is with a fully up-to-date Opensuse 12.3.

The solution in comment 5 restores the brightness but the function keys still don't work (well they do show the "on-screen brightness display" changing but with no effect on the actual brightness).

Using (as root)
echo 4539 > /sys/class/backlight/intel_backlight/brightness

restores my screen to its full brightness and passing different lower values dims the screen.

Is there anything that we can check to figure out what causes this to stop working after a suspend?

[Swesemeyer (swesemeyer)]

Actually, I just found the bug report at

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778

which links to

https://bugzilla.kernel.org/show_bug.cgi?id=21012

and comment #19 worked for me (although now the minimum brightness is absolute darkness but at least the FN-keys work)

[luca (llucax)]

Hi, I improved the /etc/udev/rules.d/tosh-backlight.sh script as presented in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778/comments/68, this script avoids the no-backlight at all issue and sets the brightness using a quadratic function (it works much better in my Z830 where the lower brightness jumps are very big).

#!/bin/sh
acpi_max=$(cat /sys/class/backlight/toshiba/max_brightness)
acpi_curr=$(cat /sys/class/backlight/toshiba/brightness)
intel_max=$(cat /sys/class/backlight/intel_backlight/max_brightness)
intel_min=100 # What we want the brightness 0 to be
# Linear
#intel_curr=$((($intel_max-$intel_min)/$acpi_max*$acpi_curr+$intel_min))
# Cuadratic
intel_curr=$(echo "scale=10; ($intel_max-$intel_min)/($acpi_max^2)*$acpi_curr^2+$intel_min" | bc | cut -d. -f1)
echo $intel_curr > /sys/class/backlight/intel_backlight/brightness

[penalvch (penalvch)]

luca, in order to track your hardware, could you please file a new report via a terminal:
ubuntu-bug linux

[Ohering-l (ohering-l)]

This may now work in Tumbleweed

[penalvch (penalvch)]

Patches addressing this issue for various models was released upstream in 2016.