On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett <mjg@xxxxxxxxxx> wrote: > We don't have to at all - as far as I've been able to tell, the kernel > is utterly consistent in its current usage. The only drivers that emit > KEY_SLEEP are either embedded-specific (where it's clearly suspend to > RAM and not hibernate), the ACPI driver (where usage in other operating > systems is consistent with it being suspent to RAM) and the panasonic > and thinkpad drivers which use it consistently. If there's any > confusion, it's over the fact that KEY_SUSPEND is is used for suspend to > RAM in a (smaller) number of places. The fact that we're mapping x->y and y->x is the reason people keep getting it wrong. > I'd suggest reverting these current patches and doing something like the > following and then changing any drivers where it's worth clarifying > things. This has exactly the same effect with the advantage that no > userspace needs to be changed. So how do we specify a sleep button where policy is to be decided by userspace? For instance, the sleep button on a remote control? Do we hardcode policy in the kernel? > -#define KEY_SLEEP 142 /* SC System Sleep */ > +#define KEY_SUSPEND_TO_RAM 142 /* SC System Sleep */ I deliberately avoided using the terms DISK and RAM in the key defines used in my patch. > +/* Deprecated - use KEY_SUSPEND_TO_RAM and KEY_HIBERNATE instead */ > +#define KEY_SLEEP KEY_SUSPEND_TO_RAM > +#define KEY_SUSPEND KEY_HIBERNATE Yet more confusion. Can't we sort this mess out once and for all? If you're that bothered about userspace using the bodged mappings, I would suggest changing my patch so that KEY_SLEEP is 247, KEY_HIBERNATE is 205 and KEY_SUSPEND is 142. Richard. -- 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
