On Wed, Jul 06, 2011 at 09:31:20PM +0200, Henrik Rydberg wrote:

quoted

quoted

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.

quoted

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?

quoted

quoted

quoted

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);

quoted

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