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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
