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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/935778 Title: Toshiba R840 - brightness controls work on first boot, but do nothing after suspend/resume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
