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

[Jung-uk Kim]

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

On 2013-09-05 16:04:56 -0400, Bengt Ahlgren wrote:
> Jung-uk Kim <jkim at FreeBSD.org> writes:
> 
>> On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote:
>>> On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote:
>>>> 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. :-(
>> 
>> kib let me know that there is a way to make it work but it was
>> not well-integrated to i915kms.ko.  If you are interested in
>> fixing it, dev/drm2/i915/intel_opregion.c is the source and you
>> can download the specification from here:
>> 
>> https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf
>
>> 
> Hmm, scanning that spec, I wonder whether the opregion
> functionality is better placed together with acpi_video, and then
> i915kms makes calls to that instead?

Traditionally, platform-specific code goes to dev/acpi_support.  So,
dev/acpi_support/acpi_intel.c may be created to cater its needs, if it
is absolutely necessary.

> Hmm, again, perhaps the intel platform needs opregion support to
> work properly also without the kms driver.  Could be anexplanation
> for the backlight issues.

Yes and yes, I think.

However, many developers are tired of dealing with syscons ugliness
and now the Foundation is sponsoring ray@ to replace syscons with
newcons+KMS if my understanding is correct.  I am not sure how it will
be layered at the end, though.

> (Just speculation so far...  I have no idea if/how this relates to
> or interacts with options VESA)

Apparently, they interact badly. :-(

Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (FreeBSD)

iQEcBAEBAgAGBQJSKOpXAAoJECXpabHZMqHOSnIIANS/Kt043RI7fFLNYVeWvpH0
zQ8C3wTi66aIW9B5bvYcXcJXcE1yazfegbtAHT6i0Hf4/BrvoMkN3umHIRYMbMv9
ei7WoFDLRIuyGzqgMy7CP3t9byYZolRBuyIt+zELsNU/5zCkgSP3di40TK+oLJ+3
NXhALsLZA37B1S3TYaiLy+U4BylfC3iNhFDlDRrikuYvAym/s5o/Ro0Ea8dyUw4i
CtWDEomCIwjzOuythAl1wlXYeMtZZp+6Fj2Pemhh9COzFXgHiTfhfVySRVt0tBAs
6FKmQnc30ra2clU1o5JJuzwlOsgGH+aztvrdjc4VGr/wGpdmKW6FrNlpcku1VkQ=
=i0JD
-----END PGP SIGNATURE-----