ABS_PRESSURE and 0 ranges
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
Hi Rolf,
Quoted 11 lines · 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 doABS_PRESSUREtslib 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?
Quoted 6 lines
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.
Signature · 1 line
Dmitry
Quoted 11 lines · You
Hi Rolf,
Quoted 8 lines · 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 doABS_PRESSUREtslib will not do it's emulation and just pass on whatever pressure value the kernel sends.
Quoted 5 lines
Quoted 3 lines
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/
Quoted 10 lines
Quoted 6 lines
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
Quoted 33 lines · Rolf Eike Beer
Quoted 13 lines · You
Hi Rolf,
Quoted 10 lines · 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 supportABS_PRESSURE. But when the kernel says it can doABS_PRESSUREtslib will not do it's emulation and just pass on whatever pressure value the kernel
sends.Quoted 5 lines
Quoted 3 lines
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/Quoted 10 lines
Quoted 6 lines
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.
Quoted 5 lines
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.
Signature · 1 line
Dmitry
Quoted 41 lines · You
Quoted 34 lines · Rolf Eike Beer
Quoted 14 lines · You
Hi Rolf,
Quoted 11 lines · 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 supportABS_PRESSURE. But when the kernel says it can doABS_PRESSUREtslib will
not do it's emulation and just pass on whatever pressure value the kernel
sends.Quoted 5 lines
Quoted 3 lines
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/Quoted 10 lines
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
Once again, the limits are simply advisory and can even be adjusted from userspace (EVIOCSABS).
So
ucb1400_tsdoes report true pressure so all is good there, but tsc40 is not. I think the claim forABS_PRESSUREis left over from time when tslib did not think that device withoutABS_PRESSUREwas 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