From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 20:04:44 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 1B519D84; Wed, 4 Sep 2013 20:04:44 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <522791D2.9050606@FreeBSD.org> Date: Wed, 04 Sep 2013 16:02:26 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130814 Thunderbird/17.0.8 MIME-Version: 1.0 To: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 20:04:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: > Jung-uk Kim 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@FreeBSD.org :-) > 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? > 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) iQEcBAEBAgAGBQJSJ5HRAAoJECXpabHZMqHOZWQIAMHMrSWRw55HslMhQBpdbiI6 lT/iKNGUsHu4um9o8ULJMuuq2aKsSPxygz62a+XokefTbMEBIxQPFfcXAqvvGq2Y 6CvLjimTzfPO8axvvLRLEbVXDKcnHboabW5YxwJ6NreXwiWID+Noifc3EiEs5knj /Y0la3PP9ZWJu71DinGeyNLMoIeNdRC/E+o45P9uDTy3uZh7jBbIIwVdzAUEho+7 dN9xx88FkgYvnaNVJIf2sGmcMbMo0PJHB/9RNnz5AxNtmgVzrlEJaMMwKr1rnRu5 J5mUyuLt27/hGjSamqWaTMA/jS8gYJeF1Gyq7NWb2AvIsWHe68DY2a0MVZe1Oz0= =9xfZ -----END PGP SIGNATURE-----