[questions]touch driver.

[questions]touch driver.

[Austin Zhang]

hi, team,

I have several questions on touch driver.

1 For touch panel, if it is HID type panel, then for enabling
autosuspend for this device, can we only let its parent device enable
autosuspend as default, don't need do anything within that touch
driver?

2 When setting fuzz parameter by input_set_abs_params, what is the
typical rule/scenarios in general? For example, if one device which
supports logical max sample in X/Y as 4096*3072 and the screen LCD
resolution as 1024*768, then fuzz=100 is meaning that the driver will
not report (by input_event) contact point within 50 sample point
(fuzz/2) to userspace? And if in this case, the high level gesture
recognizer is setting Manhattan length as 60, does it means it is ok
if the Manhattan length of contact point coordinator from driver is
less than 240? (60*4)

3 Seemed few drivers (only egalax and intel-mid-touch) are using this
fuzz param, so in most cases, it is one in-case params to leave to
user for 'tuning' only? Then should it be exported as module
parameter?

Thanks for your answer in advance.

Re: [questions]touch driver.

[Benjamin Tissoires]

Hi Austin,

On Wed, Jun 29, 2011 at 05:08, Austin Zhang <zhang.austin@gmail.com> wrote:
> Ben, sorry if disturbing you, seemed people pay most
> efforts/attentions on patch rather than below simple question in ML,
> can you please shed some light on this. Thanks.

Sorry, I'm on holidays, and sometimes, I don't take the time to answer
to many messages....

>
>
> ---------- Forwarded message ----------
> From: Austin Zhang <zhang.austin@gmail.com>
> Date: 2011/6/23
> Subject: [questions]touch driver.
> To: linux-input@vger.kernel.org, Benjamin Tissoires
> <benjamin.tissoires@gmail.com>, Chase Douglas
> <chase.douglas@canonical.com>
>
>
> hi, team,
>
> I have several questions on touch driver.
>
> 1 For touch panel, if it is HID type panel, then for enabling
> autosuspend for this device, can we only let its parent device enable
> autosuspend as default, don't need do anything within that touch
> driver?

I don't really understand this point.
The hid multitouch panel sleep issue has been solved in
hid-multitouch. Normally there are no problems with suspend to ram (if
you mean that by autosuspend) except if the device need to be in a
special mode (as for most multitouch devices).
See the function mt_reset_resume in hid-multitouch.c

>
> 2 When setting fuzz parameter by input_set_abs_params, what is the
> typical rule/scenarios in general? For example, if one device which
> supports logical max sample in X/Y as 4096*3072 and the screen LCD
> resolution as 1024*768, then fuzz=100 is meaning that the driver will
> not report (by input_event) contact point within 50 sample point
> (fuzz/2) to userspace? And if in this case, the high level gesture
> recognizer is setting Manhattan length as 60, does it means it is ok
> if the Manhattan length of contact point coordinator from driver is
> less than 240? (60*4)

Personally, I don't care with fuzz. My idea of the kernel is that it
needs to send data from the device with less transformations (or we
won't be able to use it in user space).
You should ask Henrik Rydberg on fuzz as he is the one to introduce it
in hid-multitouch.

There is also a problem with your explanation: fuzz should not be
related to screen resolution as in the kernel we are not aware of the
screen resolution and the mapping.
I think, and it's my own opinion that fuzz should be used when the
device is not stable, i.e. when it has a range of 4096 for instance
and the values are floating in a range of 10 for instance.

Then, on some integrated platforms (tablets, and others) fuzz can be
used to not awake too much the different processes that rely on input.
But I would say this is a side effect of the original goal (again,
it's my only guess).

>
> 3 Seemed few drivers (only egalax and intel-mid-touch) are using this
> fuzz param, so in most cases, it is one in-case params to leave to
> user for 'tuning' only? Then should it be exported as module
> parameter?

With the current implementation, I don't think so. If you want to
submit a patch, I won't vote against. Dimitry and Jiri may have a
different view on this.

Cheers,
Benjamin

>
> Thanks for your answer in advance.
>

Re: [questions]touch driver.

[Austin Zhang]

Thanks for your reply.

>> 1 For touch panel, if it is HID type panel, then for enabling
>> autosuspend for this device, can we only let its parent device enable
>> autosuspend as default, don't need do anything within that touch
>> driver?
>
> I don't really understand this point.
> The hid multitouch panel sleep issue has been solved in
> hid-multitouch. Normally there are no problems with suspend to ram (if
> you mean that by autosuspend) except if the device need to be in a
> special mode (as for most multitouch devices).
> See the function mt_reset_resume in hid-multitouch.c
Here, for autosuspend, what I am pointing to is USB autosuspend (say,
supports_autosuspend = 1). For the current hid touch panel, seemed no
one declare it explicitly, so I want to know if hid touch panel
implement autosuspend from his up-level class.

>
>>
>> 2 When setting fuzz parameter by input_set_abs_params, what is the
>> typical rule/scenarios in general? For example, if one device which
>> supports logical max sample in X/Y as 4096*3072 and the screen LCD
>> resolution as 1024*768, then fuzz=100 is meaning that the driver will
>> not report (by input_event) contact point within 50 sample point
>> (fuzz/2) to userspace? And if in this case, the high level gesture
>> recognizer is setting Manhattan length as 60, does it means it is ok
>> if the Manhattan length of contact point coordinator from driver is
>> less than 240? (60*4)
>
> Personally, I don't care with fuzz. My idea of the kernel is that it
> needs to send data from the device with less transformations (or we
> won't be able to use it in user space).
> You should ask Henrik Rydberg on fuzz as he is the one to introduce it
> in hid-multitouch.
Thanks.

> There is also a problem with your explanation: fuzz should not be
> related to screen resolution as in the kernel we are not aware of the
> screen resolution and the mapping.
Yes, we don't know the resolution in userspace. But as above my
description, our touch panel has resolution as Xtouch*Ytouch, if I set
fuzz=<fuzz_value>, then from the current code, contact point within
fuzz_value/2 will be treated as same contact point, that filtered some
noise. And the high level touch/gesture recognizer also has rule to
filter noise (by Manhattan length).
So can I assume:
If the high level gesture recognizer set Manhattan length as 60 and
Xorg sets screen resolution as Xlcd*Ylcd, then almost X-direction
changes of contact point within 60*(Xtouch/Xlcd) will be treated as
same X-direction coordinate by userspace gesture recognizer?
And if it is ture, then fuzz parameter seemed not so useful.


> I think, and it's my own opinion that fuzz should be used when the
> device is not stable, i.e. when it has a range of 4096 for instance
> and the values are floating in a range of 10 for instance.
In above case, if Xtouch*Ytouch= 4096*3072, Xlcd*Ylcd = 1024*768, then
the floating of 10 in panel is meaning 2.5 in logical resolution,
which << the Manhattan length in gesture recognizer. So even thought I
don't set it in driver, the floating also was filtered from userspace.
And also 60 Manhattan length in userspace would be 240 Manhattan
length in driver, seemed no device will have such big floating in
practice. So fuzz is useless in this situation.


> Then, on some integrated platforms (tablets, and others) fuzz can be
> used to not awake too much the different processes that rely on input.
> But I would say this is a side effect of the original goal (again,
> it's my only guess).
>
>>
>> 3 Seemed few drivers (only egalax and intel-mid-touch) are using this
>> fuzz param, so in most cases, it is one in-case params to leave to
>> user for 'tuning' only? Then should it be exported as module
>> parameter?
>
> With the current implementation, I don't think so. If you want to
> submit a patch, I won't vote against. Dimitry and Jiri may have a
> different view on this.
>
> Cheers,
> Benjamin
>
>>
>> Thanks for your answer in advance.
>>
>