From: Maxime Ripard <hidden> Date: 2014-11-05 15:11:02
Hi,
The current ft5x06 reports to the user-space that its maximum
coordinates are, on both X and Y, way higher than what could be
actually usable on the screen (in my case, 5759x1151 instead of
480x800).
This causes trouble on some userspace stacks that then try to re-scale
these coordinates back to the framebuffer resolution, like QT does.
Use the of_touchscreen code to find the real touchscreen limits in the
DT case, and report that to the userspace.
Thanks,
Maxime
Maxime Ripard (3):
input: touchscreen: of: Use input_set_abs_params
input: touchscreen: of: Register multitouch axes
input: ft5x06: Allow to set the maximum axes value through the DT
drivers/input/touchscreen/edt-ft5x06.c | 5 ++++
drivers/input/touchscreen/of_touchscreen.c | 39 ++++++++++++++++++++++--------
2 files changed, 34 insertions(+), 10 deletions(-)
--
2.1.1
From: Maxime Ripard <hidden> Date: 2014-11-05 15:10:05
Drivers are still required to call input_set_abs_params for their axes, as if
they only use the touchscreen_parse_of_params function, the axis bit in absbit
won't be set.
Switch to using input_set_abs_params to fully setup each and every available
axis so that drivers will be able to solely use this function.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/input/touchscreen/of_touchscreen.c | 33 +++++++++++++++++++++---------
1 file changed, 23 insertions(+), 10 deletions(-)
From: Maxime Ripard <hidden> Date: 2014-11-05 15:10:07
Currently the driver relies on some obscure and undocumented register to set
the maximum axis value.
The reported value is way too high to be meaningful, which confuses some
userspace tools like QT's evdevtouch plugin which try to scale the reported
events to the maximum values.
Use the values from the DT to set meaningful values.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/input/touchscreen/edt-ft5x06.c | 5 +++++
1 file changed, 5 insertions(+)
From: Maxime Ripard <hidden> Date: 2014-11-05 15:10:25
So far, the DT parsing code was only setting up the regular input axes,
completely ignoring their multitouch counter parts.
Fill them with the same parameters than the regular axes.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/input/touchscreen/of_touchscreen.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
On Wed, Nov 05, 2014 at 04:07:49PM +0100, Maxime Ripard wrote:
quoted hunk
So far, the DT parsing code was only setting up the regular input axes,
completely ignoring their multitouch counter parts.
Fill them with the same parameters than the regular axes.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/input/touchscreen/of_touchscreen.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Not all devices are multitouch so you shoudl not be setting multitouch
bits unconditionally.
In I think we should rely on driver to set capability bits properly and
then here test them and apply the readings. Probably also issue a
warning if we see max/fuzz setting but neither ABS_<N>/ABS_MT_<N>
capabilities.
Thanks.
From: Maxime Ripard <hidden> Date: 2014-11-06 16:10:07
Hi,
On Wed, Nov 05, 2014 at 09:56:35AM -0800, Dmitry Torokhov wrote:
On Wed, Nov 05, 2014 at 04:07:49PM +0100, Maxime Ripard wrote:
quoted
So far, the DT parsing code was only setting up the regular input axes,
completely ignoring their multitouch counter parts.
Fill them with the same parameters than the regular axes.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/input/touchscreen/of_touchscreen.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Not all devices are multitouch so you shoudl not be setting multitouch
bits unconditionally.
Hmmm, right.
In I think we should rely on driver to set capability bits properly and
then here test them and apply the readings. Probably also issue a
warning if we see max/fuzz setting but neither ABS_<N>/ABS_MT_<N>
capabilities.
What I was aiming at was to avoid DT parsing duplication for the
!multitouch and multitouch axis. I don't think there's a way to copy
the parameters.
The mt_init_slots might be a solution, but it does the copy the other
way around: from the multitouch to the !multitouch axis, and without
enabling it, which renders using both input_mt_init_slots and the
of_touchscreen code together impossible.
Is there a way to just enable an axis without calling
input_set_abs_params? Is __set_bit enough?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Thu, Nov 06, 2014 at 05:06:21PM +0100, Maxime Ripard wrote:
Hi,
On Wed, Nov 05, 2014 at 09:56:35AM -0800, Dmitry Torokhov wrote:
quoted
On Wed, Nov 05, 2014 at 04:07:49PM +0100, Maxime Ripard wrote:
quoted
So far, the DT parsing code was only setting up the regular input axes,
completely ignoring their multitouch counter parts.
Fill them with the same parameters than the regular axes.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/input/touchscreen/of_touchscreen.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Not all devices are multitouch so you shoudl not be setting multitouch
bits unconditionally.
Hmmm, right.
quoted
In I think we should rely on driver to set capability bits properly and
then here test them and apply the readings. Probably also issue a
warning if we see max/fuzz setting but neither ABS_<N>/ABS_MT_<N>
capabilities.
What I was aiming at was to avoid DT parsing duplication for the
!multitouch and multitouch axis. I don't think there's a way to copy
the parameters.
The mt_init_slots might be a solution, but it does the copy the other
way around: from the multitouch to the !multitouch axis, and without
enabling it, which renders using both input_mt_init_slots and the
of_touchscreen code together impossible.
Is there a way to just enable an axis without calling
input_set_abs_params? Is __set_bit enough?
Hmm, not anymore I'm afraid as you still need absinfo being allocated,
but there is input_set_capability() that is basically a fancy
__set_bit(). If you set ABS_* with it that would mean that the device
has unspecified min/max/fuzz.
And then, in DT parsing code, I'd do:
...read max and fuzz for an axis...
if (max || fuzz) {
if (!test_bit(ABS_N, dev->absbit) &&
!test_bit(ABS_MT_N, dev->absbit)) {
dev_warn("... have parameters but axis not set up...");
} else {
if (test_bit(ABS_N...)
input_set_abs_params(dev, ABS_N...);
if (test_bit(ABS_MT_N...)
input_set_abs_params(dev, ABS_MT_N...);
}
Thanks.
--
Dmitry