Toshiba R835-P56X - screen brightness control does not work after suspend/resume

[Luke Scharf]

Toshiba R835-P56X - screen brightness control does not work after suspend/resume. It works just fine before suspend/resume. After suspend/resume, the dbus (or whatever) indicator shows the brightness slider-bar changing, but the screen brightness doesn't actually change.

Restarting acpid or acpi-support doesn't make any difference. Only workaround that I've found so far is to reboot the machine.

I'll be happy to perform any tests that you all can suggest, as well as provide more/deeper debugging information. I've been a Linux user/sysadmin since 1998, and I'm proficient in programming/development -- but I'm mostly unfamiliar with the acpi and Linux's implementation of it.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: acpi-support 0.138
Uname: Linux 2.6.39-02063904-generic x86_64
Architecture: amd64
Date: Tue Aug 23 22:12:11 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: acpi-support
UpgradeStatus: No upgrade log present (probably fresh install)
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: lukescharf 980 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xc4820000 irq 49'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:10ec0269,1179062e,00100100 HDA:80862805,11790001,00100000'
   Controls : 17
   Simple ctrls : 9
DistroRelease: Ubuntu 11.04
HibernationDevice: RESUME=UUID=7c62d4f9-0ff6-4fc6-9666-2f70193d0c45
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
MachineType: TOSHIBA PORTEGE R835
Package: linux (not installed)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-generic root=UUID=d046bba5-6bff-42e7-ae6e-afcab4507acb ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 2.6.38-11.48-generic 2.6.38.8
RelatedPackageVersions:
 linux-restricted-modules-2.6.38-11-generic N/A
 linux-backports-modules-2.6.38-11-generic N/A
 linux-firmware 1.52
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
Tags: natty
Uname: Linux 2.6.38-11-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 08/06/2011
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 3.00
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:bvrVersion3.00:bd08/06/2011:svnTOSHIBA:pnPORTEGER835:pvrPT324U-008003:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: PORTEGE R835
dmi.product.version: PT324U-008003
dmi.sys.vendor: TOSHIBA

[Steve Langasek (vorlon)]

acpid and acpi-support aren't supposed to be involved in handling such events. Reassigning to the kernel.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 832483

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

apport information

[Luke Scharf (lukescharf)]

I'm able to reproduce this bug with both Natty's stock 2.6.38-11-generic kernel, as well as with the 2.6.39-02063904-generic kernel fron oneiric that I need to run in order to prevent random lockups. (I've filed a sperate bug report for that one.)

I ran apport-collect with the stock kernel for this report. I also put the computer through a sleep/wake cycle and attempted to ajust the screen brightness before running apport-collect, in the hopes that something worthwhile would show up in the logs. I'll be happy to run apport-collect on a freshly-booted machine, if it looks like that will be a helpful reference.

[Luke Scharf (lukescharf)]

I upgraded to Ubuntu 11.10 Beta (Oneiric), and this problem persists with the default kernel.

/proc/version:
Linux version 3.0.0-10-generic (buildd@allspice) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-7ubuntu2) ) #16-Ubuntu SMP Fri Sep 2 18:32:04 UTC 2011

dpkg --list | grep linux-image:
linux-image-3.0.0-10-generic

This isn't a surprise, but it's a data-point worth including here.

[Luke Scharf (lukescharf)]

I'd like to dig in to the code for this a bit. I've worked with the kernel a bit in the past, but I don't know where to start on this one. Can anyone point me to the source file(s) for the bottom-layer device driver that is supposed to control the screen brightness on the more-recent Toshiba laptops?

(Once I get oriented, I should be able to figure out the rest from there. Or not. But if I do figure it out, I'll send a patch.)

[Luke Scharf (lukescharf)]

I started reading drivers/platform/x86/toshiba_acpi.c to see if any obvious problems jump out at me. (None so far.) However, one strange thing that I noticed is that, while I can adjust my screen brightness by echoing values to /sys/devices/platform/toshiba_acpi/backlight/toshiba/brightness (when I can adjust the brightness at all), rmmoding toshiba_acpi doesn't have any effect on the operation of the brightness buttons, or on the other brightness files in /sys (/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/brightness, /sys/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/brightness, /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/leds/mmc0::/brightness, /sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/leds/phy0-led/brightness)

Since I can't control the brightness through any of the /sys/*/brightness files after a suspend/resume, I've decided to focus on the kernel side of things and most-ignore the GUI -- the problem must be with this system. But, since the toshiba_acpi module seems to be simultaneously involved and not involved, in setting the brightness, it's clear that I really don't understand how all of the ACPI and other firmware/chipset modules that can control the brightness interact. Can anyone point me to documentation about how this is supposed to work?

Thanks,
-Luke

[Luke Scharf (lukescharf)]

Another bit of trivia: /sys/devices/platform/toshiba_acpi/backlight/toshiba/max_brightness and /sys/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/max_brightness shows that there are 7 possible brightness values (running from 0 through 6 inclusive).

However, when I press the Fn+F6 and Fn+F7 buttons (to lower and raise the brightness), I only count 5 possible brightness levels (when the screen-brightness system is working at all).

Is the GUI supposed to follow the number of brightness levels provided by the kernel?
Some of the other /sys/*brightness* files use different units to measure/control the brightness, so are those the "real" brightness controls?

[Luke Scharf (lukescharf)]

BTW, I've uploaded the requested logs and had some offline dialog about this issue. Can we mark this one as "confirmed"?

(I'm in the process of joining the Bug Squad, so I might be able to mark it "confirmed" myself -- but marking my own bug as "confirmed" seems like a faux pas. At the very least, it seems like it's short-circuiting the review process.)

[bawdo (keith-bawdo)]

I have the exact same issue. Toshiba R731.

Linux R731 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12 22:21:04 UTC 2011 i686 i686 i386 GNU/Linux

[Luke Scharf (lukescharf)]

The problem persists after upgrading the BIOS in my Toshiba R835-P56X to version 3.10.

[Luke Scharf (lukescharf)]

Marked confirmed, since it affects multiple people. I've received offline e-mail from people who haven't participated in the bug discussion here, so this bug appears to be affecting people and two recent varieties of Toshiba laptops.

[Luke Scharf (lukescharf)]

I tried blacklisting the toshiba_acpi module and, while it didn't fix the suspend/resume, it didn't break anything. Also, with toshiba_acpi blacklisted, there are more brightness-notches available -- 7 possible brightnesses instead of 5.

Also, the PPA of kernel 3.1 (as suggested during one of the offline discussions I've had about this bug), does seem to let the CPU run at full speed. (The fan runs faster while the CPU is busy and the machine feels snappier, but idle fan speed is the same.)

[Gibb (capt-gibb)]

Same happens on my new Toshiba Satellite R830 laptops (oneiric)

[Luke Scharf (lukescharf)]

Just updated to version 3.40 of the Toshiba BIOS (http://www.csd.toshiba.com/cgi-bin/tais/support/jsp/download.jsp?soid=3241013).

Despite the changelog saying things like "Implemented the Intel specification for Intel Chipsets to improve stability", I observed no change in behavior -- screen brightness control works before suspend/resume, but it stuck after.

[bawdo (keith-bawdo)]

I am also seeing this issue on my Toshiba R731/38C with an upgraded kernel - 3.0.0-15-generic-pae

Interestingly if I manually turn off the screen wait ten seconds and then turn it back on then the brightness controls work.

sudo vbetool dpms off && sleep 10 && sudo vbetool dpms on

However, after a normal suspend/resume the brightness controls are still fritzed.

[Abhinay Mukunthan (lexxonnet)]

I've got the same issue on the Toshiba Tecra R840. I looked at the following thread: http://ubuntuforums.org/showthread.php?t=1550219 and there was a fix which involved using toshset to turn the backlight on after adjusting the levels.

When typing "toshset -bl on" into the terminal after adjusting the levels as required, the backlight will subsequently change to that level.

Its a temporary fix, but better than nothing. There are also a couple of scripts at the bottom of the page that allow you to bind the brightness-up down keys to the command. However, it doesn't allow gnome/KDE power managers to control the backlight.

[Luke Scharf (lukescharf)]

I've tried that in the past with no success.

It's worth noting that toshset uses a different kernel module than the Ubuntu installer sets up by default. By default, I have the toshiba_acpi.ki module loaded. I've built and installed the correct module for toshset, but it didn't seem to work any better. And I'm hazy enough on how to the low-level acpi kernel parts work together that I wasn't sure if there was some conflict -- there sure are a lot of files throughout /sys and /proc that seem to control the screen brightness before the sleep/resume cycle that fail after the sleep/resume cycle. From reading the webpage from the author of toshset (http://schwieters.org/toshset/), I'm left with the distinct impression that it was obsolete long before my Toshiba R835-P56x was on the drawing board.

Also, upgrading my R835-P56x to version 3.5 of the system BIOS didn't have any effect.

I'd love to delve in to the kernel and fix this myself (I'm programming literate and I've touched read/modified kernel code before), but I can't find the right background reading that describes what I need to know about ACPI in general (the kernel/OS view), Linux's ACPI infrastructure, and Toshiba's ACPI. If someone could point me to the right direction, I'd be happy to give it a go and contribute any code that I come up with. Alas, I don't know where to start and I'm a busy guy so I can't just stare at it until it works, the way I could back when I was a student with nothing but time.

[Luke Scharf (lukescharf)]

(I removed toshset and the related kernel module after proving to myself that it wasn't a solution. My current configuration has just the stock toshiba_acpi module that the Ubuntu installer pulled in.)

[Luke Scharf (lukescharf)]

Still experiencing this after upgrading to Precise with kernel 3.2.0-18-generic.

My day job has been keeping me incredibly busy these last few weeks, so I haven't had a chance to apply the patches referenced above to the kernel modules yet. Trying to keep the big report alive as much as anything. I've had the patches open in a web browser-window for the past month or so, and I'll apply them when I get a chance.

I have been able to get control of the brightness back after some hibernate/resume cycles, but I don't have a pattern yet (or maybe my laptop just sleeps instead of hibernating half the time). I still always loose control of the brightness after sleep/resume cycles.

BTW, the upgrade to Precise was super-smooth! :-)

[penalvch (penalvch)]

Luke Scharf, 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>

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[n3rd (n3rd)]

Yes it is, Toshiba R835 Ubuntu 13.10

[penalvch (penalvch)]

Reset, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs