From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 22:37:20 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E556E27; Wed, 4 Sep 2013 22:37:20 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAA3D2B89; Wed, 4 Sep 2013 22:37:19 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r84MbGuQ045353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 00:37:16 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r84Md7Mo006454; Thu, 5 Sep 2013 00:39:07 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r84Md72H006453; Thu, 5 Sep 2013 00:39:07 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Jung-uk Kim Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) In-Reply-To: <522791D2.9050606@FreeBSD.org> (Jung-uk Kim's message of "Wed, 04 Sep 2013 16:02:26 -0400") References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Thu, 05 Sep 2013 00:39:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= 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 22:37:20 -0000 Jung-uk Kim writes: > 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 > > :-) Great! Is vesa.c = options VESA = vesa.ko? >> 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@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@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Jumping to another thing. The Xorg intel/KMS driver does not present a backlight property using RandR (older non-KMS intel driver did): [bengta@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