Comment 33 for bug 935778

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.