> According to the Lenovo forum thread above, there is a new BIOS (1.30)
> that allows you to select "Sleep State" between Windows and Linux so I
> suppose in case of Linux they enabled S3.
Amazing---it turns out that everybody outside this list was correct in
thinking that S3 works just fine on this laptop! Maybe consistent
reports from Linux users sometimes mean something? :-)
In all seriousness: Deployment of today's BIOS update should mean that
the DMI part of my patch, enabling S3 specifically for this laptop, will
become redundant. Let me emphasize, however, that the patch also plans
ahead for the next laptop that hides its S3 support. Specifically, the
patch adds an
acpi_force_s3=5
command-line option saying that the machine supports S3 as hardware
sleep state 5. The user can change the 5, of course; this is just an
example for this laptop.
If this command-line option had been available six months ago then the
Linux community would have skipped all the work on building ACPI DSDT
overrides for this laptop and documenting how to install overrides on
various boot systems; Qubes/Xen users would have had the laptop working
five months earlier; and many user complaints, rising to the level of
people saying "I have returned this laptop", would have been avoided.
I suppose it's possible that the entire laptop industry will learn a
lesson from Lenovo here, and that S3 support will be announced in every
new laptop's DSDT until we've all reached the bright and glorious future
in which continued development of s2idle has removed the need for S3.
But, just in case the future isn't so perfect, I think it's worth a few
lines of code in the kernel to give users an easy workaround.
It has been brought to my attention that the people in charge saw my
patch more than a month ago (when I posted it to qubes-users), and
dismissed it on the basis of Lenovo supposedly not having tested S3 on
this laptop---even though public reports already showed
* S3 consistently making Linux users happier with this laptop (since
s2idle is far from its goal of matching S3 in power consumption,
while nobody encountered any S3 problems), and
* S3 being the only option available to make this laptop work under
Qubes/Xen (since, for reasons that still haven't been diagnosed,
s2idle fails to resume).
I must admit to continued puzzlement as to what the Linux testing
standards are, and how those standards led to allowing s2idle on this
laptop while failing to allow S3. I understand that there's enthusiasm
for the extra functionality of s2idle (and I support Intel's efforts to
compete with ARM in enabling low-power applications), but if years of
development are still giving s2idle users
* much worse battery drain than S3 on some laptops and
* totally non-functional resume in some environments
then surely it's too early to throw S3 away.
---Dan
Attachment:
signature.asc
Description: PGP signature
