Richard Hughes wrote: > In the last couple of years, I've been striving to make consistent the > mapping of sleep states consistent. I don't care what we call things in > a UI, but we need to make sure we're not arguing about whether: > > KEY_SUSPEND should be mapped to XF86Standby, XF86Hibernate or XF86Sleep > KEY_SLEEP should be mapped to XF86Hibernate or XF86Standby > > You see it's a mess. > > In userspace we've agreed with the following nomenclature: > > standby = sleep CPU and devices (not really used any more) > suspend = sleep to memory (quite fast) > hibernate = sleep to disk (slow) > hybrid = sleep to both (slow, but fast resume) > > In X, and evdev we've also fixed the mapping, so that: > > XF86Sleep : suspend _or_ hibernate (configured in session policy) > XF86Suspend: suspend > XF86Hibernate: hibernate > > This means that if a key on a keyboard can be sleep (but the user can > choose which), the application handles XF86Sleep. If the button decal is > marked with a disk, or the ram symbol, then we choose XF86Hibernate or > XF86Suspend as appropriate. > > We've changed this in HAL a few years ago, As of "git pull" made five minutes ago, HAL emits "sleep" for KEY_SLEEP and "hibernate" for KEY_SUSPEND. So changing kernel semantic of KEY_SUSPEND will break any older HAL installation. > xproto, libX11 and > xkeyboard-config last year, and nearly all of the session software in > use uses the same nomenclature for the last few years. > > After reviewing the platform drivers in ACPI, it appears few of them > know whether KEY_SLEEP corresponds to suspend or hibernate, and > KEY_SUSPEND seems to be used for hibernate. Basically, it's a mess. > This is exactly what current HAL does :) > I propose that we add a KEY_HIBERNATE (key 247), and then we can just > do: > > KEY_HIBERNATE -> XF86Hibernate -> sleep to disk > KEY_SUSPEND -> XF86Suspend -> sleep to ram > KEY_SLEEP -> XF86Sleep -> sleep (configurable) > > Then the drivers can be patched so everyone is doing the same thing. At > the moment I'm diagnosing bugs and trying to work around the brokenness > in userspace hal-info every few days, and it's getting tiresome. > > Feedback welcome, although please don't comment on things like "suspend > sounds more like a suspend to disk" as we spent years talking with > userspace people working for a compromise, and this is what we've > settled on. It's not to everyones taste, but we _do_ need to agree on > something, even if its just an agreed bodge. > This all sounds very reasonable except it is not clear how HAL transition should be handled. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
