Date: Wed, 04 Sep 2013 18:47:47 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Bengt Ahlgren <bengta@sics.se> Cc: Kevin Oberman <rkoberman@gmail.com>, freebsd-acpi <freebsd-acpi@FreeBSD.org>, Laura Marie Feeney <lmfeeney@sics.se>, Gleb Smirnoff <glebius@FreeBSD.org>, "Sergey A. Osokin" <osa@FreeBSD.org>, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@FreeBSD.org> Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) Message-ID: <5227B893.1000509@FreeBSD.org> In-Reply-To: <uh71u54ky9g.fsf@P142.sics.se> References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <uh7a9jsl7qf.fsf@P142.sics.se> <522791D2.9050606@FreeBSD.org> <uh71u54ky9g.fsf@P142.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: > Jung-uk Kim <jkim@FreeBSD.org> writes: > >> On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: >>> Jung-uk Kim <jkim@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@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@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 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@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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5227B893.1000509>