Comment 11 for bug 872652

I confirm this regression in 11.10, on a Dell Studio 1558 (even without acpi_backlight=vendor).

When the screensaver switches off the backlight, it does not come back on by tapping arbitrary keys as expected; The dark screen makes the system appear "hung", though really its just the backlight stuck off at the "unlock" password prompt dialog. Forcing a suspend/resume with the lid re-enables the backlight.

Disabling DPMS alleviates the problem (run 'xset -dpms' to do so). With DPMS disabled, the screensaver paints the screen black (but does not actually switch off the backlight), and then tapping an arbitrary key presents the screensaver "unlock" screen as expected. (@Joshua, can you confirm that 'xset -dpms' has the same beneficial effect on your system?)

More notes...

Even with dpms enabled,
$ xset s activate
... causes the backlight to switch off and *stay* off. Contrast with the behavior in 11.04, where that command makes the backlight switch off and then immediately switch back on again. Tapping arbitrary keys does not re-enable the backlight, but tapping the brightness-up key *does* work. Unfortunately, at the "unlock" screen, the brightness keys are not processed (so even though brightness-up works to fix the dark screen resulting from 'xset s activate', it does not light the screen again once the screensaver has switched it off).

I experience this problem even without acpi_backlight=vendor (my Studio 1558 does not need it; my /sys/class/backlight/intel_backlight brightness controls work properly by default in oneiric).