| Message ID | 1236164049.3936.17.camel@hughsie-work.lan (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 */
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,
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.
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,
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.
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. -- 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
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.
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,
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.
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,
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.
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?
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.
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