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