From: Joonyoung Shim <jy0922.shim@samsung.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
kyungmin.park@samsung.com
Subject: Re: [PATCH v2] input: qt602240 - Add ATMEL QT602240 touchscreen driver
Date: Mon, 28 Jun 2010 17:17:53 +0900 [thread overview]
Message-ID: <4C285AB1.7030301@samsung.com> (raw)
In-Reply-To: <4C285124.1050201@euromail.se>
On 6/28/2010 4:37 PM, Henrik Rydberg wrote:
> Joonyoung Shim wrote:
>> On 6/25/2010 11:08 PM, Henrik Rydberg wrote:
>>> Hi Joonyoung,
>>>
>>> some follow-up comments on the MT events.
>>>
>>>> +static void qt602240_input_report(struct qt602240_data *data, int single_id)
>>>> +{
>>>> + struct qt602240_finger *finger = data->finger;
>>>> + struct input_dev *input_dev = data->input_dev;
>>>> + int finger_num = 0;
>>>> + int id;
>>>> +
>>>> + for (id = 0; id < QT602240_MAX_FINGER; id++) {
>>>> + if (!finger[id].status)
>>>> + continue;
>>>> +
>>>> + input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR,
>>>> + finger[id].area);
>>>> +
>>>> + if (finger[id].status == QT602240_RELEASE)
>>>> + finger[id].status = 0;
>>>> + else {
>>>> + input_report_abs(input_dev, ABS_MT_POSITION_X,
>>>> + finger[id].x);
>>>> + input_report_abs(input_dev, ABS_MT_POSITION_Y,
>>>> + finger[id].y);
>>>> + finger_num++;
>>>> + }
>>>> +
>>>> + input_mt_sync(input_dev);
>>>> + }
>>>> +
>>>> + input_report_key(input_dev, BTN_TOUCH, finger_num > 0);
>>>> +
>>>> + if (finger[single_id].status != QT602240_RELEASE) {
>>>> + input_report_abs(input_dev, ABS_X, finger[single_id].x);
>>>> + input_report_abs(input_dev, ABS_Y, finger[single_id].y);
>>>> + }
>>>> +
>>>> + input_sync(input_dev);
>>>> +}
>>> The problem still persists here. I will try to explain in code form instead:
>>>
>>> for (id = 0; id < QT602240_MAX_FINGER; id++) {
>>> if (!finger[id].status)
>>> continue;
>>>
>>> input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR,
>>> finger[id].status != QT602240_RELEASE ? finger[id].area : 0);
>>> input_report_abs(input_dev, ABS_MT_POSITION_X,
>>> finger[id].x);
>>> input_report_abs(input_dev, ABS_MT_POSITION_Y,
>>> finger[id].y);
>> Hmm, is it OK to report ABS_MT_POSITION_X/Y when releases?
>
> Yes. The position should be the position where the finger left the surface. It
> is different from the ABS_X/Y case simply because the type A protocol exchanges
> data statelessly.
>
I see, but i have something wondering at your document.
This is your patch of "Document the MT event slot protocol"
+Protocol Example A
+------------------
+
+Here is what a minimal event sequence for a two-contact touch would look
+like for a type A device:
+
+ ABS_MT_POSITION_X x[0]
+ ABS_MT_POSITION_Y y[0]
+ SYN_MT_REPORT
+ ABS_MT_POSITION_X x[1]
+ ABS_MT_POSITION_Y y[1]
+ SYN_MT_REPORT
+ SYN_REPORT
+The sequence after moving one of the contacts looks exactly the same; the
+raw data for all present contacts are sent between every synchronization
+with SYN_REPORT.
-Usage
------
+Here is the sequence after lifting the first contact:
+
+ ABS_MT_POSITION_X x[1]
+ ABS_MT_POSITION_Y y[1]
+ SYN_MT_REPORT
+ SYN_REPORT
+
+And here is the sequence after lifting the second contact:
+
+ SYN_MT_REPORT
+ SYN_REPORT
+
Here, there is no reporting for ABS_MT_POSITION_X/Y event, because that
is the last contact?
Then, the coordinates of the first contact are x[1] and y[1], right? If
yes, it is some confusing, i think they are x[0] and y[0].
>>> input_mt_sync(input_dev);
>>>
>>> if (finger[id].status == QT602240_RELEASE)
>>> finger[id].status = 0;
>>> else
>>> finger_num++;
>>> }
>>>
>>> Regarding the single_id, I can understand the need for it, but the logic for a
>>> single touch is slightly confusing. If single_id is to be interpreted as the
>>> contact currently being tracked as the single pointer, and that single_id
>>> changes as the number of fingers on the pad is reduced, until there is only one
>>> left, then it would still be clearer logically to do something like this:
>>>
>>> if (finger_num > 0) {
>>> input_report_key(input_dev, BTN_TOUCH, 1);
>>> input_report_abs(input_dev, ABS_X, finger[single_id].x);
>>> input_report_abs(input_dev, ABS_Y, finger[single_id].y);
>>> } else {
>>> input_report_key(input_dev, BTN_TOUCH, 0);
>>> }
>>> input_sync(input_dev);
>>>
>>> Would it not?
>>>
>> There is a case which fingers more than one are touched and current
>> status of single_id finger is release, then this will report ABS_X/Y
>> events even if it is the release event.
>
> I see. And you want BTN_TOUCH to follow the logic for the single touch? I think
> that is the main issue here. We can have _one_ of the following definitions, but
> not both:
>
> 1. input_report_key(input_dev, BTN_TOUCH, finger_num > 0);
>
OK, i will use this. This was original code.
> 2. input_report_key(input_dev, BTN_TOUCH,
> finger[single_id].status != QT602240_RELEASE);
>
> If you use the latter, there should be another event to denote the finger_num ==
> 0 case. This line at the end should do it:
>
> if (finger_num == 0)
> input_mt_sync(input_dev);
>
I don't know why this needs?
Here, there are fixed codes. How about do you think?
static void qt602240_input_report(struct qt602240_data *data, int single_id)
{
struct qt602240_finger *finger = data->finger;
struct input_dev *input_dev = data->input_dev;
int status = finger[single_id].status;
int finger_num = 0;
int id;
for (id = 0; id < QT602240_MAX_FINGER; id++) {
if (!finger[id].status)
continue;
input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR,
finger[id].status != QT602240_RELEASE ?
finger[id].area : 0);
input_report_abs(input_dev, ABS_MT_POSITION_X,
finger[id].x);
input_report_abs(input_dev, ABS_MT_POSITION_Y,
finger[id].y);
input_mt_sync(input_dev);
if (finger[id].status == QT602240_RELEASE)
finger[id].status = 0;
else
finger_num++;
}
input_report_key(input_dev, BTN_TOUCH, finger_num > 0);
if (status != QT602240_RELEASE) {
input_report_abs(input_dev, ABS_X, finger[single_id].x);
input_report_abs(input_dev, ABS_Y, finger[single_id].y);
}
input_sync(input_dev);
}
Thanks.
next prev parent reply other threads:[~2010-06-28 8:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 1:54 [PATCH v2] input: qt602240 - Add ATMEL QT602240 touchscreen driver Joonyoung Shim
2010-06-25 14:08 ` Henrik Rydberg
2010-06-28 5:16 ` Joonyoung Shim
2010-06-28 7:37 ` Henrik Rydberg
2010-06-28 8:17 ` Joonyoung Shim [this message]
2010-06-28 8:34 ` Henrik Rydberg
2010-06-28 8:42 ` Dmitry Torokhov
2010-06-28 8:46 ` Henrik Rydberg
2010-06-28 9:01 ` Dmitry Torokhov
2010-06-28 9:10 ` Henrik Rydberg
2010-06-28 9:05 ` Joonyoung Shim
2010-06-28 9:17 ` Henrik Rydberg
2010-06-28 10:00 ` Joonyoung Shim
2010-06-28 10:22 ` Henrik Rydberg
2010-06-28 11:12 ` Joonyoung Shim
2010-06-28 12:23 ` Henrik Rydberg
2010-06-28 12:58 ` Joonyoung Shim
2010-06-28 13:24 ` Henrik Rydberg
2010-06-28 13:41 ` Joonyoung Shim
[not found] ` <AANLkTikNh-LTClIgXGAIEkegLCmWNnN2Zk05XhZWOumb@mail.gmail.com>
2010-06-28 14:33 ` Dan Murphy
2010-06-29 3:33 ` Joonyoung Shim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C285AB1.7030301@samsung.com \
--to=jy0922.shim@samsung.com \
--cc=dmitry.torokhov@gmail.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-input@vger.kernel.org \
--cc=rydberg@euromail.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.