suspend / hibernate nomenclature

suspend / hibernate nomenclature

[Richard Hughes]

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, 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.

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.

Would patches be accepted to fix this?

Thanks,

Richard Hughes.

Re: suspend / hibernate nomenclature

[Henrique de Moraes Holschuh]

On Mon, 02 Mar 2009, Richard Hughes wrote:
> 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

And when hybrid is to be used it gets hooked to hibernate, correct?

> 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)

I'd like that.

I'd also like a LOT if proper documentation were added next to the
KEY_ defines...

> 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.
> 
> Would patches be accepted to fix this?

FWIW, I think it is a good idea, and I'd take patches for
thinkpad-acpi.

But I would appreciate that the commit log discloses the userspace
versions of stuff like HAL that have the desired behaviour.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend / hibernate nomenclature

[Richard Hughes]

On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
> And when hybrid is to be used it gets hooked to hibernate, correct?

Well, this is from the physical keys to the input event. I've not seen a
laptop out there that has a specific "suspend hybrid" key, because
that's just a type of hibernation. I do see a lop of laptops that have a
single "sleep" key that needs policy from the session.

Richard,

[patch] add KEY_HIBERNATE and clarify the uses of KEY_SUSPEND and KEY_SLEEP

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

I've attached a patch that adds KEY_HIBERNATE and clarifies the uses of
KEY_SUSPEND and KEY_SLEEP.

Please consider. Thanks.

Richard Hughes


[-- Attachment #2: 0001-INPUT-add-KEY_HIBERNATE-and-clarify-the-uses-of-KEY.patch --]
[-- Type: text/x-patch, Size: 2150 bytes --]

>From bc161c6e4253d94dee3b1c42dfcf32a0120921a1 Mon Sep 17 00:00:00 2001
From: Richard Hughes <richard@hughsie.com>
Date: Tue, 3 Mar 2009 17:16:49 +0000
Subject: [PATCH] INPUT: add KEY_HIBERNATE and clarify the uses of KEY_SUSPEND and KEY_SLEEP

Add a new key define that is used for sleeping to disk.

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)

We've already converted Xorg, HAL, and most of userspace to use the same names.
Adding a new key should reduce the confusion where:

KEY_SUSPEND was mapped to XF86Standby, XF86Hibernate or XF86Sleep
KEY_SLEEP was mapped to XF86Hibernate or XF86Standby

With this patch, the sleep keys can be labeled consistently all the way
through the stack. Other patches to device drivers are to follow.

Signed-off-by: Richard Hughes <hughsient@gmail.com>
---
 include/linux/input.h |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/input.h b/include/linux/input.h
index 1249a0c..f5dee33 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -263,7 +263,7 @@ struct input_absinfo {
 #define KEY_MENU		139	/* Menu (show menu) */
 #define KEY_CALC		140	/* AL Calculator */
 #define KEY_SETUP		141
-#define KEY_SLEEP		142	/* SC System Sleep */
+#define KEY_SLEEP		142	/* SC System Sleep (either RAM or disk) */
 #define KEY_WAKEUP		143	/* System Wake Up */
 #define KEY_FILE		144	/* AL Local Machine Browser */
 #define KEY_SENDFILE		145
@@ -324,7 +324,7 @@ struct input_absinfo {
 #define KEY_PROG3		202
 #define KEY_PROG4		203
 #define KEY_DASHBOARD		204	/* AL Dashboard */
-#define KEY_SUSPEND		205
+#define KEY_SUSPEND		205	/* Sleep state, typically to RAM */
 #define KEY_CLOSE		206	/* AC Close */
 #define KEY_PLAY		207
 #define KEY_FASTFORWARD		208
@@ -375,6 +375,8 @@ struct input_absinfo {
 
 #define KEY_WIMAX		246
 
+#define KEY_HIBERNATE		247	/* Sleep state, typically to disk */
+
 /* Range 248 - 255 is reserved for special needs of AT keyboard driver */
 
 #define BTN_MISC		0x100
-- 
1.6.1.3

Re: [patch] add KEY_HIBERNATE and clarify the uses of KEY_SUSPEND and KEY_SLEEP

[Rafael J. Wysocki]

On Tuesday 03 March 2009, Richard Hughes wrote:
> I've attached a patch that adds KEY_HIBERNATE and clarifies the uses of
> KEY_SUSPEND and KEY_SLEEP.
> 
> Please consider. Thanks.

FWIW, I agree with the naming.

Thanks,
Rafael

Re: [patch] add KEY_HIBERNATE and clarify the uses of KEY_SUSPEND and KEY_SLEEP

[Dmitry Torokhov]

On Tue, Mar 03, 2009 at 08:53:04PM +0100, Rafael J. Wysocki wrote:
> On Tuesday 03 March 2009, Richard Hughes wrote:
> > I've attached a patch that adds KEY_HIBERNATE and clarifies the uses of
> > KEY_SUSPEND and KEY_SLEEP.
> > 
> > Please consider. Thanks.
> 
> FWIW, I agree with the naming.
> 

Applied to next, thank you Richard.

-- 
Dmitry

[PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
> FWIW, I think it is a good idea, and I'd take patches for
> thinkpad-acpi.

Patch attached for thinkpad-acpi. KEY_HIBERNATE is already in
linux-next, but has not yet been pushed to master. Please review,
thanks.

Richard.


[-- Attachment #2: 0002-thinkpad-acpi-use-correct-key-names-for-sleep-keys.patch --]
[-- Type: text/x-patch, Size: 2203 bytes --]

>From d3ce499f80ba7526e83e7b16f85124ccf77ac1f4 Mon Sep 17 00:00:00 2001
From: Richard Hughes <richard@hughsie.com>
Date: Wed, 4 Mar 2009 10:51:52 +0000
Subject: thinkpad-acpi: use correct key names for sleep keys in driver

Use the new key KEY_HIBERNATE and correct the use of KEY_SUSPEND.

KEY_HIBERNATE is used when the decal on the key indicates sleep to disk,
KEY_SUSPEND is used when the decal indicates sleep to memory, and
KEY_SLEEP is used when the sleep type is unknown or unspecified

We've already converted Xorg, HAL, and most of userspace to use the same names.

With this patch, the sleep keys can be labeled consistently all the way
through the stack. More patches to other device drivers are to follow.

Signed-off-by: Richard Hughes <hughsient@gmail.com>
---
 drivers/platform/x86/thinkpad_acpi.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index bcbc051..d89015d 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2241,9 +2241,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 	 */
 	static u16 ibm_keycode_map[] __initdata = {
 		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
-		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SLEEP,
+		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SUSPEND,
 		KEY_WLAN,	KEY_FN_F6, KEY_SWITCHVIDEOMODE, KEY_FN_F8,
-		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
+		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_HIBERNATE,
 
 		/* Scan codes 0x0C to 0x1F: Other ACPI HKEY hot keys */
 		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
@@ -2277,9 +2277,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 	};
 	static u16 lenovo_keycode_map[] __initdata = {
 		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
-		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SLEEP,
+		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SUSPEND,
 		KEY_WLAN,	KEY_FN_F6, KEY_SWITCHVIDEOMODE, KEY_FN_F8,
-		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
+		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_HIBERNATE,
 
 		/* Scan codes 0x0C to 0x1F: Other ACPI HKEY hot keys */
 		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
-- 
1.6.1.3

[PATCH] panasonic-laptop: use correct key names for sleep states in driver

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Wed, 2009-03-04 at 10:54 +0000, Richard Hughes wrote:
> On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
> > FWIW, I think it is a good idea, and I'd take patches for
> > thinkpad-acpi.
> 
> Patch attached for thinkpad-acpi. KEY_HIBERNATE is already in
> linux-next, but has not yet been pushed to master. Please review,
> thanks.

Patch also attached for panasonic-laptop. Harald, can you please review
this. Thanks.

Richard


[-- Attachment #2: 0003-panasonic-laptop-use-correct-key-names-for-sleep-ke.patch --]
[-- Type: text/x-patch, Size: 1447 bytes --]

>From 11df58e5c55e6286f03b29b6b9820ed4b13095db Mon Sep 17 00:00:00 2001
From: Richard Hughes <richard@hughsie.com>
Date: Wed, 4 Mar 2009 10:57:36 +0000
Subject: panasonic-laptop: use correct key names for sleep keys in driver

Use the new key KEY_HIBERNATE and correct the use of KEY_SUSPEND.

KEY_HIBERNATE is used when the decal on the key indicates sleep to disk,
KEY_SUSPEND is used when the decal indicates sleep to memory, and
KEY_SLEEP is used when the sleep type is unknown or unspecified

We've already converted Xorg, HAL, and most of userspace to use the same names.

With this patch, the sleep keys can be labeled consistently all the way
through the stack. More patches to other device drivers are to follow.

Signed-off-by: Richard Hughes <hughsient@gmail.com>
---
 drivers/platform/x86/panasonic-laptop.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/panasonic-laptop.c b/drivers/platform/x86/panasonic-laptop.c
index c47a44d..63a1828 100644
--- a/drivers/platform/x86/panasonic-laptop.c
+++ b/drivers/platform/x86/panasonic-laptop.c
@@ -205,10 +205,10 @@ static const int initial_keymap[KEYMAP_SIZE] = {
 	/*  4 */ KEY_MUTE,
 	/*  5 */ KEY_VOLUMEDOWN,
 	/*  6 */ KEY_VOLUMEUP,
-	/*  7 */ KEY_SLEEP,
+	/*  7 */ KEY_SUSPEND,
 	/*  8 */ KEY_PROG1, /* Change CPU boost */
 	/*  9 */ KEY_BATTERY,
-	/* 10 */ KEY_SUSPEND,
+	/* 10 */ KEY_HIBERNATE,
 };
 
 struct pcc_acpi {
-- 
1.6.1.3

Re: [PATCH] panasonic-laptop: use correct key names for sleep states in driver

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Wed, Mar 04, 2009 at 10:58:26AM +0000, Richard Hughes wrote:
> On Wed, 2009-03-04 at 10:54 +0000, Richard Hughes wrote:
> > On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
> > > FWIW, I think it is a good idea, and I'd take patches for
> > > thinkpad-acpi.
> > 
> > Patch attached for thinkpad-acpi. KEY_HIBERNATE is already in
> > linux-next, but has not yet been pushed to master. Please review,
> > thanks.
> 
> Patch also attached for panasonic-laptop. Harald, can you please review
> this. Thanks.

Acked-by: Harald Welte <laforge@gnumonks.org>

(I've just started three weeks vacation and won't be able to respond to mails
until March 26th)

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] panasonic-laptop: use correct key names for sleep states in driver

[Richard Hughes]

On Thu, 2009-03-05 at 00:58 +0100, Harald Welte wrote:
> On Wed, Mar 04, 2009 at 10:58:26AM +0000, Richard Hughes wrote:
> > On Wed, 2009-03-04 at 10:54 +0000, Richard Hughes wrote:
> > > On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
> > > > FWIW, I think it is a good idea, and I'd take patches for
> > > > thinkpad-acpi.
> > > 
> > > Patch attached for thinkpad-acpi. KEY_HIBERNATE is already in
> > > linux-next, but has not yet been pushed to master. Please review,
> > > thanks.
> > 
> > Patch also attached for panasonic-laptop. Harald, can you please review
> > this. Thanks.
> 
> Acked-by: Harald Welte <laforge@gnumonks.org>

Dmitry, could you pull this and the thinkpad acpi patch into linux-next
please. Thanks.

Richard.

Re: [PATCH] DVB-USB: correct the comment about KEY_SLEEP

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Wed, 2009-03-04 at 10:54 +0000, Richard Hughes wrote:
> On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
> > FWIW, I think it is a good idea, and I'd take patches for
> > thinkpad-acpi.
> 
> Patch attached for thinkpad-acpi. KEY_HIBERNATE is already in
> linux-next, but has not yet been pushed to master. Please review,
> thanks.

Antti, I've included a fix to the Afatech AF9015 DVB-T USB2.0 receiver
header file. It corrects the comment about KEY_SLEEP. Please review.

Thanks,

Richard.


[-- Attachment #2: 0004-DVB-USB-use-correct-key-names-for-sleep-keys-in-dri.patch --]
[-- Type: text/x-patch, Size: 1462 bytes --]

>From 839a18f6663f416b484d496824beb7ad9cfe9215 Mon Sep 17 00:00:00 2001
From: Richard Hughes <richard@hughsie.com>
Date: Wed, 4 Mar 2009 11:01:31 +0000
Subject: DVB-USB: correct the comment about KEY_SLEEP

KEY_HIBERNATE is used when the decal on the key indicates sleep to disk,
KEY_SUSPEND is used when the decal indicates sleep to memory, and
KEY_SLEEP is used when the sleep type is unknown or unspecified

We've already converted Xorg, HAL, and most of userspace to use the same names.

With this patch, the sleep keys can be labeled consistently all the way
through the stack. More patches to other device drivers are to follow.

Signed-off-by: Richard Hughes <hughsient@gmail.com>
---
 drivers/media/dvb/dvb-usb/af9015.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/af9015.h b/drivers/media/dvb/dvb-usb/af9015.h
index 21c7782..e01587c 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -244,7 +244,7 @@ static struct dvb_usb_rc_key af9015_rc_keys_twinhan[] = {
 	{ 0x01, 0x17, KEY_SUBTITLE },     /* Subtitle / CC */
 	{ 0x00, 0x10, KEY_MUTE },
 	{ 0x01, 0x19, KEY_AUDIO },        /* L/R */ /* TODO better event */
-	{ 0x01, 0x16, KEY_SLEEP },        /* Hibernate */
+	{ 0x01, 0x16, KEY_SLEEP },        /* Sleep */
 	{ 0x01, 0x16, KEY_SWITCHVIDEOMODE },
 					  /* A/V */ /* TODO does not work */
 	{ 0x00, 0x06, KEY_AGAIN },        /* Recall */
-- 
1.6.1.3

Re: [PATCH] DVB-USB: correct the comment about KEY_SLEEP

[Antti Palosaari]

Richard Hughes wrote:
> On Wed, 2009-03-04 at 10:54 +0000, Richard Hughes wrote:
>> On Mon, 2009-03-02 at 08:24 -0300, Henrique de Moraes Holschuh wrote:
>>> FWIW, I think it is a good idea, and I'd take patches for
>>> thinkpad-acpi.
>> Patch attached for thinkpad-acpi. KEY_HIBERNATE is already in
>> linux-next, but has not yet been pushed to master. Please review,
>> thanks.
> 
> Antti, I've included a fix to the Afatech AF9015 DVB-T USB2.0 receiver
> header file. It corrects the comment about KEY_SLEEP. Please review.

It is not correct. Comment "Hibernate" for that button comes from the 
remote controller, where "Z^z" is printed to the top of the button and 
"Hibernate" below the button. Replacing KEY_SLEEP with KEY_HIBERNATE 
seems to be correct solution for me.

regards
Antti
-- 
http://palosaari.fi/

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Henrique de Moraes Holschuh]

On Wed, 04 Mar 2009, Richard Hughes wrote:
> >From d3ce499f80ba7526e83e7b16f85124ccf77ac1f4 Mon Sep 17 00:00:00 2001
> From: Richard Hughes <richard@hughsie.com>
> Date: Wed, 4 Mar 2009 10:51:52 +0000
> Subject: thinkpad-acpi: use correct key names for sleep keys in driver
> 
> Use the new key KEY_HIBERNATE and correct the use of KEY_SUSPEND.
> 
> KEY_HIBERNATE is used when the decal on the key indicates sleep to disk,
> KEY_SUSPEND is used when the decal indicates sleep to memory, and
> KEY_SLEEP is used when the sleep type is unknown or unspecified
> 
> We've already converted Xorg, HAL, and most of userspace to use the same names.
> 
> With this patch, the sleep keys can be labeled consistently all the way
> through the stack. More patches to other device drivers are to follow.
> 
> Signed-off-by: Richard Hughes <hughsient@gmail.com>

Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

> ---
>  drivers/platform/x86/thinkpad_acpi.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index bcbc051..d89015d 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -2241,9 +2241,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
>  	 */
>  	static u16 ibm_keycode_map[] __initdata = {
>  		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> -		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SLEEP,
> +		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SUSPEND,
>  		KEY_WLAN,	KEY_FN_F6, KEY_SWITCHVIDEOMODE, KEY_FN_F8,
> -		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
> +		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_HIBERNATE,
>  
>  		/* Scan codes 0x0C to 0x1F: Other ACPI HKEY hot keys */
>  		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
> @@ -2277,9 +2277,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
>  	};
>  	static u16 lenovo_keycode_map[] __initdata = {
>  		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> -		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SLEEP,
> +		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SUSPEND,
>  		KEY_WLAN,	KEY_FN_F6, KEY_SWITCHVIDEOMODE, KEY_FN_F8,
> -		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
> +		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_HIBERNATE,
>  
>  		/* Scan codes 0x0C to 0x1F: Other ACPI HKEY hot keys */
>  		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */


-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

On mer, 2009-03-04 at 09:04 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 04 Mar 2009, Richard Hughes wrote:
> > >From d3ce499f80ba7526e83e7b16f85124ccf77ac1f4 Mon Sep 17 00:00:00 2001
> > From: Richard Hughes <richard@hughsie.com>
> > Date: Wed, 4 Mar 2009 10:51:52 +0000
> > Subject: thinkpad-acpi: use correct key names for sleep keys in driver
> > 
> > Use the new key KEY_HIBERNATE and correct the use of KEY_SUSPEND.
> > 
> > KEY_HIBERNATE is used when the decal on the key indicates sleep to disk,
> > KEY_SUSPEND is used when the decal indicates sleep to memory, and
> > KEY_SLEEP is used when the sleep type is unknown or unspecified
> > 
> > We've already converted Xorg, HAL, and most of userspace to use the same names.
> > 
> > With this patch, the sleep keys can be labeled consistently all the way
> > through the stack. More patches to other device drivers are to follow.
> > 
> > Signed-off-by: Richard Hughes <hughsient@gmail.com>
> 
> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

It seems that this patch is still not in master?

Currently (on debian unstable), input-events reports on my T61:

KEY_SLEEP for Fn+F4
KEY_SUSPEND for Fn+F12

which kind-of breaks xfce4-power-manager, where SLEEP and SUSPEND both
suspend to ram, so I don't have any way to hibernate. Changing xfpm
doesn't seem like a good idea if the way to go is to use SUSPEND for
STR, HIBERNATE for STD and SLEEP for either.

So what's the status for this?

> 
> > ---
> >  drivers/platform/x86/thinkpad_acpi.c |    8 ++++----
> >  1 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> > index bcbc051..d89015d 100644
> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > @@ -2241,9 +2241,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
> >  	 */
> >  	static u16 ibm_keycode_map[] __initdata = {
> >  		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> > -		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SLEEP,
> > +		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SUSPEND,
> >  		KEY_WLAN,	KEY_FN_F6, KEY_SWITCHVIDEOMODE, KEY_FN_F8,
> > -		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
> > +		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_HIBERNATE,
> >  
> >  		/* Scan codes 0x0C to 0x1F: Other ACPI HKEY hot keys */
> >  		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
> > @@ -2277,9 +2277,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
> >  	};
> >  	static u16 lenovo_keycode_map[] __initdata = {
> >  		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> > -		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SLEEP,
> > +		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SUSPEND,
> >  		KEY_WLAN,	KEY_FN_F6, KEY_SWITCHVIDEOMODE, KEY_FN_F8,
> > -		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
> > +		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_HIBERNATE,
> >  
> >  		/* Scan codes 0x0C to 0x1F: Other ACPI HKEY hot keys */
> >  		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
> 
> 
Cheers,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Matthew Garrett]

On Tue, Aug 18, 2009 at 10:02:10PM +0200, Yves-Alexis Perez wrote:

> It seems that this patch is still not in master?

Correct. We can't change the existing semantics without breaking 
existing userspace applications.

> Currently (on debian unstable), input-events reports on my T61:
> 
> KEY_SLEEP for Fn+F4
> KEY_SUSPEND for Fn+F12
>
> which kind-of breaks xfce4-power-manager, where SLEEP and SUSPEND both
> suspend to ram, so I don't have any way to hibernate. Changing xfpm
> doesn't seem like a good idea if the way to go is to use SUSPEND for
> STR, HIBERNATE for STD and SLEEP for either.
> 
> So what's the status for this?

KEY_SLEEP is suspend to RAM, KEY_SUSPEND is suspend to disk. xfpm should 
be changed to match.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On mar, 2009-08-18 at 21:10 +0100, Matthew Garrett wrote:
> 
> > It seems that this patch is still not in master?
> 
> Correct. We can't change the existing semantics without breaking 
> existing userspace applications.

Hmh ok, but is it planned?
> 
> > Currently (on debian unstable), input-events reports on my T61:
> > 
> > KEY_SLEEP for Fn+F4
> > KEY_SUSPEND for Fn+F12
> >
> > which kind-of breaks xfce4-power-manager, where SLEEP and SUSPEND
> both
> > suspend to ram, so I don't have any way to hibernate. Changing xfpm
> > doesn't seem like a good idea if the way to go is to use SUSPEND for
> > STR, HIBERNATE for STD and SLEEP for either.
> > 
> > So what's the status for this?
> 
> KEY_SLEEP is suspend to RAM, KEY_SUSPEND is suspend to disk. xfpm should 
> be changed to match.
> 
Ok, I'm CC:ing the developer to let him know.

Cheers,

-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Matthew Garrett]

On Tue, Aug 18, 2009 at 10:27:10PM +0200, Yves-Alexis Perez wrote:
> On mar, 2009-08-18 at 21:10 +0100, Matthew Garrett wrote:
> > 
> > > It seems that this patch is still not in master?
> > 
> > Correct. We can't change the existing semantics without breaking 
> > existing userspace applications.
> 
> Hmh ok, but is it planned?

No. We'd break userspace.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Henrique de Moraes Holschuh]

On Tue, 18 Aug 2009, Matthew Garrett wrote:
> On Tue, Aug 18, 2009 at 10:27:10PM +0200, Yves-Alexis Perez wrote:
> > On mar, 2009-08-18 at 21:10 +0100, Matthew Garrett wrote:
> > > 
> > > > It seems that this patch is still not in master?
> > > 
> > > Correct. We can't change the existing semantics without breaking 
> > > existing userspace applications.
> > 
> > Hmh ok, but is it planned?
> 
> No. We'd break userspace.

Indeed.  I am not merging any changes to SUSPEND/HIBERNATE keymaps,
until some interested party comes up with a PROPER migration plan and
helps implementing it across the entire kernel and userspace.

This obviously mean new keycodes for S3 and S4-specific sleep, that
won't change the meaning of the old ones.  There is also the generic
(whatever the system think its best) sleep.

X.org's braindead limit of 255 keycodes won't help any.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Ali Abdallah]

Yves-Alexis Perez wrote:
> On mar, 2009-08-18 at 21:10 +0100, Matthew Garrett wrote:
>   
>>> It seems that this patch is still not in master?
>>>       
>> Correct. We can't change the existing semantics without breaking 
>> existing userspace applications.
>>     
>
> Hmh ok, but is it planned?
>   
>>> Currently (on debian unstable), input-events reports on my T61:
>>>
>>> KEY_SLEEP for Fn+F4
>>> KEY_SUSPEND for Fn+F12
>>>
>>> which kind-of breaks xfce4-power-manager, where SLEEP and SUSPEND
>>>       
>> both
>>     
>>> suspend to ram, so I don't have any way to hibernate. Changing xfpm
>>> doesn't seem like a good idea if the way to go is to use SUSPEND for
>>> STR, HIBERNATE for STD and SLEEP for either.
>>>
>>> So what's the status for this?
>>>       
>> KEY_SLEEP is suspend to RAM, KEY_SUSPEND is suspend to disk. xfpm should 
>> be changed to match.
>>
>>     
> Ok, I'm CC:ing the developer to let him know.
>
> Cheers,
>
>   

Dunno if i should ask the question here, now gpm relies completely on X 
to map these buttons, in X there is:

HAVE_XF86XK_SLEEP  (Suspend).

HAVE_XF86XK_HIBERNATE
HAVE_XF86XK_SUSPEND

As i understood These two buttons are suspend two disk, okay, so they 
should have the same keycode right?, or can they be two different keys?

Cheers And thanks,
Ali.

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Yves-Alexis Perez]

On mar, 2009-08-18 at 21:10 +0100, Matthew Garrett wrote:
> > So what's the status for this?
> 
> KEY_SLEEP is suspend to RAM, KEY_SUSPEND is suspend to disk. xfpm should 
> be changed to match.

Hmh, there's something weird.

In /usr/include/X11/XF86keysym.h we can see:

#define XF86XK_Suspend    0x1008FFA7   /* Sleep to RAM                */        
#define XF86XK_Hibernate  0x1008FFA8   /* Sleep to disk               */

So (some) userspace seems to have switched already?

Cheers,
-- 
Yves-Alexis

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Matthew Garrett]

On Wed, Aug 26, 2009 at 01:36:14PM +0200, Yves-Alexis Perez wrote:

> #define XF86XK_Suspend    0x1008FFA7   /* Sleep to RAM                */        
> #define XF86XK_Hibernate  0x1008FFA8   /* Sleep to disk               */
> 
> So (some) userspace seems to have switched already?

Adding those keysyms was, with hindsight, an error.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

On mer, 2009-08-26 at 14:43 +0100, Matthew Garrett wrote:
> On Wed, Aug 26, 2009 at 01:36:14PM +0200, Yves-Alexis Perez wrote:
> 
> > #define XF86XK_Suspend    0x1008FFA7   /* Sleep to RAM                */        
> > #define XF86XK_Hibernate  0x1008FFA8   /* Sleep to disk               */
> > 
> > So (some) userspace seems to have switched already?
> 
> Adding those keysyms was, with hindsight, an error.

Ok, so every userland app which began the transition should step back
until a correct migration plan is set up?

Are X people aware of that and will they step back? What should we do so
it works on most system? Now that things have started to move wouldn't
it make sense to keep going?

Sorry, I'm a bit lost and I think xfce4-power-manager upstream is too…

Cheers,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Henrique de Moraes Holschuh]

On Wed, 26 Aug 2009, Yves-Alexis Perez wrote:
> On mer, 2009-08-26 at 14:43 +0100, Matthew Garrett wrote:
> > On Wed, Aug 26, 2009 at 01:36:14PM +0200, Yves-Alexis Perez wrote:
> > > #define XF86XK_Suspend    0x1008FFA7   /* Sleep to RAM                */        
> > > #define XF86XK_Hibernate  0x1008FFA8   /* Sleep to disk               */
> > > 
> > > So (some) userspace seems to have switched already?
> > 
> > Adding those keysyms was, with hindsight, an error.
> 
> Ok, so every userland app which began the transition should step back
> until a correct migration plan is set up?

IMHO it would be both easier and faster to deploy a proper migration plan
and keep going.  Nobody said the names used by X.org keysyms have to agree
with the ones used by input devices, for example... and a mapping table is
already used anyway.

So, userspace can use the X keysyms like the above. There's nothing wrong
with it.  But the correct mapping for kernel input events to those keysyms
is AND WILL REMAIN:

KEY_SLEEP -> XF86XK_Suspend
KEY_SUSPEND -> XF86XK_Hibernate

If people want to define two new input events, say KEY_SUSPENDTORAM and
KEY_SUSPENDTODISK, start migrating the kernel drivers to use these two, and
after some time with no use of KEY_SLEEP in the kernel, reclaim it to
be a generic "sleep the system in some unspecified way", I'd be fine with
it.

So, you'd have:
KEY_SLEEP -> XF86XK_Suspend
KEY_SUSPENDTORAM -> XF86XK_Suspend
KEY_SUSPEND -> XF86XK_Hibernate
KEY_SUSPENDTODISK -> XF86XK_Hibernate

I'd guess the only thing that could make us break that ABI the way people
wanted us to (i.e. change the meaning of KEY_SUSPEND and KEY_SLEEP, and add
a new KEY_HIBERNATE), is a proof that we got the USB HID table wrong and
that USB keyboards are doing the wrong thing because of it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Dmitry Torokhov]

On Wed, Aug 26, 2009 at 07:51:11PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 26 Aug 2009, Yves-Alexis Perez wrote:
> > On mer, 2009-08-26 at 14:43 +0100, Matthew Garrett wrote:
> > > On Wed, Aug 26, 2009 at 01:36:14PM +0200, Yves-Alexis Perez wrote:
> > > > #define XF86XK_Suspend    0x1008FFA7   /* Sleep to RAM                */        
> > > > #define XF86XK_Hibernate  0x1008FFA8   /* Sleep to disk               */
> > > > 
> > > > So (some) userspace seems to have switched already?
> > > 
> > > Adding those keysyms was, with hindsight, an error.
> > 
> > Ok, so every userland app which began the transition should step back
> > until a correct migration plan is set up?
> 
> IMHO it would be both easier and faster to deploy a proper migration plan
> and keep going.  Nobody said the names used by X.org keysyms have to agree
> with the ones used by input devices, for example... and a mapping table is
> already used anyway.
> 
> So, userspace can use the X keysyms like the above. There's nothing wrong
> with it.  But the correct mapping for kernel input events to those keysyms
> is AND WILL REMAIN:
> 
> KEY_SLEEP -> XF86XK_Suspend
> KEY_SUSPEND -> XF86XK_Hibernate
> 
> If people want to define two new input events, say KEY_SUSPENDTORAM and
> KEY_SUSPENDTODISK, start migrating the kernel drivers to use these two, and
> after some time with no use of KEY_SLEEP in the kernel, reclaim it to
> be a generic "sleep the system in some unspecified way", I'd be fine with
> it.
> 
> So, you'd have:
> KEY_SLEEP -> XF86XK_Suspend
> KEY_SUSPENDTORAM -> XF86XK_Suspend
> KEY_SUSPEND -> XF86XK_Hibernate
> KEY_SUSPENDTODISK -> XF86XK_Hibernate
> 
> I'd guess the only thing that could make us break that ABI the way people
> wanted us to (i.e. change the meaning of KEY_SUSPEND and KEY_SLEEP, and add
> a new KEY_HIBERNATE), is a proof that we got the USB HID table wrong and
> that USB keyboards are doing the wrong thing because of it.
> 

Would not it be easier just to adjust HID in this case?

-- 
Dmitry

Re: [PATCH] thinkpad-acpi: use correct key names for sleep states in driver

[Henrique de Moraes Holschuh]

On Wed, 26 Aug 2009, Dmitry Torokhov wrote:
> On Wed, Aug 26, 2009 at 07:51:11PM -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 26 Aug 2009, Yves-Alexis Perez wrote:
> > > On mer, 2009-08-26 at 14:43 +0100, Matthew Garrett wrote:
> > > > On Wed, Aug 26, 2009 at 01:36:14PM +0200, Yves-Alexis Perez wrote:
> > > > > #define XF86XK_Suspend    0x1008FFA7   /* Sleep to RAM                */        
> > > > > #define XF86XK_Hibernate  0x1008FFA8   /* Sleep to disk               */
> > > > > 
> > > > > So (some) userspace seems to have switched already?
> > > > 
> > > > Adding those keysyms was, with hindsight, an error.
> > > 
> > > Ok, so every userland app which began the transition should step back
> > > until a correct migration plan is set up?
> > 
> > IMHO it would be both easier and faster to deploy a proper migration plan
> > and keep going.  Nobody said the names used by X.org keysyms have to agree
> > with the ones used by input devices, for example... and a mapping table is
> > already used anyway.
> > 
> > So, userspace can use the X keysyms like the above. There's nothing wrong
> > with it.  But the correct mapping for kernel input events to those keysyms
> > is AND WILL REMAIN:
> > 
> > KEY_SLEEP -> XF86XK_Suspend
> > KEY_SUSPEND -> XF86XK_Hibernate
> > 
> > If people want to define two new input events, say KEY_SUSPENDTORAM and
> > KEY_SUSPENDTODISK, start migrating the kernel drivers to use these two, and
> > after some time with no use of KEY_SLEEP in the kernel, reclaim it to
> > be a generic "sleep the system in some unspecified way", I'd be fine with
> > it.
> > 
> > So, you'd have:
> > KEY_SLEEP -> XF86XK_Suspend
> > KEY_SUSPENDTORAM -> XF86XK_Suspend
> > KEY_SUSPEND -> XF86XK_Hibernate
> > KEY_SUSPENDTODISK -> XF86XK_Hibernate
> > 
> > I'd guess the only thing that could make us break that ABI the way people
> > wanted us to (i.e. change the meaning of KEY_SUSPEND and KEY_SLEEP, and add
> > a new KEY_HIBERNATE), is a proof that we got the USB HID table wrong and
> > that USB keyboards are doing the wrong thing because of it.
> 
> Would not it be easier just to adjust HID in this case?

Your call.  I really don't know what the USB HID spec wants KEY_foo to mean,
and I don't know if we got it wrong or not.  I know I used KEY_SLEEP and
KEY_SUSPEND in thinkpad-acpi because those are the mappings the rest of the
kernel uses.  The thinkpad hotkeys *do* have sleep-to-ram and sleep-to-disk
context, they're not generic "sleep" keys.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend / hibernate nomenclature

[Andrey Borzenkov]

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.

Re: suspend / hibernate nomenclature

[Matthew Garrett]

On Mon, Mar 02, 2009 at 11:13:49AM +0000, Richard Hughes wrote:

> 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.

KEY_SUSPEND has always been pretty clearly used for hibernate for, well, 
forever. I don't think the distinction is a useful one. How many 
machines are going to have both a sleep and a suspend key?

This is a user-visible change in behaviour. I think we're too entrenched 
for it to make much of a difference now. Adding a #define KEY_HIBERNATE 
KEY_SUSPEND sounds fine to me, but I really don't think we need anything 
more.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: suspend / hibernate nomenclature

[Henrique de Moraes Holschuh]

On Sat, 07 Mar 2009, Matthew Garrett wrote:
> On Mon, Mar 02, 2009 at 11:13:49AM +0000, Richard Hughes wrote:
> > 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.
> 
> KEY_SUSPEND has always been pretty clearly used for hibernate for, well, 
> forever. I don't think the distinction is a useful one. How many 
> machines are going to have both a sleep and a suspend key?

All machines with a standard crappy PeeCee keyboard with the moon key
have a KEY_SLEEP key, and you can plug a PeeCee USB keyboard in just
about anything nowadays... including on thinkpads, which have a key
that is specific for S4, and one that is specific for S3 in their
internal keyboards.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend / hibernate nomenclature

[Matthew Garrett]

On Sat, Mar 07, 2009 at 01:41:51PM -0300, Henrique de Moraes Holschuh wrote:

> All machines with a standard crappy PeeCee keyboard with the moon key
> have a KEY_SLEEP key, and you can plug a PeeCee USB keyboard in just
> about anything nowadays... including on thinkpads, which have a key
> that is specific for S4, and one that is specific for S3 in their
> internal keyboards.

And is this really common enough that it's worth breaking existing 
userland?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: suspend / hibernate nomenclature

[Henrique de Moraes Holschuh]

On Sat, 07 Mar 2009, Matthew Garrett wrote:
> On Sat, Mar 07, 2009 at 01:41:51PM -0300, Henrique de Moraes Holschuh wrote:
> > All machines with a standard crappy PeeCee keyboard with the moon key
> > have a KEY_SLEEP key, and you can plug a PeeCee USB keyboard in just
> > about anything nowadays... including on thinkpads, which have a key
> > that is specific for S4, and one that is specific for S3 in their
> > internal keyboards.
> 
> And is this really common enough that it's worth breaking existing 
> userland?

THAT I don't know.  In fact, I have no idea if there is or is not a
proper deploying plan in place in the userland side of things.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend / hibernate nomenclature

[Richard Hughes]

On Sat, Mar 7, 2009 at 4:48 PM, Matthew Garrett <mjg@redhat.com> wrote:
> On Sat, Mar 07, 2009 at 01:41:51PM -0300, Henrique de Moraes Holschuh wrote:
>
>> All machines with a standard crappy PeeCee keyboard with the moon key
>> have a KEY_SLEEP key, and you can plug a PeeCee USB keyboard in just
>> about anything nowadays... including on thinkpads, which have a key
>> that is specific for S4, and one that is specific for S3 in their
>> internal keyboards.
>
> And is this really common enough that it's worth breaking existing
> userland?

Xorg and evdev already does the right thing, we have XF86Hibernate
now. All I have to do is patch HAL to check the kernel version and
then everything in userspace we care about should just work. We have
to sort out the insane mappings sooner or later, and what I've put in
linux-next seems to be the right way of dong this, rather than the way
things used to be (suspend -> hibernate, sleep->suspend,
standby->sleep). I'm fed up of debugging why sleep buttons don't work
right in userspace when the kernel isn't sure what button to emit.

Richard.

Re: suspend / hibernate nomenclature

[Matthew Garrett]

On Sat, Mar 07, 2009 at 08:25:27PM +0000, Richard Hughes wrote:

> Xorg and evdev already does the right thing, we have XF86Hibernate
> now. All I have to do is patch HAL to check the kernel version and
> then everything in userspace we care about should just work. We have
> to sort out the insane mappings sooner or later, and what I've put in
> linux-next seems to be the right way of dong this, rather than the way
> things used to be (suspend -> hibernate, sleep->suspend,
> standby->sleep). I'm fed up of debugging why sleep buttons don't work
> right in userspace when the kernel isn't sure what button to emit.

We don't have to at all - as far as I've been able to tell, the kernel 
is utterly consistent in its current usage. The only drivers that emit 
KEY_SLEEP are either embedded-specific (where it's clearly suspend to 
RAM and not hibernate), the ACPI driver (where usage in other operating 
systems is consistent with it being suspent to RAM) and the panasonic 
and thinkpad drivers which use it consistently. If there's any 
confusion, it's over the fact that KEY_SUSPEND is is used for suspend to 
RAM in a (smaller) number of places.

I'd suggest reverting these current patches and doing something like the 
following and then changing any drivers where it's worth clarifying 
things. This has exactly the same effect with the advantage that no 
userspace needs to be changed.

diff --git a/include/linux/input.h b/include/linux/input.h
index 1249a0c..90abe27 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -263,7 +263,7 @@ struct input_absinfo {
 #define KEY_MENU		139	/* Menu (show menu) */
 #define KEY_CALC		140	/* AL Calculator */
 #define KEY_SETUP		141
-#define KEY_SLEEP		142	/* SC System Sleep */
+#define KEY_SUSPEND_TO_RAM	142	/* SC System Sleep */
 #define KEY_WAKEUP		143	/* System Wake Up */
 #define KEY_FILE		144	/* AL Local Machine Browser */
 #define KEY_SENDFILE		145
@@ -324,7 +324,7 @@ struct input_absinfo {
 #define KEY_PROG3		202
 #define KEY_PROG4		203
 #define KEY_DASHBOARD		204	/* AL Dashboard */
-#define KEY_SUSPEND		205
+#define KEY_HIBERNATE		205
 #define KEY_CLOSE		206	/* AC Close */
 #define KEY_PLAY		207
 #define KEY_FASTFORWARD		208
@@ -377,6 +377,10 @@ struct input_absinfo {
 
 /* Range 248 - 255 is reserved for special needs of AT keyboard driver */
 
+/* Deprecated - use KEY_SUSPEND_TO_RAM and KEY_HIBERNATE instead */
+#define KEY_SLEEP		KEY_SUSPEND_TO_RAM
+#define KEY_SUSPEND		KEY_HIBERNATE
+
 #define BTN_MISC		0x100
 #define BTN_0			0x100
 #define BTN_1			0x101

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: suspend / hibernate nomenclature

[Richard Hughes]

On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett <mjg@redhat.com> wrote:
> We don't have to at all - as far as I've been able to tell, the kernel
> is utterly consistent in its current usage. The only drivers that emit
> KEY_SLEEP are either embedded-specific (where it's clearly suspend to
> RAM and not hibernate), the ACPI driver (where usage in other operating
> systems is consistent with it being suspent to RAM) and the panasonic
> and thinkpad drivers which use it consistently. If there's any
> confusion, it's over the fact that KEY_SUSPEND is is used for suspend to
> RAM in a (smaller) number of places.

The fact that we're mapping x->y and y->x is the reason people keep
getting it wrong.

> I'd suggest reverting these current patches and doing something like the
> following and then changing any drivers where it's worth clarifying
> things. This has exactly the same effect with the advantage that no
> userspace needs to be changed.

So how do we specify a sleep button where policy is to be decided by
userspace? For instance, the sleep button on a remote control? Do we
hardcode policy in the kernel?

> -#define KEY_SLEEP              142     /* SC System Sleep */
> +#define KEY_SUSPEND_TO_RAM     142     /* SC System Sleep */

I deliberately avoided using the terms DISK and RAM in the key defines
used in my patch.

> +/* Deprecated - use KEY_SUSPEND_TO_RAM and KEY_HIBERNATE instead */
> +#define KEY_SLEEP              KEY_SUSPEND_TO_RAM
> +#define KEY_SUSPEND            KEY_HIBERNATE

Yet more confusion. Can't we sort this mess out once and for all? If
you're that bothered about userspace using the bodged mappings, I
would suggest changing my patch so that KEY_SLEEP is 247,
KEY_HIBERNATE is 205 and KEY_SUSPEND is 142.

Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend / hibernate nomenclature

[Matthew Garrett]

On Sun, Mar 08, 2009 at 08:45:59AM +0000, Richard Hughes wrote:
> On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett <mjg@redhat.com> wrote:
> > We don't have to at all - as far as I've been able to tell, the kernel
> > is utterly consistent in its current usage. The only drivers that emit
> > KEY_SLEEP are either embedded-specific (where it's clearly suspend to
> > RAM and not hibernate), the ACPI driver (where usage in other operating
> > systems is consistent with it being suspent to RAM) and the panasonic
> > and thinkpad drivers which use it consistently. If there's any
> > confusion, it's over the fact that KEY_SUSPEND is is used for suspend to
> > RAM in a (smaller) number of places.
> 
> The fact that we're mapping x->y and y->x is the reason people keep
> getting it wrong.

Sure, doing things differently would have made sense several years ago 
when nobody was relying on this behaviour. We don't have that option now 
- making this change will break things, and we've got no idea how much 
it'll break.

> > I'd suggest reverting these current patches and doing something like the
> > following and then changing any drivers where it's worth clarifying
> > things. This has exactly the same effect with the advantage that no
> > userspace needs to be changed.
> 
> So how do we specify a sleep button where policy is to be decided by
> userspace? For instance, the sleep button on a remote control? Do we
> hardcode policy in the kernel?

Just carry on using KEY_SLEEP for that. We've already got the UI for it.

> > -#define KEY_SLEEP              142     /* SC System Sleep */
> > +#define KEY_SUSPEND_TO_RAM     142     /* SC System Sleep */
> 
> I deliberately avoided using the terms DISK and RAM in the key defines
> used in my patch.

Why? This isn't user-visible. The aim is to reduce confusion amongst 
driver authors, not be consistent with userspace terminology.

> > +/* Deprecated - use KEY_SUSPEND_TO_RAM and KEY_HIBERNATE instead */
> > +#define KEY_SLEEP              KEY_SUSPEND_TO_RAM
> > +#define KEY_SUSPEND            KEY_HIBERNATE
> 
> Yet more confusion. Can't we sort this mess out once and for all? If
> you're that bothered about userspace using the bodged mappings, I
> would suggest changing my patch so that KEY_SLEEP is 247,
> KEY_HIBERNATE is 205 and KEY_SUSPEND is 142.

No, then the behaviour of userspace would depend on whether it had been 
recompiled or not.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend / hibernate nomenclature

[Rafael J. Wysocki]

On Sunday 08 March 2009, Matthew Garrett wrote:
> On Sun, Mar 08, 2009 at 08:45:59AM +0000, Richard Hughes wrote:
> > On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett <mjg@redhat.com> wrote:
> > > We don't have to at all - as far as I've been able to tell, the kernel
> > > is utterly consistent in its current usage. The only drivers that emit
> > > KEY_SLEEP are either embedded-specific (where it's clearly suspend to
> > > RAM and not hibernate), the ACPI driver (where usage in other operating
> > > systems is consistent with it being suspent to RAM) and the panasonic
> > > and thinkpad drivers which use it consistently. If there's any
> > > confusion, it's over the fact that KEY_SUSPEND is is used for suspend to
> > > RAM in a (smaller) number of places.
> > 
> > The fact that we're mapping x->y and y->x is the reason people keep
> > getting it wrong.
> 
> Sure, doing things differently would have made sense several years ago 
> when nobody was relying on this behaviour. We don't have that option now 
> - making this change will break things, and we've got no idea how much 
> it'll break.

Which is a good enough reason to avoid it.

Alternatively, we can add completely new definitions _along_ _with_ the old
ones, mark the old ones as obsolete (after some time) and try to make the
user space start using the new ones only (that may be difficult, though).

I said I liked the names, but I didn't realize that changing them would break
things.

Thanks,
Rafael

Re: suspend / hibernate nomenclature

[Dmitry Torokhov]

On Sun, Mar 08, 2009 at 09:56:45PM +0100, Rafael J. Wysocki wrote:
> On Sunday 08 March 2009, Matthew Garrett wrote:
> > On Sun, Mar 08, 2009 at 08:45:59AM +0000, Richard Hughes wrote:
> > > On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett <mjg@redhat.com> wrote:
> > > > We don't have to at all - as far as I've been able to tell, the kernel
> > > > is utterly consistent in its current usage. The only drivers that emit
> > > > KEY_SLEEP are either embedded-specific (where it's clearly suspend to
> > > > RAM and not hibernate), the ACPI driver (where usage in other operating
> > > > systems is consistent with it being suspent to RAM) and the panasonic
> > > > and thinkpad drivers which use it consistently. If there's any
> > > > confusion, it's over the fact that KEY_SUSPEND is is used for suspend to
> > > > RAM in a (smaller) number of places.
> > > 
> > > The fact that we're mapping x->y and y->x is the reason people keep
> > > getting it wrong.
> > 
> > Sure, doing things differently would have made sense several years ago 
> > when nobody was relying on this behaviour. We don't have that option now 
> > - making this change will break things, and we've got no idea how much 
> > it'll break.
> 
> Which is a good enough reason to avoid it.
> 
> Alternatively, we can add completely new definitions _along_ _with_ the old
> ones, mark the old ones as obsolete (after some time) and try to make the
> user space start using the new ones only (that may be difficult, though).
> 
> I said I liked the names, but I didn't realize that changing them would break
> things.
> 

I don't think we want to break anything if we can help it. The problem
with Richard's patch is that it changes meaning of KEY_SUSPEND from STD
to STR. I would prefer if we could do the following:

- KEY_SLEEP - leave the keycode, the action should be the default
system state defined by either platform or user. I expect that the vast
majority of system have default state similar to S3 so there should not
be anysurprises.

- KEY_SUSPEND - provide better comment for its intended usage and maybe
add KEY_HIBERNATE alias.

- KEY_SUSPEND2RAM - add a new definition.

Do you think this would this work?

I intend to back out the patch in question for the time being.

Thanks.

-- 
Dmitry

Re: suspend / hibernate nomenclature

[Matthew Garrett]

On Sun, Mar 08, 2009 at 04:07:50PM -0700, Dmitry Torokhov wrote:

> - KEY_SLEEP - leave the keycode, the action should be the default
> system state defined by either platform or user. I expect that the vast
> majority of system have default state similar to S3 so there should not
> be anysurprises.
> 
> - KEY_SUSPEND - provide better comment for its intended usage and maybe
> add KEY_HIBERNATE alias.
> 
> - KEY_SUSPEND2RAM - add a new definition.
> 
> Do you think this would this work?

I think that would be fine, though I'm not entirely convinced that we 
need KEY_SUSPEND2RAM as a separate keycode.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: suspend / hibernate nomenclature

[Ville Syrjälä]

On Sun, Mar 08, 2009 at 11:19:35PM +0000, Matthew Garrett wrote:
> On Sun, Mar 08, 2009 at 04:07:50PM -0700, Dmitry Torokhov wrote:
> 
> > - KEY_SLEEP - leave the keycode, the action should be the default
> > system state defined by either platform or user. I expect that the vast
> > majority of system have default state similar to S3 so there should not
> > be anysurprises.
> > 
> > - KEY_SUSPEND - provide better comment for its intended usage and maybe
> > add KEY_HIBERNATE alias.
> > 
> > - KEY_SUSPEND2RAM - add a new definition.
> > 
> > Do you think this would this work?
> 
> I think that would be fine, though I'm not entirely convinced that we 
> need KEY_SUSPEND2RAM as a separate keycode.

If you think this using common sense I think the following would be the
most obvious mapping:
sleep = STR, hibernate = STD, suspend = preferred suspend mode

Both sleep and hibernate are biological processes and the difference
between them should be obvious for everyone. Suspend on that other hand
just says that your work is suspended.

I don't know if common sense has any room in these discussions though.

I would at least avoid mixing the suspend2ram and hibernate definitions.
The first one comes from the technical aspect and the second comes from
the biological aspect so mixing them IMO just creates more confusion.

Of course the API is a technical thing anyway so perhaps just go for
something explicit like suspend2ram, suspend2disk and suspend2preferred.
The old definitions would of course need to be mapped to the new
definitions somehow.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend / hibernate nomenclature

[Matthew Garrett]

On Mon, Mar 09, 2009 at 03:52:42PM +0200, Ville Syrjälä wrote:

> If you think this using common sense I think the following would be the
> most obvious mapping:
> sleep = STR, hibernate = STD, suspend = preferred suspend mode

I agree, but this isn't a discussion about user-visible nomenclature - 
it's a discussion about using the keycodes we have in the kernel. The 
aim is to ensure that everyone in-kernel uses the correct codes, and if 
we can do that without breaking existing userspace (even if it means the 
nomenclature differs) then that's preferable.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend / hibernate nomenclature

[Ville Syrjälä]

On Mon, Mar 09, 2009 at 02:00:09PM +0000, Matthew Garrett wrote:
> On Mon, Mar 09, 2009 at 03:52:42PM +0200, Ville Syrjälä wrote:
> 
> > If you think this using common sense I think the following would be the
> > most obvious mapping:
> > sleep = STR, hibernate = STD, suspend = preferred suspend mode
> 
> I agree, but this isn't a discussion about user-visible nomenclature - 
> it's a discussion about using the keycodes we have in the kernel. The 
> aim is to ensure that everyone in-kernel uses the correct codes, and if 
> we can do that without breaking existing userspace (even if it means the 
> nomenclature differs) then that's preferable.

I don't think that invalidates my point. There's always the possibility
of re-creating the same mess in the future if the definitions aren't
crystal clear. The less room there is for personal interpretation of the
definitions the better.

I understand that backwards compatibility is critical but perhaps that
is reason enough to create a completely a new set of definitions and
just map the old definitions in the best way possible.

Something like this?
KEY_SUSPEND_TO_RAM
KEY_SUSPEND_TO_DISK
KEY_SUSPEND_TO_PREFERRED

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html