On Sunday 26 October 2008, Rafael J. Wysocki wrote: > On Sunday, 26 of October 2008, Dmitry Torokhov wrote: > > Hi Len, > > > > On Friday 24 October 2008, Len Brown wrote: > > > Dmitry, > > > > > > Looking around the tree, the other calls to > > > input_report_switch() and input_report_key() > > > are all followed by input_sync(). > > > > > > > The idea is that userspace can accumulate input events and not act on > > them till it gets the "whole state" of the device which is indicated by > > sending EV_SYN/SYN_REPORT event. This really does not matter for most > > of the simple devices (such as most button devices) but is required > > when you need to report state of a touchpad or a tablet (ABS_X, ABS_Y, > > ABS_PRESSURE, host of buttons and so on). And that is the reason to have > > 2 input_sync when you you reporting button down and up back to back - > > if there was only one input_sync userspace may (although I don't think > > anyone does) wait to reacting till the sync and by that time the up event > > will "cancel out" the down event. > > > > > I guess we didn't understand the API when we added > > > these calls to button.c? > > > > > > > The code was fine until acpi_lid_send_state was used un resume path, > > then it needed its own input_sync. > > > > > Looks like the other users of input_report_* in > > > drivers/acpi and drivers/misc are okay, > > > with the exception of toshiba_acpi.c -- > > > the most neglected driver we have, > > > so I"ll do the same to that one? > > > > > > Ack? > > > > Yep. > > -stable material? Nah, I don't think userspace using these events actually cares so stable can stay as is. -- Dmitry -- 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
