2012/7/13 Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>: > 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... thinkpads use its own thinkpad_acpi driver to handle this, it will submit events to proc acpi event by itself through acpi_bus_generate_proc_event(). And BTW, I found a ThinkPad X220 and do the test, it won't enter S3 multiple times if I press the suspend keys many times. And I try to remove thinkpad_acpi module and stop the acpid and press the button again, the system enter S3 correctly, too. So, it won't damage this function from removing proc acpi event. So, I didn't get the point why we can just remove the event, we don't rely on it to enter S3 now, and to take into account that it's deprecated since 2007(fb804714), I don't think we should do more workaround for this. -- Chia-Lin Kao(AceLan) http://blog.acelan.idv.tw/ E-Mail: acelan.kaoATcanonical.com (s/AT/@/) -- 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
