Dmitry, Looking around the tree, the other calls to input_report_switch() and input_report_key() are all followed by input_sync(). I guess we didn't understand the API when we added these calls to button.c? 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? thanks, -Len On Fri, 24 Oct 2008, Guillem Jover wrote: > Currently not always an EV_SYN event is reported to userland > after the EV_SW SW_LID event has been sent. This is easy to verify > by using “input-events” from input-utils and just closing and opening > the lid. > > Signed-off-by: Guillem Jover <guillem.jover@xxxxxxxxx> > --- > drivers/acpi/button.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c > index 1dfec41..59352d9 100644 > --- a/drivers/acpi/button.c > +++ b/drivers/acpi/button.c > @@ -262,6 +262,7 @@ static int acpi_lid_send_state(struct acpi_button *button) > return -ENODEV; > /* input layer checks if event is redundant */ > input_report_switch(button->input, SW_LID, !state); > + input_sync(button->input); > return 0; > } > > @@ -285,8 +286,8 @@ static void acpi_button_notify(acpi_handle handle, u32 event, void *data) > input_report_key(input, keycode, 1); > input_sync(input); > input_report_key(input, keycode, 0); > + input_sync(input); > } > - input_sync(input); > > acpi_bus_generate_proc_event(button->device, event, > ++button->pushed); > -- > 1.6.0.2 > > -- > 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 >
