On Sun, Mar 08, 2009 at 08:33:48AM +0000, Richard Hughes wrote: > On Sat, Mar 7, 2009 at 8:26 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > Mapping KEY_SUSPEND to hibernate is what we've been doing for years. > > It's what hal *still does*. > > Sure, but how much userspace now listens to HAL for these events? Xorg > and evdev has taken over that role for all the session. We can ship a > trivial patch as an fdi file to HAL to remap this if required. I've no idea. But I lean towards not gratuitously breaking it for no reason other than aesthetics. > > KEY_SLEEP has been the suspend to RAM key forever. > > Except if you're a USB keyboard. Grep through the kernel sources and > see how many drivers get this wrong. We can't map three sleep states > to two buttons in any sane way. For instance, is the sleep acpi button > supposed to trigger a suspend of hibernate? Surely this is user policy > as it is not specified on the the exterior of the machine. We do it the same way we've previously done it (and the same way it works outside the Linux world) - the "suspend to RAM" key has configurable behaviour. As far as I can tell, the USB driver does the right thing here? > > How are we supposed to perform this transition? We've no idea > > how much of userspace makes the same assumption. > > FWIW, I think emitting KEY_ events (not switch events) in HAL is crazy > as now we can just use the fixed Xorg in the session. FWIW, HAL gets > other keys wrong too, for instance KEY_BATTERY is mapped to > display_off, but nobody has noticed as we've been using Xorg since > ages. I'm happy with obvious bugs being fixed, but this isn't an obvious bug - it's purely an aesthetic issue. We don't need to draw a distinction between generic sleep and suspend to RAM keys, especially if the cost of doing so is having to fix up an undefined quantity of userspace. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
