From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>,
Henrik Rydberg <rydberg@bitmath.org>,
Jiri Kosina <jkosina@suse.cz>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] Input - mt: Fix input_mt_get_slot_by_key
Date: Thu, 23 Apr 2015 11:47:09 -0700 [thread overview]
Message-ID: <20150423184709.GG34808@dtor-ws> (raw)
In-Reply-To: <20150423183827.GA10937@mail.corp.redhat.com>
On Thu, Apr 23, 2015 at 02:38:27PM -0400, Benjamin Tissoires wrote:
> On Apr 23 2015 or thereabouts, Dmitry Torokhov wrote:
> > On Thu, Apr 23, 2015 at 07:10:55PM +0200, Henrik Rydberg wrote:
> > > > "Creation, replacement and destruction of contacts is achieved by
> > > > modifying the ABS_MT_TRACKING_ID of the associated slot. A
> > > > non-negative tracking id is interpreted as a contact, and the value -1
> > > > denotes an unused slot. A tracking id not previously present is
> > > > considered new, and a tracking id no longer present is considered
> > > > removed."
> > > >
> > > > If some userspace is confused with missing -1 tracking ID for that
> > > > slot, that userspace should be fixed.
> > >
> > > I agree. Some userland applications work with add/remove out of convenience, and
> > > cannot handle the more compressed notation the kernel slot handling allows.
> > > Fixing those applications will be a good thing.
> > >
> > > Unfortunately the patch already appeared in Linus' tree...
> >
> > It's in 4.1-rc0 so we can just revert it.
> >
>
> Before we call for a revert, I'd like to hear Peter thoughts about it,
> as he is the main user of the slotted protocol.
>
> Also, Dmitry, can you check if the ChromeOS driver and (or) the android
> one would need to be adapted? My guess is that none of these drivers are
> able to handle a silent closing of a slot
I will, at least for Chrome. But if it is broken I'll simply open a big
to fix it ;)
> and the easiest solution might
> be to simply change the documentation if in fact nobody uses the
> compressed notation (which removes just one ABS_SLOT event within the
> frame, so not sure we can call it compressed BTW).
No, it is more that that I think. Wouldn't we need to allocate memory
for 2*n slots to actually reliably track all contacts if they all happen
to get released and put back onto the surface in different place very
very quickly if we insist on sending tracking id -1 for previously used
slots?
Thanks.
--
Dmitry
next prev parent reply other threads:[~2015-04-23 18:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 18:54 [PATCH v2] Input - mt: Fix input_mt_get_slot_by_key Benjamin Tissoires
2015-04-06 16:33 ` Dmitry Torokhov
2015-04-07 13:17 ` Jiri Kosina
2015-04-23 16:49 ` Dmitry Torokhov
2015-04-23 17:10 ` Henrik Rydberg
2015-04-23 18:20 ` Dmitry Torokhov
2015-04-23 18:38 ` Benjamin Tissoires
2015-04-23 18:47 ` Dmitry Torokhov [this message]
2015-04-24 0:50 ` Peter Hutterer
2015-04-24 6:26 ` Henrik Rydberg
2015-04-27 3:52 ` Peter Hutterer
2015-04-27 18:02 ` Benjamin Tissoires
2015-04-23 18:52 ` Henrik Rydberg
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=20150423184709.GG34808@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.hutterer@who-t.net \
--cc=rydberg@bitmath.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).