can_suspend_to_{x}

[Peter Jones]

On Sat, 2006-05-06 at 10:28 +0200, Danny Kukawka wrote:

> > Developing gnome-power-manager (and a chunk of the power management in HAL) 
> > gives me first-hand experience of the ways users, distros, packagers and 
> > developers can and do get this wrong.
> 
> Why do you think they do this wrong? For KDE e.g. IMO everybody know already 
> the terms s2ram/s2disk/standby from klaptop and kpowersave since a long time. 

How do "s2ram" and "standby" differ?  I don't think the answer is clear
to anybody who hasn't read the ACPI docs, or had it explained to them by
somebody who has.  Even if you do know the difference, it's something of
a triviality these days, since suspend is pretty fast.

> Why should this be wrong and why should they change this?

In the UI, "suspend" and "hibernate" are pretty unambiguous, and that's
good.  But it's easier for people to contribute to these tools
themselves if we use the same nomenclature internally as we do in the UI
wherever possible.

> > Bad Nomenclature
> > - Sleep  
> > - Standby
> > - Suspend-to-RAM 
> 
> Btw. Standby is used under KDE related to standby from /sys/power/state. 

_Why_? 

If you really must keep standby around, I don't object to leaving it
with that name, although I think it's incredibly inexpressive.  "s2ram",
"suspend-to-ram", "s2disk", and "suspend-to-disk" are all pretty awful,
though.

Really, keeping that state and leaving it with the name "standby" means
there should be some sort of name for coming out of standby that doesn't
have the connotations of coming out of suspend or hibernate.  The best I
can come up with that seems related to standby is "continue", which
obviously doesn't meet that criteria.  And "unstandby" is obviously
pretty awful.

Really, though, I think "standby" mode is pretty pointless these days.

> > I figure getting the same names so it all makes sense when we document
> > it, is worth the short term pain of breaking (undocumented?) API.
> 
> No, this is not undocumented API. Take a look at the SPEC.

Which spec?  ACPI?

-- 
  Peter