On Fri, Dec 10, 2010 at 12:01 PM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: > On 12/10/2010 08:00 PM, Ping Cheng wrote: > >> On Fri, Dec 10, 2010 at 10:13 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: >>> >>>> Can we make MT_TOOL_ENVELOPE cover a bit more cases by: >>>> >>>> 1. Removing ", and is only used for legacy hardware"; >>>> 2. Adding "Or the number of contacts inside the bounding rectangle is >>>> reported if hardware provides the number but not the real contact >>>> positions" to the end of the paragraph. >>> >>> You might disagree, but "old" is still somewhat apt in this situation. >> >> It's ok if we say the new type was inspired by legacy hardware. But >> saying that it "is only used for legacy hardware" closes the door for >> future development. That's not what we are trying to do, right? > > > Well, in a sense we are. I would agree that data aiming to provide gestures as a > 2D transformation matrix can be handled quite well with two tracked points and a > finger count. However, a multitouch interface where users manipulate different > objects on the screen simultaneously is a different story. > >> >>> How would you suggest we report the number of fingers? >> >> I guess if we want to make it generic, we could have something like >> ABS_MT_NUM_CONTACTS to go with MT_TOOL_ENVELOPE. Clients, such as >> synaptics touchpads, that only care about the number of contacts >> inside the envelope don't need to process the contact positions even >> when they are reported. This also resolve the potential that >> BTN_TOOL_QUADTAP is not enough to tell us how many contacts are on the >> surface. > > > I really would like to avoid adding a new way to solve an old problem, in > particular given the statement above. Adding something like BTN_TOOL_QUINTAP > would hurt a little bit, but not nearly as much. If we plan to add BTN_TOOL_QUINTAP, you can ignore my previous comments. >> Maybe we should also tell the clients whether they are going to get >> the contact positions or not. > > > I may not understand what you mean here, but if you are referring to an up-front > declaration of what MT_TOOL types are to be expected, we did discuss this > before, without any conclusion. Perhaps it is relevant to outline why this would > be important. With BTN_TOOL_QUINTAP, this question can be ignored too. Thank you. Ping -- 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
