Re: [PATCH] ACPI: Always report a sync event after a lid state change

["Rafael J. Wysocki" <rjw@sisk.pl>]

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?

Rafael