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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 6 Jul 2011 13:00:57 -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 09:31:20PM +0200, Henrik Rydberg wrote:
> > > 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.
> 
> Well, it is possible, but it is a great deal more complex than just
> looking at what the slots contain. At least we should all be able to
> agree that MT-B is sufficient for any "proper" MT device.
> 
> > Luckily this should be backward-compatible (i.e. older userspace will
> > ignore "extended" fingercounts, newer will pay attention to it).
> 
> OTOH, letting semi-mt engulf all devices which requires the use of
> BTN_TOOL_* for finger count makes it easier to differentiate between
> various userspace support levels. "This app supports pure MT-B only",
> etc.

Do app writers really want to exclude semi-MT devices even though they
might be usable? I can see wanting to support only MT-B protocol (as opposed
to chatty MT-A) but if semi-MT stream is usable why not use 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?
> 
> To indicate that a) the two positions may not represent true fingers
> but a bounding box, and b) the contact count is determined by
> BTN_TOOL_*.
> 
> True, there is no way to distinguish between the real-fingers and
> bounding-box cases here

And that is the problem.

> (that is why I suggested another binary value
> in a previous mail), but without semi-mt, there is no way to know a
> priori if special logic is needed for the number of fingers.

This should be pretty straightforward:

	num_fingers = calc_fingers_from_btn_tool(device); // via EVIOCGKEY
	num_slots = get_number_of_slots(device); // EVIOCGABS
	num_untracked_contacts = max(num_fingers - num_slots, 0);

> 
> > 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.
> 
> Yes, it seems we do have different assumptions here. The more reason
> to document it further. :-)

I'll take patches ;)

> 
> To me, it seems we do need a little bit of extra information to
> determine this new type of device.

I think we already have all we need (see above).

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/