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