linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: "Felipe F. Tonello" <eu@felipetonello.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] input: mt: Add helper function to send end events
Date: Wed, 1 Jan 2014 11:18:39 -0800	[thread overview]
Message-ID: <20140101191838.GA30798@core.coreip.homeip.net> (raw)
In-Reply-To: <52C43FFE.3010005@euromail.se>

On Wed, Jan 01, 2014 at 05:19:10PM +0100, Henrik Rydberg wrote:
> Hi Dmitry,
> 
> >> What problematic scenario is this supposed to solve?
> >>
> >> The 'release on suspend' is only an approximation to the 'close
> >> laptop' scenario, it is certainly not correct in the coffee table
> >> case,
> > 
> > Why would it not be correct for coffee table? Do we expect the touches
> > to remain valid while the device is asleep?
> 
> In some scenarios with placed objects (like a cup or a marker), that would be
> the case, yes.
> 
> >> for instance. Instead of
> >> hardcoding this in the kernel, userland can easily detect long intervals
> >> directly using the event time.
> > 
> > But with slots it is not only problem with old events being sent out
> > later, it is that we have mix of old (pre-sleep) and new state.
> 
> The new state is not really a problem, it will look exactly the same regardless
> of how 'old' releases are handled.
> 
> > We do that for keys (release them when we transition to system sleep)
> > and I think it might be worthwhile to do the same for touch data.
> 
> I agree that keyboard applications seldom look at time intervals and hence are
> well helped by such a strategy, even though it is not strictly 'correct'.
> However, touch interfaces are quite dependent on time intervals, and it
> therefore makes a lot of sense to resolve touch timeouts directly in the
> application. It also puts less restrictions on what can be done.
> 
> Regarding notifications in general, perhaps it would be interesting to be able
> to send a notification event via the input interface when a device comes back
> from sleep. It could help resolve other complex issues, if there were any.
> 

OK, fair enough. If there is a demand we could send SYN_SYSTEM_RESUME
event though the interfaces to allow clients "flush" the state or
otherwise decide if new touch data is actually old touches that were
there pre-suspend.

Felipe, will that help in your case?

Thanks.

-- 
Dmitry

  reply	other threads:[~2014-01-01 19:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-31  2:06 [PATCH 0/2] input: mt: Add helper function to send end events Felipe F. Tonello
2013-12-31  2:06 ` [PATCH 1/2] " Felipe F. Tonello
2013-12-31  2:06 ` [PATCH 2/2] input: egalax: report end state in suspend callback Felipe F. Tonello
2013-12-31  9:26 ` [PATCH 0/2] input: mt: Add helper function to send end events Henrik Rydberg
2013-12-31 18:50   ` Dmitry Torokhov
2014-01-01 16:19     ` Henrik Rydberg
2014-01-01 19:18       ` Dmitry Torokhov [this message]
2014-01-02 23:20         ` Felipe Ferreri Tonello

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=20140101191838.GA30798@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=eu@felipetonello.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rydberg@euromail.se \
    /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).