-----BEGIN PGP SIGNED MESSAGE-----
On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote:
> Jung-uk Kim <j...@freebsd.org> writes:
>> On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote:
>>> Jung-uk Kim <j...@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
>>>>>> 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
>>>>> 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:
>> does pretty much the same thing. FYI, vbetool does "more" but it
>> does not really do more "reinitialisation".
>> % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER=
> 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
Then, KMS probably breaks acpi_video(4), too. :-(
> 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
>>> 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)
-----END PGP SIGNATURE-----
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"