ABS_PRESSURE and 0 ranges

ABS_PRESSURE and 0 ranges

[Rolf Eike Beer]

Hi all,

as I found out the hard way tslib does the detection if a touchscreen has been 
"clicked" if the kernel driver says it does not support ABS_PRESSURE. But when 
the kernel says it can do ABS_PRESSURE tslib will not do it's emulation and 
just pass on whatever pressure value the kernel sends.

So far, so good. Sadly there are some drivers that do:

input_set_abs_params(dev, ABS_PRESSURE, 0, 0, 0, 0);

Guess what happens: no clicks at all. The question I have is: does the above 
line make any sense to be in a kernel driver at all? Or is that some voodoo 
that must be there and it's all tslib fault?

Now that I know where the problem is coming from the problem is easily 
fixable, I'm just wondering which patch to make.

Greetings,

Eike

Re: ABS_PRESSURE and 0 ranges

[Dmitry Torokhov]

Hi Rolf,

On Thu, Oct 25, 2012 at 02:59:49PM +0200, Rolf Eike Beer wrote:
> Hi all,
> 
> as I found out the hard way tslib does the detection if a touchscreen has been 
> "clicked" if the kernel driver says it does not support ABS_PRESSURE. But when 
> the kernel says it can do ABS_PRESSURE tslib will not do it's emulation and 
> just pass on whatever pressure value the kernel sends.
> 
> So far, so good. Sadly there are some drivers that do:
> 
> input_set_abs_params(dev, ABS_PRESSURE, 0, 0, 0, 0);
> 

What drivers are doing this?

> Guess what happens: no clicks at all. The question I have is: does the above 
> line make any sense to be in a kernel driver at all? Or is that some voodoo 
> that must be there and it's all tslib fault?
> 
> Now that I know where the problem is coming from the problem is easily 
> fixable, I'm just wondering which patch to make.

Well, the limits are strictly advisory for userspace, input core does
not perform any clamping or discarding the data that falls outside the
limits, so tslib probably should not do that either.

Thanks.

-- 
Dmitry

Re: ABS_PRESSURE and 0 ranges

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

You wrote:
> Hi Rolf,
> 
> On Thu, Oct 25, 2012 at 02:59:49PM +0200, Rolf Eike Beer wrote:
> > Hi all,
> > 
> > as I found out the hard way tslib does the detection if a touchscreen has
> > been "clicked" if the kernel driver says it does not support
> > ABS_PRESSURE. But when the kernel says it can do ABS_PRESSURE tslib will
> > not do it's emulation and just pass on whatever pressure value the kernel
> > sends.
> > 
> > So far, so good. Sadly there are some drivers that do:
> > 
> > input_set_abs_params(dev, ABS_PRESSURE, 0, 0, 0, 0);
> 
> What drivers are doing this?

git grep 'ABS_PRESSURE, 0, 0, 0, 0' drivers/input/

> > Guess what happens: no clicks at all. The question I have is: does the
> > above line make any sense to be in a kernel driver at all? Or is that
> > some voodoo that must be there and it's all tslib fault?
> > 
> > Now that I know where the problem is coming from the problem is easily
> > fixable, I'm just wondering which patch to make.
> 
> Well, the limits are strictly advisory for userspace, input core does
> not perform any clamping or discarding the data that falls outside the
> limits, so tslib probably should not do that either.

My main concern is that if the driver says it will only ever give pressure 
values from 0 to 0, what useful stuff may that ever be? And since the driver 
says it supports presure touchscreen will wait for the driver to report it. 
Since it will never do it (or could at most return a 0), then there is nothing 
that could ever become a valid click event.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ABS_PRESSURE and 0 ranges

[Dmitry Torokhov]

On Thursday, October 25, 2012 10:11:27 PM Rolf Eike Beer wrote:
> You wrote:
> > Hi Rolf,
> > 
> > On Thu, Oct 25, 2012 at 02:59:49PM +0200, Rolf Eike Beer wrote:
> > > Hi all,
> > > 
> > > as I found out the hard way tslib does the detection if a touchscreen
> > > has
> > > been "clicked" if the kernel driver says it does not support
> > > ABS_PRESSURE. But when the kernel says it can do ABS_PRESSURE tslib will
> > > not do it's emulation and just pass on whatever pressure value the
> > > kernel
> > > sends.
> > > 
> > > So far, so good. Sadly there are some drivers that do:
> > > 
> > > input_set_abs_params(dev, ABS_PRESSURE, 0, 0, 0, 0);
> > 
> > What drivers are doing this?
> 
> git grep 'ABS_PRESSURE, 0, 0, 0, 0' drivers/input/
> 
> > > Guess what happens: no clicks at all. The question I have is: does the
> > > above line make any sense to be in a kernel driver at all? Or is that
> > > some voodoo that must be there and it's all tslib fault?
> > > 
> > > Now that I know where the problem is coming from the problem is easily
> > > fixable, I'm just wondering which patch to make.
> > 
> > Well, the limits are strictly advisory for userspace, input core does
> > not perform any clamping or discarding the data that falls outside the
> > limits, so tslib probably should not do that either.
> 
> My main concern is that if the driver says it will only ever give pressure
> values from 0 to 0, what useful stuff may that ever be? And since the driver
> says it supports presure touchscreen will wait for the driver to report it.
> Since it will never do it (or could at most return a 0), then there is
> nothing that could ever become a valid click event.

Once again, the limits are simply advisory and can even be adjusted from
userspace (EVIOCSABS).

So ucb1400_ts does report true pressure so all is good there, but tsc40 is
not. I think the claim for ABS_PRESSURE is left over from time when tslib
did not think that device without ABS_PRESSURE was a touchscreen. I'll
remove it from the driver.

Thanks.

-- 
Dmitry

Re: ABS_PRESSURE and 0 ranges

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

You wrote:
> On Thursday, October 25, 2012 10:11:27 PM Rolf Eike Beer wrote:
> > You wrote:
> > > Hi Rolf,
> > > 
> > > On Thu, Oct 25, 2012 at 02:59:49PM +0200, Rolf Eike Beer wrote:
> > > > Hi all,
> > > > 
> > > > as I found out the hard way tslib does the detection if a touchscreen
> > > > has
> > > > been "clicked" if the kernel driver says it does not support
> > > > ABS_PRESSURE. But when the kernel says it can do ABS_PRESSURE tslib
> > > > will
> > > > not do it's emulation and just pass on whatever pressure value the
> > > > kernel
> > > > sends.
> > > > 
> > > > So far, so good. Sadly there are some drivers that do:
> > > > 
> > > > input_set_abs_params(dev, ABS_PRESSURE, 0, 0, 0, 0);
> > > 
> > > What drivers are doing this?
> > 
> > git grep 'ABS_PRESSURE, 0, 0, 0, 0' drivers/input/
> > 
> > > > Guess what happens: no clicks at all. The question I have is: does the
> > > > above line make any sense to be in a kernel driver at all? Or is that
> > > > some voodoo that must be there and it's all tslib fault?
> > > > 
> > > > Now that I know where the problem is coming from the problem is easily
> > > > fixable, I'm just wondering which patch to make.
> > > 
> > > Well, the limits are strictly advisory for userspace, input core does
> > > not perform any clamping or discarding the data that falls outside the
> > > limits, so tslib probably should not do that either.
> > 
> > My main concern is that if the driver says it will only ever give pressure
> > values from 0 to 0, what useful stuff may that ever be? And since the
> > driver says it supports presure touchscreen will wait for the driver to
> > report it. Since it will never do it (or could at most return a 0), then
> > there is nothing that could ever become a valid click event.
> 
> Once again, the limits are simply advisory and can even be adjusted from
> userspace (EVIOCSABS).
> 
> So ucb1400_ts does report true pressure so all is good there, but tsc40 is
> not. I think the claim for ABS_PRESSURE is left over from time when tslib
> did not think that device without ABS_PRESSURE was a touchscreen. I'll
> remove it from the driver.

Thanks, so I know what part to patch. Please backport that to stable, too, so 
tslib will work with that driver even on stable kernels.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]