On Fri, Oct 29, 2010 at 3:45 PM, Ping Cheng <pinglinux@xxxxxxxxx> wrote:
> On Wed, Oct 13, 2010 at 11:21 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote:
>>
>>>> +static int wacom_bpt_irq(struct wacom_wac *wacom, size_t len)
>>
>>>> +{
>>>> + static int trkid;
>>>> + struct input_dev *input = wacom->input;
>>>> + unsigned char *data = wacom->data;
>>>> + int sp = 0, sx = 0, sy = 0, count = 0;
>>>> + int i;
>>>> +
>>>> + if (len != WACOM_PKGLEN_BBTOUCH)
>>>> + return 0;
>>>> +
>>>> + for (i = 0; i < 2; i++) {
>>>> + int p = data[9 * i + 2];
>>>> + input_mt_slot(input, i);
>>>> + if (p) {
>>>> + int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
>>>> + int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
>>>> + input_report_abs(input, ABS_MT_PRESSURE, p);
>>>> + input_report_abs(input, ABS_MT_POSITION_X, x);
>>>> + input_report_abs(input, ABS_MT_POSITION_Y, y);
>>>> + if (wacom->id[i] < 0)
>>>> + wacom->id[i] = trkid++ & MAX_TRACKING_ID;
>>>
>>> Why do we need an arbitrary MAX_TRACKING_ID when the device can tell
>>> us how many IDs we can have and it tracks the individual fingers for
>>> us? In this case, there are only two ID/fingers and the ID can be
>>> retrieved from the raw data. I must be missing something in the
>>> defintion of MAX_TRACKING_ID.
>>
>> In the language of ABS_MT, there is a distinction between slot and id. The slot
>> is the handle used to communicate a unique touch. The id is the identifier of
>> that touch. The device tells us how many slots we have. The range of ids is in
>> principle infinite. In practice, it is set to a large number.
>
> Sorry to bring this topic back again. I was under the impression that
> I was the only one who didn't get the spec clear. The discussion at
> yesterday's UDS session made me feel I am not alone (good or bad :).
> Let me try it again to see if I can get it right this time.
>
> From the "Multi-touch (MT) Protocol" under Documentation/input, we see
> the following:
>
> "The slot protocol requires the use of the ABS_MT_TRACKING_ID, either
> provided by the hardware or computed from the raw data".
>
> That means if the hardware provides the tracking ID, we use it.
> Otherwise we lose that specific information reported from the
> hardware.
>
> For the Bamboo case, the tracking ID happens to be the same as the
> slot ID we use. But, there are devices, as far as I know, report up to
> 10 fingers/touches. So, there would be 10 slots to report the data.
> But, the tracking ID we get from the devices is 0 to 255. So, slot 5
> could have a tracking ID of 123 now and 9 when tuch 123 is up and
> touch 5 is down.
>
>> To answer a possible follow-up question: from the tracking id, you can tell if a
>> contact is present, if it is new, and if it is older than another contact.
>
> The new and old attribute can be tracked by a time stamp in the
> userland. Kernel driver doesn't need to worry about it. Maybe I am
> missing an use case in the kernel?
>
> Ping
>
Let me ask the same basic question using some examples.
First, let me say I see no issues with MT spec... its just you may
have a usecase in mind for tracking ID always being unique that not
everyone has fully grasped.
As I'm updating xf86-input-wacom, I see ABS_MT_SLOT as mostly same
meaning as BTN_TOOL_PEN/ERASER/MOUSE. It gives context of all MT
events to follow for a specific touch.
I next see ABS_MT_TRACKING_ID a little like BTN_TOUCH sent along with
that tool's data. It tells you when touch/tool is in proximity and
thus that the x/y/pressure values have meaning. Here -1 is out of
proximity and positive value is in proximity and also a little extra
(how old a touch compared to others, etc).
Now, for HW that enforces slot == touch #, if we made
ABS_MT_TRACKING_ID while in proximity/touching the same value as
ABS_MT_SLOT then user app could simplify and totally ignore
ABS_MT_SLOT event (I think).
So I guess the question is does unique ID solve some specific user
space problem that couldn't be solved with user space timestamps taken
when ABS_MT_TRACKING_ID first becomes non-negative?
Mostly, I expect the answer is "stop being lazy and just look at both
events so you'll work with all hardware types and without timestamps".
:-)
Chris
--
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
