linux-kernel - Re: [PATCH 09/12] Input: synaptics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jul 2011 11:58:33 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Daniel Kurtz <djkurtz@...omium.org>, chase.douglas@...onical.com,
	rubini@...l.unipv.it, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, derek.foreman@...labora.co.uk,
	daniel.stone@...labora.co.uk, olofj@...omium.org
Subject: Re: [PATCH 09/12] Input: synaptics - add image sensor support

On Wed, Jul 06, 2011 at 08:47:59PM +0200, Henrik Rydberg wrote:
> > > (C) A third, compromise implementation might be to do something like this:
> > >   (1) When >=2 fingers are on the pad, report 2 MT-B slots, where:
> > >     (a) slot[0] reports finger 1
> > >     (b) slot[1] reports finger 2
> > >     (c) Total number of fingers on pad is indicated by EV_KEY/BTN_TOOL_* is set.
> > >   (2) If 1 finger is removed, the tracking_id for its slot is invalidated;
> > >       but, the finger that remains stays in its same slot with the
> > > same tracking_id.
> > >   (3) Whenever the number of fingers changes from/to 3 or more
> > > fingers, both slots are always invalidated.
> > >       New tracking_ids are assigned to both slots which contain the
> > > two fingers now being reported.
> > >   (4) No special driver property is required for this, not even "semi-mt".
> > >       It should be as pure MT-B as we can get (plus BTN_TOOL_* hack).
> 
> I believe there is a strong userspace assumption that BTN_TOOL_* has
> no meaning for real MT devices. Rightfully so, IMO. Hence, I think
> semi-mt needs to be used here as well.

I think we need to adjust userspace to pay attention to BTN_TOOL_* for
MT-B too so that if number of slots advertised does not match
BTN_TOOL_* capabilities that means that the device does not privide
tracking data for all contacts.

Luckily this should be backward-compatible (i.e. older userspace will
ignore "extended" fingercounts, newer will pay attention to it).

> 
> > > 
> > 
> > This is the best option in my opinion. We will present 2 finger position
> > data plus extended finger count.
> 
> We never did put all the details of the bounding box coordinates in
> writing, so perhaps this is an opportunity to both fix that and extend
> usability to the case so described. The only question is whether there
> are applications out there which now assume min/max instead of contact
> positions. If anyone knows, please speak up. :-) Otherwise, I am very
> much for Daniel's case C, with Dmitry's modification.
> 
> In short: Use the semi-MT property, and send two suitable fingers
> along with it.

Umm... but it is my understanding that 2 fingers will provide real
tracking data, not bounding box, so why would we set semi-MT?

Maybe we have different notions of what semi-MT property conveys? For me
semi-MT indicates that the device provides 2 coordinates for bounding
box.  However if semi-MT is not set does not mean that the device
provides true tracking for all contacts, but only for advertised slots.
There still may be additional data transmitted.

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/