[Toshiba Portege Z835-ST6N03] Brightness control lost after suspend screen dimmed

[John D Marsden]

Using Ubuntu 14.04. Recently updated to kernel version Ubuntu 3.13.0-30.54-generic 3.13.11.2

I expect brightness of my LCD screen to remain the same and be controllable after waking from suspend. It doesn't and isn't.

What happens:

Brightness controls fully working after initial boot, both through function keys and system settings.

After putting computer into suspend and then re-awakening the LCD screen comes up with lowest brightness in actual appearance but settings still show the brightness as set at suspend time. Controls for brightness have become ineffective - they slide the brightness bar along but make no difference to the actual brightness of the screen.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-30-generic 3.13.0-30.54
ProcVersionSignature: Ubuntu 3.13.0-30.54-generic 3.13.11.2
Uname: Linux 3.13.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: john 2060 F.... pulseaudio
CurrentDesktop: Unity
Date: Sat Jul 5 18:55:05 2014
InstallationDate: Installed on 2012-06-04 (760 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MachineType: TOSHIBA PORTEGE Z835
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-30-generic root=UUID=865f4d37-5ceb-4e4a-b59b-032fa8a2c80b ro quiet splash elevator=noop vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-30-generic N/A
 linux-backports-modules-3.13.0-30-generic N/A
 linux-firmware 1.127.4
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: Upgraded to trusty on 2014-04-27 (68 days ago)
dmi.bios.date: 02/08/2012
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 1.60
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:bvrVersion1.60:bd02/08/2012:svnTOSHIBA:pnPORTEGEZ835:pvrPT224U-01W00C:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: PORTEGE Z835
dmi.product.version: PT224U-01W00C
dmi.sys.vendor: TOSHIBA

[Brad Figg (brad-figg)]

This change was made by a bot.

[John D Marsden (jdmarsden)]

Clarification:

Screen does not always come up dimmed after suspend. Screen comes up with setting prior to suspend.

If the computer has gone into suspend itself after being unused for a certain amount of time it comes up dimmed, even if not deliberately set to this by the user. In these circumstances the computer has dimmed the screen some time prior to going into suspend.

In all cases controls no longer function after suspend as reported in initial post.

[John D Marsden (jdmarsden)]

Upgrade to Ubuntu 3.13.0-30.55-generic 3.13.11.2 does not solve the problem.

[John D Marsden (jdmarsden)]

Christopher, thank you for your advice and my apologies for not following the protocol of first checking for BIOS updates.

I have now updated the BIOS. Results of "sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date" are:
   Version 1.80
   04/18/2013
so the update has worked.

Unfortunately the problem still persists as previously described.

Please note the problem also manifests on my wife's Toshiba Protege Z835-ST8305 which I have also updated to the latest BIOS. Her computer is also running Ubuntu 14.04 with kernel version Ubuntu 3.13.0-30.55-generic 3.13.11.2

Thank you for your help.

[penalvch (penalvch)]

John D Marsden, could you please test the latest upstream kernel available from the very top line at the top of the page (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.16-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[John D Marsden (jdmarsden)]

Installed latest upstream mainline kernel: 3.16.0-031600rc4-generic

Unfortunately this failed to solve the problem. Brightness control on systems settings and via function keys works on initial boot but ceases to work after a suspend, as before.

Thank you for your help.

[John D Marsden (jdmarsden)]

Clarification:

I have gone back to older kernels on my machine to confirm my feeling that this only started happening recently. The oldest kernel on my machine is 3.8.0-31-generic. The problem also occurs with when booted with this kernel so my feeling that this was recent is wrong.

I have edited the original bug report to remove my assertion that it had seemed to have only started recently.

[penalvch (penalvch)]

John D Marsden, could you please provide the missing information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[John D Marsden (jdmarsden)]

As requested I followed the steps in https://wiki.ubuntu.com/DebuggingKernelSuspend.

Results are:
1. Information from sticker on computer:
   Manufacurer: Toshiba
   Model: Protege Z835-ST6N03
   Part No: PT224U-01W00C
2. Bios is already upgraded to latest version 1.80.
3. Booted in mianline upstream kernel 3.16-rc4. Suspended with pm-trace and awakened successfully.
   cat /proc/acpi/wakeup > wakeup result is attached.
4. Resume trace result:
   a) Resume succeeded, though LCD brightness controls fail as originally reported.
   b) Result of: dmesg > mesg.txt will be attached.
   c) Searched dmesg.txt for "Magic number" and got:
           .....
           [ 0.864274] Magic number: 6:405:689
           [ 0.864395] rtc_cmos 00:05: setting system clock to 2014-07-09 15:41:36 UTC (1404920496)
           .....
   d) Searched dmesg.txt for "hash match"" and got no lines matching search.
   e) Not sure whether brightness controls failing counts as "graphics related issue".
        So will attach Xorg.0.log and Xorg.0.log.old just in case.

[John D Marsden (jdmarsden)]

In answer to "did this problem not occur in a release prior to Trusty?":

I'm sorry, I don't know for sure. I only noticed the problem the day I first reported it, however my behaviour regarding shutdowns rather than suspends has recently changed so that may well be why I noticed it. My wife hadn't noticed it on her computer (see mention in comment #6) until I specifically tested for it.

However in comment #9 above I report testing and getting the same result with kernel version 3.8.0-31 which must date from when I had Raring running on my computer.

[John D Marsden (jdmarsden)]

In answer to: "if you remove the kernel parameter elevator=noop does this change anything?"
No it does not change anything. I tried with this kernel parameter removed on the latest mainline upstream kernel 3.16-rc4.

As requested, tested on Precise 12.04.0 and 12.04.3 both obtained from http://old-releases.ubuntu.com/releases/12.04.0/. Used "Live CD" method. In both cases the bug as originally reported occurred.

[John D Marsden (jdmarsden)]

I have tested against the kernel at http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc5-utopic/ and can confirm that the bug as reported still persists.

[penalvch (penalvch)]

John D Marsden, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

[John D Marsden (jdmarsden)]

Christopher, Thank you for your guidance on this issue. I want to make sure I report this upstream in the correct way and am unsure of which upstream list I should be using.

https://wiki.ubuntu.com/DebuggingKernelSuspend mentions says "Suspend and Resume use facilities within your BIOS called ACPI". Should I therefore report to the <email address hidden> list?
Or should I use the <email address hidden> list which is mentioned in the "SUSPEND TO RAM" section of http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS ?
Or, since the bug refers to a Toshiba laptop should I use the <email address hidden> list which is mentioned in the "TOSHIBA ACPI EXTRAS DRIVER" section?
Or something else?

I appreciate your help.

[penalvch (penalvch)]

John D Marsden, I would start with linux-acpi. linux-pm is more for a bug in the software of suspend itself, not buggy drivers that cause suspend to not work.

[John D Marsden (jdmarsden)]

Reported upstream. See http://marc.info/?l=linux-acpi&m=140658075422146&w=2.

As requested from upstream am attaching output from acpidump as acpidump.txt

[John D Marsden (jdmarsden)]

Workround provided from upstream dialogue - Thank you Aaron.

See http://marc.info/?l=linux-acpi&m=140686098023199&w=2

In summary:
Switching to use the "intel-backlight" interface rather than the "acpi_video0" interface makes the controls for brightness work after suspend. This can be done by creating, or adding to, the file /etc/X11/xorg.conf with the section below:

Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
Option "Backlight" "intel_backlight"
Driver "intel"
BusID "PCI:0:2:0"
EndSection