[PATCH resend v2 0/2] Input: touchscreen - Add support for touchscreen-min-x and -min-y properties

[PATCH resend v2 0/2] Input: touchscreen - Add support for touchscreen-min-x and -min-y properties

[Hans de Goede]

Hi Dmitry,

This one seems to have fallen through the cracks, hence this resend.

Note the first patch has a:

Reviewed-by: Rob Herring <robh@kernel.org>

Now, so I believe that this series is ready for merging.

Regards,

Hans

[PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Hans de Goede]

Some touchscreens, depending on the firmware and/or the digitizer report
coordinates which never reach 0 along one or both of their axis.

This has been seen for example on the Silead touchscreens on a Onda V891w
and a Point of View mobii TAB-P800w(v2.0).

This commits documents 2 new touchscreen properties for communicating
the minimum reported values to the OS: touchscreen-min-x and -min-y.

This commit also drop the (in pixels) comment from the documentation
of the touchscreen-size-x and touchscreen-size-y properties. This comment
suggests that there is a relation between the range of reported
coordinates and the display resolution, which is only true for some
devices. The (in pixels) comment is replaced with "(maximum x coordinate
reported + 1)" to mirror the language describing the new touchscreen-min-x
and -min-y properties.

Cc: robh@kernel.org
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Split out from the patch implementing support for the properties
-Describe the changes to the touchscreen-size-x / -size-y description in
 the commit message
---
 .../devicetree/bindings/input/touchscreen/touchscreen.txt   | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
index 537643e86f61..8aff9551259f 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -1,10 +1,12 @@
 General Touchscreen Properties:
 
 Optional properties for Touchscreens:
+ - touchscreen-min-x		: minimum x coordinate reported (0 if not set)
+ - touchscreen-min-y		: minimum y coordinate reported (0 if not set)
  - touchscreen-size-x		: horizontal resolution of touchscreen
-				  (in pixels)
+				  (maximum x coordinate reported + 1)
  - touchscreen-size-y		: vertical resolution of touchscreen
-				  (in pixels)
+				  (maximum y coordinate reported + 1)
  - touchscreen-max-pressure	: maximum reported pressure (arbitrary range
 				  dependent on the controller)
  - touchscreen-fuzz-x		: horizontal noise value of the absolute input
-- 
2.18.0

[PATCH resend v2 2/2] Input: of_touchscreen - Add support for touchscreen-min-x|y

[Hans de Goede]

Some touchscreens, depending on the firmware and/or the digitizer report
coordinates which never reach 0 along one or both of their axis.

This has been seen for example on the Silead touchscreens on a Onda V891w
and a Point of View mobii TAB-P800w(v2.0).

This commit adds support for touchscreen-min-x and touchscreen-min-y
device-properties which can be set to communicate the actual start
coordinates (rather then 0,0) to userspace.

When set this fixes e.g. not being able to click things in the GNOME3
top-bar on the 2 example tablets.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-The dt-bindings changes have been split out into a separate patch
---
 drivers/input/touchscreen/of_touchscreen.c | 36 +++++++++++++++++-----
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/input/touchscreen/of_touchscreen.c b/drivers/input/touchscreen/of_touchscreen.c
index 9642f103b726..6d241d45e312 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -35,7 +35,7 @@ static bool touchscreen_get_prop_u32(struct device *dev,
 
 static void touchscreen_set_params(struct input_dev *dev,
 				   unsigned long axis,
-				   int max, int fuzz)
+				   int min, int max, int fuzz)
 {
 	struct input_absinfo *absinfo;
 
@@ -47,6 +47,7 @@ static void touchscreen_set_params(struct input_dev *dev,
 	}
 
 	absinfo = &dev->absinfo[axis];
+	absinfo->minimum = min;
 	absinfo->maximum = max;
 	absinfo->fuzz = fuzz;
 }
@@ -68,8 +69,9 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 				  struct touchscreen_properties *prop)
 {
 	struct device *dev = input->dev.parent;
+	struct input_absinfo *absinfo;
 	unsigned int axis;
-	unsigned int maximum, fuzz;
+	unsigned int minimum, maximum, fuzz;
 	bool data_present;
 
 	input_alloc_absinfo(input);
@@ -77,7 +79,10 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 		return;
 
 	axis = multitouch ? ABS_MT_POSITION_X : ABS_X;
-	data_present = touchscreen_get_prop_u32(dev, "touchscreen-size-x",
+	data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
+						input_abs_get_min(input, axis),
+						&minimum) |
+		       touchscreen_get_prop_u32(dev, "touchscreen-size-x",
 						input_abs_get_max(input,
 								  axis) + 1,
 						&maximum) |
@@ -85,10 +90,13 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 						input_abs_get_fuzz(input, axis),
 						&fuzz);
 	if (data_present)
-		touchscreen_set_params(input, axis, maximum - 1, fuzz);
+		touchscreen_set_params(input, axis, minimum, maximum - 1, fuzz);
 
 	axis = multitouch ? ABS_MT_POSITION_Y : ABS_Y;
-	data_present = touchscreen_get_prop_u32(dev, "touchscreen-size-y",
+	data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
+						input_abs_get_min(input, axis),
+						&minimum) |
+		       touchscreen_get_prop_u32(dev, "touchscreen-size-y",
 						input_abs_get_max(input,
 								  axis) + 1,
 						&maximum) |
@@ -96,7 +104,7 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 						input_abs_get_fuzz(input, axis),
 						&fuzz);
 	if (data_present)
-		touchscreen_set_params(input, axis, maximum - 1, fuzz);
+		touchscreen_set_params(input, axis, minimum, maximum - 1, fuzz);
 
 	axis = multitouch ? ABS_MT_PRESSURE : ABS_PRESSURE;
 	data_present = touchscreen_get_prop_u32(dev,
@@ -108,7 +116,7 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 						input_abs_get_fuzz(input, axis),
 						&fuzz);
 	if (data_present)
-		touchscreen_set_params(input, axis, maximum, fuzz);
+		touchscreen_set_params(input, axis, 0, maximum, fuzz);
 
 	if (!prop)
 		return;
@@ -117,13 +125,25 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 
 	prop->max_x = input_abs_get_max(input, axis);
 	prop->max_y = input_abs_get_max(input, axis + 1);
+
 	prop->invert_x =
 		device_property_read_bool(dev, "touchscreen-inverted-x");
+	if (prop->invert_x) {
+		absinfo = &input->absinfo[axis];
+		absinfo->maximum -= absinfo->minimum;
+		absinfo->minimum = 0;
+	}
+
 	prop->invert_y =
 		device_property_read_bool(dev, "touchscreen-inverted-y");
+	if (prop->invert_y) {
+		absinfo = &input->absinfo[axis + 1];
+		absinfo->maximum -= absinfo->minimum;
+		absinfo->minimum = 0;
+	}
+
 	prop->swap_x_y =
 		device_property_read_bool(dev, "touchscreen-swapped-x-y");
-
 	if (prop->swap_x_y)
 		swap(input->absinfo[axis], input->absinfo[axis + 1]);
 }
-- 
2.18.0

Re: [PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Dmitry Torokhov]

Hi Hans,

On Tue, Jul 31, 2018 at 01:19:57PM +0200, Hans de Goede wrote:
> Some touchscreens, depending on the firmware and/or the digitizer report
> coordinates which never reach 0 along one or both of their axis.
> 
> This has been seen for example on the Silead touchscreens on a Onda V891w
> and a Point of View mobii TAB-P800w(v2.0).
> 
> This commits documents 2 new touchscreen properties for communicating
> the minimum reported values to the OS: touchscreen-min-x and -min-y.
> 
> This commit also drop the (in pixels) comment from the documentation
> of the touchscreen-size-x and touchscreen-size-y properties. This comment
> suggests that there is a relation between the range of reported
> coordinates and the display resolution, which is only true for some
> devices. The (in pixels) comment is replaced with "(maximum x coordinate
> reported + 1)" to mirror the language describing the new touchscreen-min-x
> and -min-y properties.

I am concerned that people will not read the documentation carefully and
will treat it as true size, since it is what in the name. Maybe we
should say that it is size of usable area, in device units, and that
maximum reported coordinate is "touchscreen-min-x + touchscreen-size-x -
1"?

Thanks.

-- 
Dmitry

Re: [PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Hans de Goede]

Hi,

I completely missed this mail earlier, sorry.

Thank you Benjamin for pointing this out to me.

On 03-08-18 02:31, Dmitry Torokhov wrote:
> Hi Hans,
> 
> On Tue, Jul 31, 2018 at 01:19:57PM +0200, Hans de Goede wrote:
>> Some touchscreens, depending on the firmware and/or the digitizer report
>> coordinates which never reach 0 along one or both of their axis.
>>
>> This has been seen for example on the Silead touchscreens on a Onda V891w
>> and a Point of View mobii TAB-P800w(v2.0).
>>
>> This commits documents 2 new touchscreen properties for communicating
>> the minimum reported values to the OS: touchscreen-min-x and -min-y.
>>
>> This commit also drop the (in pixels) comment from the documentation
>> of the touchscreen-size-x and touchscreen-size-y properties. This comment
>> suggests that there is a relation between the range of reported
>> coordinates and the display resolution, which is only true for some
>> devices. The (in pixels) comment is replaced with "(maximum x coordinate
>> reported + 1)" to mirror the language describing the new touchscreen-min-x
>> and -min-y properties.
> 
> I am concerned that people will not read the documentation carefully and
> will treat it as true size, since it is what in the name. Maybe we
> should say that it is size of usable area, in device units, and that
> maximum reported coordinate is "touchscreen-min-x + touchscreen-size-x -
> 1"?

Not sure what you mean with "true size" but in the implementation
from this series, the maximum coordinated reported is (touchscreen-size-x - 1)
not (touchscreen-min-x + touchscreen-size-x - 1) as you suggest.

Basically what this series does is set:

input_absinfo.minimum to the new touchscreen-min-x value (or 0 if not specified)
input_absinfo.maximum to touchscreen-size-x - 1 as we've always done.

So the usable range / the range mapping from one screen edge to the other is:

touchscreen-min-x - (touchscreen-size-x - 1)

Which matches with the dt bindings doc after this patch, which
reads after this patch:

  - touchscreen-min-x		: minimum x coordinate reported (0 if not set)
  - touchscreen-min-y		: minimum y coordinate reported (0 if not set)
  - touchscreen-size-x		: horizontal resolution of touchscreen
				  (maximum x coordinate reported + 1)
  - touchscreen-size-y		: vertical resolution of touchscreen
				  (maximum y coordinate reported + 1)

I hope this clarifies things and if you want to change anything let
me know.

Regards,

Hans

Re: [PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Dmitry Torokhov]

Hi Hans,

Sorry, now I was being slow as well.

On Thu, Sep 20, 2018 at 07:31:43PM +0200, Hans de Goede wrote:
> Hi,
> 
> I completely missed this mail earlier, sorry.
> 
> Thank you Benjamin for pointing this out to me.
> 
> On 03-08-18 02:31, Dmitry Torokhov wrote:
> > Hi Hans,
> > 
> > On Tue, Jul 31, 2018 at 01:19:57PM +0200, Hans de Goede wrote:
> > > Some touchscreens, depending on the firmware and/or the digitizer report
> > > coordinates which never reach 0 along one or both of their axis.
> > > 
> > > This has been seen for example on the Silead touchscreens on a Onda V891w
> > > and a Point of View mobii TAB-P800w(v2.0).
> > > 
> > > This commits documents 2 new touchscreen properties for communicating
> > > the minimum reported values to the OS: touchscreen-min-x and -min-y.
> > > 
> > > This commit also drop the (in pixels) comment from the documentation
> > > of the touchscreen-size-x and touchscreen-size-y properties. This comment
> > > suggests that there is a relation between the range of reported
> > > coordinates and the display resolution, which is only true for some
> > > devices. The (in pixels) comment is replaced with "(maximum x coordinate
> > > reported + 1)" to mirror the language describing the new touchscreen-min-x
> > > and -min-y properties.
> > 
> > I am concerned that people will not read the documentation carefully and
> > will treat it as true size, since it is what in the name. Maybe we
> > should say that it is size of usable area, in device units, and that
> > maximum reported coordinate is "touchscreen-min-x + touchscreen-size-x -
> > 1"?
> 
> Not sure what you mean with "true size" but in the implementation
> from this series, the maximum coordinated reported is (touchscreen-size-x - 1)
> not (touchscreen-min-x + touchscreen-size-x - 1) as you suggest.
> 
> Basically what this series does is set:
> 
> input_absinfo.minimum to the new touchscreen-min-x value (or 0 if not specified)
> input_absinfo.maximum to touchscreen-size-x - 1 as we've always done.
> 
> So the usable range / the range mapping from one screen edge to the other is:
> 
> touchscreen-min-x - (touchscreen-size-x - 1)
> 
> Which matches with the dt bindings doc after this patch, which
> reads after this patch:
> 
>  - touchscreen-min-x		: minimum x coordinate reported (0 if not set)
>  - touchscreen-min-y		: minimum y coordinate reported (0 if not set)
>  - touchscreen-size-x		: horizontal resolution of touchscreen
> 				  (maximum x coordinate reported + 1)
>  - touchscreen-size-y		: vertical resolution of touchscreen
> 				  (maximum y coordinate reported + 1)
> 
> I hope this clarifies things and if you want to change anything let
> me know.

Right, except that my concern is that people do not read documentation,
and therefore will not realize that touchscreen-size-x is not the "true"
what I called it, or what you call usable range, but rather maximum
coordinate (-1).  IOW I am concerned that if we have a device with
640x480 screen for example, and touch controller reporting coordinates
with offset of 20, someone will specify:

touchscreen-min-x = 20
touchscreen-size-x = 640 (because that's their screen size)

and will not notice for some reason and later quirk it in their
software.

So I was asking if we should accommodate this, and actually set up max
on axis as "touchscreen-min-x + touchscreen-size-x - 1". It will still
be compatible with current bindings (having effectively min of 0), but
to me better reflects the name of the parameter - size of the screen.

Please let me know if this makes any sense to you.

Thanks.

-- 
Dmitry

Re: [PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Hans de Goede]

Hi,

On 11-10-18 02:52, Dmitry Torokhov wrote:
> Hi Hans,
> 
> Sorry, now I was being slow as well.

No problem.

> On Thu, Sep 20, 2018 at 07:31:43PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> I completely missed this mail earlier, sorry.
>>
>> Thank you Benjamin for pointing this out to me.
>>
>> On 03-08-18 02:31, Dmitry Torokhov wrote:
>>> Hi Hans,
>>>
>>> On Tue, Jul 31, 2018 at 01:19:57PM +0200, Hans de Goede wrote:
>>>> Some touchscreens, depending on the firmware and/or the digitizer report
>>>> coordinates which never reach 0 along one or both of their axis.
>>>>
>>>> This has been seen for example on the Silead touchscreens on a Onda V891w
>>>> and a Point of View mobii TAB-P800w(v2.0).
>>>>
>>>> This commits documents 2 new touchscreen properties for communicating
>>>> the minimum reported values to the OS: touchscreen-min-x and -min-y.
>>>>
>>>> This commit also drop the (in pixels) comment from the documentation
>>>> of the touchscreen-size-x and touchscreen-size-y properties. This comment
>>>> suggests that there is a relation between the range of reported
>>>> coordinates and the display resolution, which is only true for some
>>>> devices. The (in pixels) comment is replaced with "(maximum x coordinate
>>>> reported + 1)" to mirror the language describing the new touchscreen-min-x
>>>> and -min-y properties.
>>>
>>> I am concerned that people will not read the documentation carefully and
>>> will treat it as true size, since it is what in the name. Maybe we
>>> should say that it is size of usable area, in device units, and that
>>> maximum reported coordinate is "touchscreen-min-x + touchscreen-size-x -
>>> 1"?
>>
>> Not sure what you mean with "true size" but in the implementation
>> from this series, the maximum coordinated reported is (touchscreen-size-x - 1)
>> not (touchscreen-min-x + touchscreen-size-x - 1) as you suggest.
>>
>> Basically what this series does is set:
>>
>> input_absinfo.minimum to the new touchscreen-min-x value (or 0 if not specified)
>> input_absinfo.maximum to touchscreen-size-x - 1 as we've always done.
>>
>> So the usable range / the range mapping from one screen edge to the other is:
>>
>> touchscreen-min-x - (touchscreen-size-x - 1)
>>
>> Which matches with the dt bindings doc after this patch, which
>> reads after this patch:
>>
>>   - touchscreen-min-x		: minimum x coordinate reported (0 if not set)
>>   - touchscreen-min-y		: minimum y coordinate reported (0 if not set)
>>   - touchscreen-size-x		: horizontal resolution of touchscreen
>> 				  (maximum x coordinate reported + 1)
>>   - touchscreen-size-y		: vertical resolution of touchscreen
>> 				  (maximum y coordinate reported + 1)
>>
>> I hope this clarifies things and if you want to change anything let
>> me know.
> 
> Right, except that my concern is that people do not read documentation,
> and therefore will not realize that touchscreen-size-x is not the "true"
> what I called it, or what you call usable range, but rather maximum
> coordinate (-1).  IOW I am concerned that if we have a device with
> 640x480 screen for example, and touch controller reporting coordinates
> with offset of 20, someone will specify:
> 
> touchscreen-min-x = 20
> touchscreen-size-x = 640 (because that's their screen size)
> 
> and will not notice for some reason and later quirk it in their
> software.

Ah I see.

> So I was asking if we should accommodate this, and actually set up max
> on axis as "touchscreen-min-x + touchscreen-size-x - 1". It will still
> be compatible with current bindings (having effectively min of 0), but
> to me better reflects the name of the parameter - size of the screen.
> 
> Please let me know if this makes any sense to you.

I understand what you want now and why you want it.

But I'm not sure I agree with you. Some pre-cursor to this patch series
actually had something like touchscreen-offset-x (or some-such I don't
remember) which actually subtracted the specified value from the coordinates
reported to userspace (clamping to 0).

In that setup I think setting:

touchscreen-size-x = (maximum x coordinate reported + 1) -
                      (minimum x coordinate reported.

Makes sense, but since now we are not doing that and just copying the
values over to input_absinfo.minimum/maximum I think a 1:1 mapping
(with the - 1 adjustment for size) makes more sense.

The way I'm currently using this is with touchscreens where we cannot
read this info from the hardware, so I repeatedly move my finger over
each edge noting down the min / max value for e.g. the left/right
edge and then directly putting these into the properties.

IMHO not having to do some math here to calculate the right value
for touchscreen-size-x shows that treating touchscreen-size-x as
(touchscreen-max-x + 1) is the right thing to do.

I'm actually worried that if we follow your suggestion people will
indeed not read the docs and thus not do the math. I think they will
just copy over the min / max readings and we and up with an
input_absinfo.maximum value which is input_absinfo.minimum
units too big.

Regards,

Hans

Re: [PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Dmitry Torokhov]

On Thu, Oct 11, 2018 at 11:09:49AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 11-10-18 02:52, Dmitry Torokhov wrote:
> > Hi Hans,
> > 
> > Sorry, now I was being slow as well.
> 
> No problem.
> 
> > On Thu, Sep 20, 2018 at 07:31:43PM +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > I completely missed this mail earlier, sorry.
> > > 
> > > Thank you Benjamin for pointing this out to me.
> > > 
> > > On 03-08-18 02:31, Dmitry Torokhov wrote:
> > > > Hi Hans,
> > > > 
> > > > On Tue, Jul 31, 2018 at 01:19:57PM +0200, Hans de Goede wrote:
> > > > > Some touchscreens, depending on the firmware and/or the digitizer report
> > > > > coordinates which never reach 0 along one or both of their axis.
> > > > > 
> > > > > This has been seen for example on the Silead touchscreens on a Onda V891w
> > > > > and a Point of View mobii TAB-P800w(v2.0).
> > > > > 
> > > > > This commits documents 2 new touchscreen properties for communicating
> > > > > the minimum reported values to the OS: touchscreen-min-x and -min-y.
> > > > > 
> > > > > This commit also drop the (in pixels) comment from the documentation
> > > > > of the touchscreen-size-x and touchscreen-size-y properties. This comment
> > > > > suggests that there is a relation between the range of reported
> > > > > coordinates and the display resolution, which is only true for some
> > > > > devices. The (in pixels) comment is replaced with "(maximum x coordinate
> > > > > reported + 1)" to mirror the language describing the new touchscreen-min-x
> > > > > and -min-y properties.
> > > > 
> > > > I am concerned that people will not read the documentation carefully and
> > > > will treat it as true size, since it is what in the name. Maybe we
> > > > should say that it is size of usable area, in device units, and that
> > > > maximum reported coordinate is "touchscreen-min-x + touchscreen-size-x -
> > > > 1"?
> > > 
> > > Not sure what you mean with "true size" but in the implementation
> > > from this series, the maximum coordinated reported is (touchscreen-size-x - 1)
> > > not (touchscreen-min-x + touchscreen-size-x - 1) as you suggest.
> > > 
> > > Basically what this series does is set:
> > > 
> > > input_absinfo.minimum to the new touchscreen-min-x value (or 0 if not specified)
> > > input_absinfo.maximum to touchscreen-size-x - 1 as we've always done.
> > > 
> > > So the usable range / the range mapping from one screen edge to the other is:
> > > 
> > > touchscreen-min-x - (touchscreen-size-x - 1)
> > > 
> > > Which matches with the dt bindings doc after this patch, which
> > > reads after this patch:
> > > 
> > >   - touchscreen-min-x		: minimum x coordinate reported (0 if not set)
> > >   - touchscreen-min-y		: minimum y coordinate reported (0 if not set)
> > >   - touchscreen-size-x		: horizontal resolution of touchscreen
> > > 				  (maximum x coordinate reported + 1)
> > >   - touchscreen-size-y		: vertical resolution of touchscreen
> > > 				  (maximum y coordinate reported + 1)
> > > 
> > > I hope this clarifies things and if you want to change anything let
> > > me know.
> > 
> > Right, except that my concern is that people do not read documentation,
> > and therefore will not realize that touchscreen-size-x is not the "true"
> > what I called it, or what you call usable range, but rather maximum
> > coordinate (-1).  IOW I am concerned that if we have a device with
> > 640x480 screen for example, and touch controller reporting coordinates
> > with offset of 20, someone will specify:
> > 
> > touchscreen-min-x = 20
> > touchscreen-size-x = 640 (because that's their screen size)
> > 
> > and will not notice for some reason and later quirk it in their
> > software.
> 
> Ah I see.
> 
> > So I was asking if we should accommodate this, and actually set up max
> > on axis as "touchscreen-min-x + touchscreen-size-x - 1". It will still
> > be compatible with current bindings (having effectively min of 0), but
> > to me better reflects the name of the parameter - size of the screen.
> > 
> > Please let me know if this makes any sense to you.
> 
> I understand what you want now and why you want it.
> 
> But I'm not sure I agree with you. Some pre-cursor to this patch series
> actually had something like touchscreen-offset-x (or some-such I don't
> remember) which actually subtracted the specified value from the coordinates
> reported to userspace (clamping to 0).
> 
> In that setup I think setting:
> 
> touchscreen-size-x = (maximum x coordinate reported + 1) -
>                      (minimum x coordinate reported.
> 
> Makes sense, but since now we are not doing that and just copying the
> values over to input_absinfo.minimum/maximum I think a 1:1 mapping
> (with the - 1 adjustment for size) makes more sense.
> 
> The way I'm currently using this is with touchscreens where we cannot
> read this info from the hardware, so I repeatedly move my finger over
> each edge noting down the min / max value for e.g. the left/right
> edge and then directly putting these into the properties.
> 
> IMHO not having to do some math here to calculate the right value
> for touchscreen-size-x shows that treating touchscreen-size-x as
> (touchscreen-max-x + 1) is the right thing to do.
> 
> I'm actually worried that if we follow your suggestion people will
> indeed not read the docs and thus not do the math. I think they will
> just copy over the min / max readings and we and up with an
> input_absinfo.maximum value which is input_absinfo.minimum
> units too big.

I see. OK, let's keep it your way. Applied.

Thanks.

-- 
Dmitry

Re: [PATCH resend v2 1/2] Input: touchscreen DT binding - add touchscreen-min-x and -min-y properties

[Hans de Goede]

Hi,

On 12-10-18 02:11, Dmitry Torokhov wrote:
> On Thu, Oct 11, 2018 at 11:09:49AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 11-10-18 02:52, Dmitry Torokhov wrote:
>>> Hi Hans,
>>>
>>> Sorry, now I was being slow as well.
>>
>> No problem.
>>
>>> On Thu, Sep 20, 2018 at 07:31:43PM +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I completely missed this mail earlier, sorry.
>>>>
>>>> Thank you Benjamin for pointing this out to me.
>>>>
>>>> On 03-08-18 02:31, Dmitry Torokhov wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On Tue, Jul 31, 2018 at 01:19:57PM +0200, Hans de Goede wrote:
>>>>>> Some touchscreens, depending on the firmware and/or the digitizer report
>>>>>> coordinates which never reach 0 along one or both of their axis.
>>>>>>
>>>>>> This has been seen for example on the Silead touchscreens on a Onda V891w
>>>>>> and a Point of View mobii TAB-P800w(v2.0).
>>>>>>
>>>>>> This commits documents 2 new touchscreen properties for communicating
>>>>>> the minimum reported values to the OS: touchscreen-min-x and -min-y.
>>>>>>
>>>>>> This commit also drop the (in pixels) comment from the documentation
>>>>>> of the touchscreen-size-x and touchscreen-size-y properties. This comment
>>>>>> suggests that there is a relation between the range of reported
>>>>>> coordinates and the display resolution, which is only true for some
>>>>>> devices. The (in pixels) comment is replaced with "(maximum x coordinate
>>>>>> reported + 1)" to mirror the language describing the new touchscreen-min-x
>>>>>> and -min-y properties.
>>>>>
>>>>> I am concerned that people will not read the documentation carefully and
>>>>> will treat it as true size, since it is what in the name. Maybe we
>>>>> should say that it is size of usable area, in device units, and that
>>>>> maximum reported coordinate is "touchscreen-min-x + touchscreen-size-x -
>>>>> 1"?
>>>>
>>>> Not sure what you mean with "true size" but in the implementation
>>>> from this series, the maximum coordinated reported is (touchscreen-size-x - 1)
>>>> not (touchscreen-min-x + touchscreen-size-x - 1) as you suggest.
>>>>
>>>> Basically what this series does is set:
>>>>
>>>> input_absinfo.minimum to the new touchscreen-min-x value (or 0 if not specified)
>>>> input_absinfo.maximum to touchscreen-size-x - 1 as we've always done.
>>>>
>>>> So the usable range / the range mapping from one screen edge to the other is:
>>>>
>>>> touchscreen-min-x - (touchscreen-size-x - 1)
>>>>
>>>> Which matches with the dt bindings doc after this patch, which
>>>> reads after this patch:
>>>>
>>>>    - touchscreen-min-x		: minimum x coordinate reported (0 if not set)
>>>>    - touchscreen-min-y		: minimum y coordinate reported (0 if not set)
>>>>    - touchscreen-size-x		: horizontal resolution of touchscreen
>>>> 				  (maximum x coordinate reported + 1)
>>>>    - touchscreen-size-y		: vertical resolution of touchscreen
>>>> 				  (maximum y coordinate reported + 1)
>>>>
>>>> I hope this clarifies things and if you want to change anything let
>>>> me know.
>>>
>>> Right, except that my concern is that people do not read documentation,
>>> and therefore will not realize that touchscreen-size-x is not the "true"
>>> what I called it, or what you call usable range, but rather maximum
>>> coordinate (-1).  IOW I am concerned that if we have a device with
>>> 640x480 screen for example, and touch controller reporting coordinates
>>> with offset of 20, someone will specify:
>>>
>>> touchscreen-min-x = 20
>>> touchscreen-size-x = 640 (because that's their screen size)
>>>
>>> and will not notice for some reason and later quirk it in their
>>> software.
>>
>> Ah I see.
>>
>>> So I was asking if we should accommodate this, and actually set up max
>>> on axis as "touchscreen-min-x + touchscreen-size-x - 1". It will still
>>> be compatible with current bindings (having effectively min of 0), but
>>> to me better reflects the name of the parameter - size of the screen.
>>>
>>> Please let me know if this makes any sense to you.
>>
>> I understand what you want now and why you want it.
>>
>> But I'm not sure I agree with you. Some pre-cursor to this patch series
>> actually had something like touchscreen-offset-x (or some-such I don't
>> remember) which actually subtracted the specified value from the coordinates
>> reported to userspace (clamping to 0).
>>
>> In that setup I think setting:
>>
>> touchscreen-size-x = (maximum x coordinate reported + 1) -
>>                       (minimum x coordinate reported.
>>
>> Makes sense, but since now we are not doing that and just copying the
>> values over to input_absinfo.minimum/maximum I think a 1:1 mapping
>> (with the - 1 adjustment for size) makes more sense.
>>
>> The way I'm currently using this is with touchscreens where we cannot
>> read this info from the hardware, so I repeatedly move my finger over
>> each edge noting down the min / max value for e.g. the left/right
>> edge and then directly putting these into the properties.
>>
>> IMHO not having to do some math here to calculate the right value
>> for touchscreen-size-x shows that treating touchscreen-size-x as
>> (touchscreen-max-x + 1) is the right thing to do.
>>
>> I'm actually worried that if we follow your suggestion people will
>> indeed not read the docs and thus not do the math. I think they will
>> just copy over the min / max readings and we and up with an
>> input_absinfo.maximum value which is input_absinfo.minimum
>> units too big.
> 
> I see. OK, let's keep it your way. Applied.

Thank you.

It seems you've not yet pushed your branch with these though ?

Regards,

Hans