On Fri, Oct 29, 2010 at 5:55 PM, Chris Bagwell <chris@xxxxxxxxxxxxxx> wrote:
> 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.
I agree with you (how come I always agree with you :). I am not asking
for a spec change. I am only discussing a code change. And I want to
make sure my code change will not affect any exsiting userland
programs, especially Henrik's programs.
> 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.
Right.
> 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).
Agree.
> 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).
Bamboo is a special case which does not make a ddifference for SLOT
and TRACKING IDs. My concern is for those devices that do report
TRACKING IDs differently from the touch #. I want to make the code
consistent accross all devices that support TRACKING IDs.
> 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?
Some user land developers told me so. And they want to get the
TRACKING_IDs if hardware provides them.
> 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".
Do you mean the answer from me or from you :)?
No, I won't answer that to you or anyone. Not all user land programs
need all the information we report. So, It would be up to the app
developers to decide how to track the data. We, as device driver
developer, only need to report the data as close as hardware provides
and that meets the spec.
Making a patch might be easier to show what meant. I'll do that soon.
I want to make sure my change does not affect Henrik's exsiting
userland programs.
Hope this clears some confusion.
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
