suspend/resume on Lenovo X1 (regression from reports on wiki)

[Jung-uk Kim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote:
> Jung-uk Kim <jkim at FreeBSD.org> writes:
> 
>> On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote:
>>> 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?)
>> 
>> No, I didn't remove it.  However, I strongly discourage it.  In
>> fact, the same functionality exists in vesa.c and it is safer.
>> 
>>> 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
>>
>>
>>> 
vesa.c
>>> 
>> does pretty much the same thing.  FYI, vbetool does "more" but it
>> does not really do more "reinitialisation".
>> 
>> % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER=
>> jkim at FreeBSD.org
>> 
>> :-)
> 
> Great!  Is vesa.c = options VESA = vesa.ko?

Yes.

>>> 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.
>> 
>> Panel may be completely off.
>> 
>>> 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.
>> 
>> I believe i915kms explicitly turns on LVDS/LCD panel.  I guess
>> it doesn't change brightness, though.
>> 
>>> Xorg/KMS didn't manage to turn the backlight on, so the text 
>>> console suspend/resume cycle managed to persistently turn the 
>>> backlight off.
>> 
>> Can you change the brightness via hotkeys or acpi_video?
> 
> The value of hw.acpi.video.lcd0.brightness changes when the screen 
> brightness keys (Fn+Home/End) are pressed, but nothing happens with
> the screen.  Same goes for changing the value with sysctl.  After a
> fresh boot it works with one issue.  The screen brightness level
> seems to lag behind one keypress.  Without acpi_video, screen
> brightness changes without the lag.
> 
> hw.acpi.video.lcd0.active is always stuck at 0 - can't change with 
> sysctl (regardless if the screen is on after a fresh boot, or
> black after a text console suspend/resume):
> 
> [root at bit ~]# sysctl hw.acpi.video.lcd0.active=1 
> hw.acpi.video.lcd0.active: 0 -> 0
> 
> Again, for my old X40 with non-KMS Xorg intel driver has
> (curiously, the screen blinks when issuing this sysctl command):
> 
> [bengta at P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 
> hw.acpi.video.crt0.active: 0

Then, KMS probably breaks acpi_video(4), too. :-(

Jung-uk Kim

> Jumping to another thing.  The Xorg intel/KMS driver does not
> present a backlight property using RandR (older non-KMS intel
> driver did):
> 
> [bengta at bit ~]$ xbacklight No outputs have backlight property
> 
> Bengt
> 
>>> 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
>> 
>> Yes, it looks relevant.
>> 
>> Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (FreeBSD)

iQEcBAEBAgAGBQJSJ7iTAAoJECXpabHZMqHOX0kH/Ag+vuvrx3YKyeYHKiGwlOKR
eOp8s4m9EJgdPFy2Tw5u9xQsLiQ1JBgT10kZ+PDXaqFGEPGlVROrfc/lsoUVx6u3
ArOGaG1+NO1dTHurfrysRl/k35fcnY3p8+KrYmzbia6BNWC/3DmtnHItaWn+nOs2
PFJfCBWjjljVpZa+TNRBR2H5QMGOFnOGA9kDgZQe3QJY0JGZOMTuXizWatEYWo5q
7hLZsyvEsIQNSbmofE7KO5JNekllQ/F5A9RLilXRPnJBaJm1to2BT89Nf8JgiIxm
18jk17XXkRWYmAkM+8aYrxUoR9SIK/jn3hxL4iNZRma/yWbSfcvj/dqJnMoEC0A=
=Rfa3
-----END PGP SIGNATURE-----