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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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