On Fri, 13 Jul 2012, Matthew Garrett wrote: > On Fri, Jul 13, 2012 at 03:07:38PM +0800, AceLan Kao wrote: > > There are many different events to inform the system concurrently, > > evdev is just one of them. > > I'm not sure which one trigger the system to suspend while pressing > > the suspend hotkey, but > > the following suspends are triggered by acpi proc event. > > I'm fine with killing the procfs interface (it's deprecated anyway, I > think?) but I'm a little worried about this only handling one case. Is > userspace guaranteed to ignore any further events that were delivered > over the input layer. No. Some firmware (thinkpads) even used to latch state and refuse to reissue sleep buttom events for a while... Is there any reason why we cannot do the same? Entering S3/S4 is a really good time to flush the contents of any input device and acpi [userspace] event queues at first glance... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
