Re: Help with uswsusp
On Wednesday, September 08, 2010, Rodolfo kix Garcia wrote:
> On Wed, 08 Sep 2010 07:11:16 +0200, Michael Biebl <biebl@debian.org>
> wrote:
> > On 07.09.2010 21:15, Rodolfo kix Garcia wrote:
> >> On 07/09/10 01:40, Kan-Ru Chen wrote:
> >>> Hi!
> >> Now I am trying to maintain the database (from 8 months ago), and the
> >> project was moved from sourceforge to git.kernel.org, but there is not
> >>a new version in the webpage. The database is important because it has
> >>the flags for the suspend to ram, an example:
If that helps, I think I can release a new version in a couple of weeks.
> > With KMS all those quirks are obsolete and actually harmful, if you try
> > to apply those quirks when using KMS (I got bug reports agains pm-utils
> > where suspend/resume failed because of that).
>
> Yes, this is correct. The problem is that now, the kernel is moving from
> old kernels to new KMS kernels. Probably Rafael can offer more information
> about this.
Well, not much, but in fact I'd recommend not to use s2ram with KMS drivers
(openSUSE has some checks for this purpose in its pm-utils scripts).
> > Maintaining a database outside of the kernel has no future.
Maintaining a database in the kernel is not an option, however. So, for
backwards compatibility the database in s2ram will probably be handy in the
nearest future at least.
> > We learned that the hard way with hal/pm-utils
>
> Yes, this is correct. The future of uswsusp is (probably, Rafael, is
> correct?):
>
> * For s2ram, delete all function relative to the database (and the
> database), and maintain the command. Basically s2ram will do something like
> "echo ram > /sys/power/state"
I think we'll deprecate s2ram entirely at one point, but we won't remove it
altogether. We'll simply stop accepting any updates to it, but we'll keep the
source code in case someone still needs it on an oldish machine with unusual
graphics adapter.
> * For s2disk, s2both, maintain their functions, compression, splash, ...,
> because they do not use the database.
Yes, except that s2both may be deprecated. It's never been well designed
and breaks some assumptions made by ACPI firmware.
> The problem is what to do with the Debian package now. Continue with the
> 0.8 version, with 85 bugs (some of them solved in the 0.9 git version) or
> don't do nothing now and wait for the next uswsusp (suspend-utils) "1.0"
> without database.
The database is still going to be there, as I said.
> > That said, I very much doubt the usefulness of s2ram in a KMS world.
It won't be useful to the people actually using the KMS (or vendor binary)
drivers, but it may be useful to someone still.
> s2disk
> > still has some nice features (like compression, splash support etc)
> which
> > the
> > in-kernel swsusp has not.
The in-kernel swsusp is getting compression as we speak. :-)
Encryption is _much_ harder, though.
Thanks,
Rafael
Reply to: