suspend/resume on Lenovo X1 (regression from reports on wiki)
Bengt Ahlgren
bengta at sics.se
Wed Sep 4 19:12:52 UTC 2013
Jung-uk Kim <jkim at FreeBSD.org> writes:
> On 2013-09-04 09:29:35 -0400, John Baldwin wrote:
>> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote:
>>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote:
>>>> Even with that hacked so I force vgapm0 and dpms0 to attach, I
>>>> still can't resume in console mode, ...
>>>
>>> What happens? Does it panic, hang, or just no backlight?
>>
>> Just no backlight. It resumes fine and if I do it in multiuser I
>> can ssh in, etc. It's just the backlight that doesn't resume. I
>> was hopeful dpms.ko would fix that, but it didn't. :(
>
> Ah, that's a well-known problem and we cannot fix it without help of
> machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and
> dpms try to restore video settings but nothing worked for Intel GPUs +
> LVDS + LCD panel AFAIK.
>
>> I think i915drm has code to specifically turn on the backlight as
>> I get some weird error message in the kernel console about a
>> timeout trying to turn the panel off during suspend when I'm in X.
> So, I guess it has an ordering issue. If my memory serves, drm1 was
> okay with vesa, however. I *think* it accidentally worked because of
> automatic VT-switching, which is still broken for KMS.
Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I
have enabled on my older hardware (TP X40 running 8.3-REL and an old
Xorg server) for it to work properly. (I however have some faint memory
that reset_video might a no-op these days, or?) In this old mail
regarding reset_video, there is a thought that it could be good with
"more" reinitialisation:
http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html
I however have one datapoint that I think contradicts John's thought.
This is on a X201 with stable/9 and no options VESA. I first just
booted up and stayed in text console, suspended and resumed. No
backlight, of course, and also no content on the LCD, it is completely
black. Then, I started Xorg with KMS. Still no backlight, but you can
see that the LCD is driven with the desired content, which is one step
forward. Finally, I suspended and resumed, but no difference, the
backlight is still off. Xorg/KMS didn't manage to turn the backlight
on, so the text console suspend/resume cycle managed to persistently
turn the backlight off.
One more thing, the kernel logs this at resume directly after the
devices are powered on (transition to D0), but I have no idea whether it
is relevant:
Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off
Bengt
More information about the freebsd-acpi
mailing list