> 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); Heh, I forgot we _do_ know in advance how many fingers are supported via BTN_TOOL_*. Ok, no more issues. > > > 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 ;) And thou shalt receive them - some day ;-) > > 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). I concur. So, to conclude: a) The improved synaptics behavior can be achieved by simply using MT-B plus BTN_TOOL_*. b) Userspace should check BTN_TOOL_* for any discrepancies between the maximum number of available slots (always two in this case) and the maximum number of fingers reported (BTN_TOOL_TRIPLETAP etc). Extra actions may then be taken to support more fingers than slots. c) The semi-mt flag is only used to signal that the two points sent via MT-B are the corners of a bounding box. Cheers, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
