On Sun, Mar 08, 2009 at 08:45:59AM +0000, Richard Hughes wrote:

On Sat, Mar 7, 2009 at 8:39 PM, Matthew Garrett [off-list ref] wrote:

quoted

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.

Sure, doing things differently would have made sense several years ago 
when nobody was relying on this behaviour. We don't have that option now 
- making this change will break things, and we've got no idea how much 
it'll break.

quoted

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?

Just carry on using KEY_SLEEP for that. We've already got the UI for it.

quoted

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

Why? This isn't user-visible. The aim is to reduce confusion amongst 
driver authors, not be consistent with userspace terminology.

quoted

+/* 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.

No, then the behaviour of userspace would depend on whether it had been 
recompiled or not.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html