On Sun, May 23, 2010 at 10:25 PM, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote: >> Ping Cheng wrote: >> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@xxxxxxxxxxxxxx> wrote: >> [...] >> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions? >> > >> > You are definitely on the right track. The fingers/touch objects can >> > be represented two-dimensionally (x,y) instead of one-dimensionally >> > (ABS_MT_TRACKING_ID). I think we can survive with the current MT_BLOB >> > definition although some optimization would be helpful, especially for >> > filtering. For the sake of Henrik great effort, I'd like to see his >> > current patchset gets in the tree before we start another round of >> > "suggestions". >> > >> > Thank you for asking. >> >> Regarding blobs, I confused myself yesterday. The original intention of the blob >> id was in fact to be able to "paint" more generic contact forms. However, no >> driver has come close to doing this yet, so it has gotten close to no attention. >> Now, to address the question of how to communicate more elaborate contact forms, >> it seems one can combine the two goals "one position per slot" and "multiple >> positions per contact" by simply repeating the same tracking id for a set of >> slots, like this: >> >> ABS_SLOT 0 >> ABS_MT_TRACKING_ID 14 >> ABS_MT_POSITION_X x[0] >> ABS_MT_POSITION_Y y[0] >> ABS_SLOT 1 >> ABS_MT_TRACKING_ID 14 >> ABS_MT_POSITION_X x[1] >> ABS_MT_POSITION_Y y[1] >> ABS_SLOT 2 >> ABS_MT_TRACKING_ID 14 >> ABS_MT_POSITION_X x[2] >> ABS_MT_POSITION_Y y[2] >> >> Not all too different from what you suggested, and there is no blob id involved >> at all. And yes, it would require additional parsing power at the user end. >> Something for later. > > This is confusing me now :) > > How would a device get multiple x/y coordinates for a single contact? I > could understand a range of coordinates but that's what we have the > ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y > coordinates, wouldn't that be two touchpoints, tracked individually and thus > with a different tracking ID? > > I read the example above as _the_ example for using blob IDs to combine > multiple contacts into one semantic contact. As Henrik pointed out, the current BLOB format is for "more generic contact forms", such as rectangles or ellipses. They are special blobs. A generic (true) blob doesn't have to have a regular shape. It is most likely in an irregular shape. They would be represented in an array of points/contacts/(x,y)s, whichever term works for you :). tbh, I don't know what exact format we are going to use. But, I feel we can live with Henrik's current format, at least for a while. 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
