linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Len Brown <lenb@kernel.org>
Cc: Guillem Jover <guillem.jover@nokia.com>,
	linux-acpi@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH] ACPI: Always report a sync event after a lid state change
Date: Sat, 25 Oct 2008 22:03:34 -0400	[thread overview]
Message-ID: <200810252203.35219.dmitry.torokhov@gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0810241529110.3056@localhost.localdomain>

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.

> 
> 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@nokia.com>
> > ---
> >  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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 



-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2008-10-26  2:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23 21:28 [PATCH] ACPI: Always report a sync event after a lid state change Guillem Jover
2008-10-24 19:37 ` Len Brown
2008-10-26  2:03   ` Dmitry Torokhov [this message]
2008-10-26 11:00     ` Rafael J. Wysocki
2008-10-27  0:16       ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200810252203.35219.dmitry.torokhov@gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=guillem.jover@nokia.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).