Comment 3 for bug 872652

Updating with some questions from Kamal Mostafa and my answers:

> In the report, please make a note of which backlight interfaces appear
> when you run "ls /sys/class/backlight" when you do *not* boot with
> acpi_backlight=vendor, and also when you *do*.

Without acpi_backlight=vendor:
* acpi_video0
* intel_backlight

With acpi_backlight=vendor:
* dell_backlight
* intel_backlight

> Since you say that you can sometimes make it recover by switching to a
> different console tty then back again, my guess is that the system is
> probably actually always suspending and resuming correctly -- but the
> backlight is sometimes not getting re-enabled on resume. If you have
> another machine on your network, you could try to confirm that by
> ping'ing or ssh'ing into the laptop while its in its dark state. In
> fact, if you can ssh into it, we could then try checking the brightness
> state and manually increasing it. Let me know what you find when you
> try to ping or ssh into the machine and we'll proceed from there.

When I can't get the display working, the laptop is responsive. I often have it hooked up to a second display through the HDMI port, and that display does enable properly. Getting the display back ON by switching ttys is rare, but doing a full system suspend and resume ALWAYS causes the display to be reenabled.

* How can I manually induce a display suspend?
* How do I manually change the display brightness level?

> Now you also mention that closing and opening the lid again fixes the
> problem... Is that behavior consistent? Specifically, are you saying
> that it *always* fails to light up when you suspend/resume the first
> time, but then *always* lights up again when you suspend/resume the
> second time? Or is the behavior not as consistent as that?

Correct, a full system suspend/resume always fixes the issue.