[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150423184709.GG34808@dtor-ws>
Date: Thu, 23 Apr 2015 11:47:09 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc: Peter Hutterer <peter.hutterer@...-t.net>,
Henrik Rydberg <rydberg@...math.org>,
Jiri Kosina <jkosina@...e.cz>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Input - mt: Fix input_mt_get_slot_by_key
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists