toshiba_acpi no control of display backlight after suspend to ram

[camden lindsay]

Hello-
toshiba portege r705

After boot, display backlight control works fine.
After suspend to ram (any number of times), backlight control does not work
After suspend to ram, wake, suspend to disk, wake backlight control returns to working state.

When control is not working, on screen display does work -- indicating backlight changing brightness (even though its not)
/proc/acpi/toshiba/lcd changes with button pushes, as expected
/sys/devices/platform/toshiba_acpi/backlight/toshiba/actual_brightness changes with button pushes, as expected
however--
/sys/devices/platform/toshiba_acpi/backlight/toshiba/brightness never changes from 0, even from a fresh boot.

Additionally, the max_brightness=7 and the count starts at 0, but there are only 5 levels when adjusting using control buttons. And even more oddly, when increasing from 0, display_brightness goes like this:
0,2,4,6,7
And when decreasing from 7, it goes like this:
7,5,3,1,0.

Although i think this needs to be filed against a different component, (suggestions?) i thought it might be valid here as well.

[Daniel Smith (connect404)]

I can confirm this issue also affects the Toshiba R700. If this should be filed upstream can someone recommed where?

It seems the hardware power cycle (shutdown or suspend to disk) is the only way to regain brightness control. The toshest util enables changing the brightness and turning off the backlight before a suspend to ram, but after resuming turning the backlight off and on give odd results dimming and undimming at steps untill the intensity doesn't alter.

 http://ubuntuforums.org/showthread.php?p=9710352

[Gabriel Wicke (bugs-wikidev)]

I believe this bug is tracked upstream at https://bugzilla.kernel.org/show_bug.cgi?id=21012, and for Debian in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599768.

[Alexandre (ab-linuxfr)]

I confirm this bug on a Toshiba Portégé R830 with model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz

# lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 2 (rev b4)
00:1c.2 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 3 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1c.5 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 6 (rev b4)
00:1c.6 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev b4)
00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI Controller (rev 04)
01:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 04)
04:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
05:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

[Alexandre (ab-linuxfr)]

Ok, I'm not sure this will help, but since a few days (and no special kernel upgrade), the problem isn't appearing anymore on that Portégé R830. I can suspend to ram/resume and the brightness is ok.
I'm not really sure what changed though.
Sorry for the lack of understanding there.

[camden lindsay (camden-lindsay+launchpad)]

I will check when i get home if it is fixed for my r705 as well.

[camden lindsay (camden-lindsay+launchpad)]

After checking and installing all updates available, my R705 still does not respond to changes in backlight brightness settings after a suspend to ram.

[Victoid (djvictoid)]

I can confirm this bug remains in both 2.6.38-8 and 3.0.0rc1 kernel with an R705. It seems it still needs to be fixed upstream unfortunately.

uname -a
Linux ubuntu 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

uname -a
Linux ubuntu 3.0.0-0300rc1-generic #201105310830 SMP Tue May 31 08:34:42 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

[Avishai Ish-Shalom (avishai-ish-shalom)]

Same bug with Portege R835, kernel 2.6.38-10-generic

[Martin Ling (martin-launchpad)]

Still the same in current Oneiric with kernel 3.0.0-15, on a Toshiba R830.

[Luke Scharf (lukescharf)]

Me too -- Toshiba R835-P56x.

Linux gear 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Latest BIOS update from Toshiba (Version 3.50, according to dmidecode).

I'm programming-literate, and I've been trying to figure out where to start putting together my own fix for months but, since I don't know how ACPI is supposed to work, but I don't know where to start.

[Martin Ling (martin-launchpad)]

For those wanting to help with a solution, here is pretty much everything I've found out:

- Brightness control for these 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.

- The kernel developers are (rightly, in my view) 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, including ours, 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.

- There is a patch by Jose Pereira on the kernel bug report (https://bugzilla.kernel.org/show_bug.cgi?id=21012#c12). This tries to work around 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 this patch, adjusting the backlight via /sys/class/backlight/toshiba/brightness after suspend works but setting it via the hotkeys does not.

- I have seen this problem reported with kernels as late as 3.1.1. I haven't yet tried running the latest 3.2.x to see if the problem has already been fixed there. That's the next thing to try.

- If the problem is not already fixed in the latest mainline kernel, 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. The place you should be looking is drivers/platform/x86/toshiba_acpi.c in the kernel source tree.

[Luke Scharf (lukescharf)]

Martin Ling -- many thanks!

I'll read through and try the patches you mention and go from there, when I get a chance. Things have been busy at work lately, so no promises, but I'm incredibly happy to have a starting point!

Thanks!!
-Luke

[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! :-)

[Audrey Durand (adurand)]

Same thing happens on my Toshiba z830 running Precise with kernel 3.2.0-20-generic.

[Henry Ptasinski (hptasins)]

I'm seeing this on a Toshiba R835-P92 running Oneric with 3.0.0-17-generic. Also seeing it with kernels that I've built from linux-stable (v3.3.1) and wireless-testing (master-2012-03-27). I haven't explored any of the patches mentioned above or compared them to what's been merged to stable.

[Martin Ling (martin-launchpad)]

There is some work in progress towards fixing this bug, under the duplicate report #935778. There is now a kernel that does successfully allow the brightness to be changed after suspend, albeit with a few unresolved issues.

I am marking this bug as a duplicate of #935778 to keep everything together with the (closest) solution.

[penalvch (penalvch)]

camden lindsay, 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>

[camden lindsay (camden-lindsay+launchpad)]

@penalvch

I"m afraid I no longer own this hardware and cannot verify this bug as fixed.
I"m sorry!

[penalvch (penalvch)]

camden lindsay, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606547/comments/22 regarding you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

[gagzou (gagzou)]

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

[penalvch (penalvch)]

gagzou, thank you for your comment. If you have a bug with your backlight, please feel free to 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