[PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V9:
* added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
* make the tsc2007 iio patch the last one in this sequence

2016-11-22 15:02:42: Changes V8:
* fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23@kernel.org>)
* add some more Reviewed-by: and Acked-by:
* mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>:
** drop patch "send pendown and penup only once" (input core does take care of it now)
** remove not necessary EXPORT_SYMBOL
** remove explicit file names from comment header
** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
** remove unnecessary input_unregister_device() 
** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y

2016-11-11 20:02:11: Changes V7:
* rearranged the include files (asked for by Jonathan Cameron <jic23@kernel.org>)
* forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
* add some Acked-by:

2016-10-27 10:44:29: Changes V6:
* iio patch (no changes elsewhere)
	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
	- tsc2007_iio: fix copyright (this file is 100% original work)

2016-10-25 21:26:46: Changes V5:
* ads7846: remove an empty line (suggested by Andrew F. Davis <afd@ti.com>)
* ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd@ti.com>)
* tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
* refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23@kernel.org>)

2016-10-17 16:00:02: Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron <jic23@kernel.org>)
* make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23@kernel.org>)
* swapped patch 3/n and patch 4/n to remove internal dependency

2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")

2015-11-13 21:36:07: Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)

2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by
commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):

	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
    flipping and rotation
  drivers:input:tsc2007: check for presence and power down tsc2007
    during probe
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
    pre-calibration and flipping
  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings
  drivers:input:tsc2007: add iio interface to read external ADC input
    and temperature

 .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
 .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
 drivers/input/touchscreen/Kconfig                  |  10 +
 drivers/input/touchscreen/Makefile                 |   2 +
 drivers/input/touchscreen/ads7846.c                |  71 ++++++--
 drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
 .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
 drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
 include/linux/i2c/tsc2007.h                        |   8 +
 13 files changed, 520 insertions(+), 114 deletions(-)
 rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

-- 
2.7.3

[PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V9:
* added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>)
* make the tsc2007 iio patch the last one in this sequence

2016-11-22 15:02:42: Changes V8:
* fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* add some more Reviewed-by: and Acked-by:
* mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
** drop patch "send pendown and penup only once" (input core does take care of it now)
** remove not necessary EXPORT_SYMBOL
** remove explicit file names from comment header
** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
** remove unnecessary input_unregister_device() 
** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y

2016-11-11 20:02:11: Changes V7:
* rearranged the include files (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* add some Acked-by:

2016-10-27 10:44:29: Changes V6:
* iio patch (no changes elsewhere)
	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
	- tsc2007_iio: fix copyright (this file is 100% original work)

2016-10-25 21:26:46: Changes V5:
* ads7846: remove an empty line (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
* ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
* tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
* refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)

2016-10-17 16:00:02: Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* swapped patch 3/n and patch 4/n to remove internal dependency

2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")

2015-11-13 21:36:07: Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)

2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by
commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):

	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
    flipping and rotation
  drivers:input:tsc2007: check for presence and power down tsc2007
    during probe
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
    pre-calibration and flipping
  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings
  drivers:input:tsc2007: add iio interface to read external ADC input
    and temperature

 .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
 .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
 drivers/input/touchscreen/Kconfig                  |  10 +
 drivers/input/touchscreen/Makefile                 |   2 +
 drivers/input/touchscreen/ads7846.c                |  71 ++++++--
 drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
 .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
 drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
 include/linux/i2c/tsc2007.h                        |   8 +
 13 files changed, 520 insertions(+), 114 deletions(-)
 rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

-- 
2.7.3

[PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

Please note that the old ti,fuzz properties have been removed since they
are replaced by the common bindings touchscreen-fuzz-x/y/z.

Finally, calculate_pressure has been renamed to calculate_resistance
because that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 .../bindings/input/touchscreen/tsc2007.txt         |  20 ++--
 drivers/input/touchscreen/tsc2007.c                | 120 +++++++++++++++++----
 include/linux/i2c/tsc2007.h                        |   8 ++
 3 files changed, 118 insertions(+), 30 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 	&i2c1 {
@@ -35,6 +39,8 @@ Example:
 			interrupts = <0x0 0x8>;
 			gpios = <&gpio4 0 0>;
 			ti,x-plate-ohms = <180>;
+			touchscreen-size-x = <640>;
+			touchscreen-size-y = <480>;
 		};
 
 		/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include <linux/of_device.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/input/touchscreen.h>
 
 #define TSC2007_MEASURE_TEMP0		(0x0 << 4)
 #define TSC2007_MEASURE_AUX		(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
 	u16			model;
 	u16			x_plate_ohms;
+
+	struct touchscreen_properties prop;
+
+	bool			report_resistance;
+	u16			min_x;
+	u16			min_y;
+	u16			max_x;
+	u16			max_y;
 	u16			max_rt;
 	unsigned long		poll_period; /* in jiffies */
 	int			fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
 	tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+					struct ts_event *tc)
 {
 	u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 	struct ts_event tc;
 	u32 rt;
 
+	dev_dbg(&ts->client->dev, "soft irq %d\n", irq);
 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
 		/* pen is down, continue with the measurement */
 		tsc2007_read_values(ts, &tc);
 
-		rt = tsc2007_calculate_pressure(ts, &tc);
+		rt = tsc2007_calculate_resistance(ts, &tc);
 
 		if (!rt && !ts->get_pendown_state) {
 			/*
@@ -194,21 +205,41 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 		}
 
 		if (rt <= ts->max_rt) {
+			int sx, sy;
+
 			dev_dbg(&ts->client->dev,
 				"DOWN point(%4d,%4d), pressure (%4u)\n",
 				tc.x, tc.y, rt);
 
+			if (!ts->report_resistance)
+				rt = ts->max_rt - rt;
+
+			/* scale ADC values to desired output range */
+			sx = (ts->prop.max_x * (tc.x - ts->min_x))
+				/ (ts->max_x - ts->min_x);
+			sy = (ts->prop.max_y * (tc.y - ts->min_y))
+				/ (ts->max_y - ts->min_y);
+			rt = (input->absinfo[ABS_PRESSURE].maximum * rt) /
+				ts->max_rt;
+
+			dev_dbg(&ts->client->dev,
+				"Scaled point(%4d,%4d), pressure (%4u)\n",
+				sx, sy, rt);
+
+			/* report event */
 			input_report_key(input, BTN_TOUCH, 1);
-			input_report_abs(input, ABS_X, tc.x);
-			input_report_abs(input, ABS_Y, tc.y);
+			touchscreen_report_pos(ts->input, &ts->prop,
+						(unsigned int) sx,
+						(unsigned int) sy,
+						false);
 			input_report_abs(input, ABS_PRESSURE, rt);
 
 			input_sync(input);
 
 		} else {
 			/*
-			 * Sample found inconsistent by debouncing or pressure is
-			 * beyond the maximum. Don't report it to user space,
+			 * Sample found inconsistent by debouncing or resistance
+			 * is beyond the maximum. Don't report it to user space,
 			 * repeat at least once more the measurement.
 			 */
 			dev_dbg(&ts->client->dev, "ignored pressure %d\n", rt);
@@ -233,6 +264,7 @@ static irqreturn_t tsc2007_hard_irq(int irq, void *handle)
 {
 	struct tsc2007 *ts = handle;
 
+	dev_dbg(&ts->client->dev, "hard irq %d\n", irq);
 	if (tsc2007_is_pen_down(ts))
 		return IRQ_WAKE_THREAD;
 
@@ -303,14 +335,24 @@ static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts)
 	else
 		ts->max_rt = MAX_12BIT;
 
-	if (!of_property_read_u32(np, "ti,fuzzx", &val32))
-		ts->fuzzx = val32;
+	ts->report_resistance =
+		       of_property_read_bool(np, "ti,report-resistance");
 
-	if (!of_property_read_u32(np, "ti,fuzzy", &val32))
-		ts->fuzzy = val32;
+	touchscreen_parse_properties(ts->input, false, &ts->prop);
 
-	if (!of_property_read_u32(np, "ti,fuzzz", &val32))
-		ts->fuzzz = val32;
+	if (!of_property_read_u32(np, "ti,min-x", &val32))
+		ts->min_x = val32;
+	if (!of_property_read_u32(np, "ti,max-x", &val32))
+		ts->max_x = val32;
+	else
+		ts->max_x = MAX_12BIT;
+
+	if (!of_property_read_u32(np, "ti,min-y", &val32))
+		ts->min_y = val32;
+	if (!of_property_read_u32(np, "ti,max-y", &val32))
+		ts->max_y = val32;
+	else
+		ts->max_y = MAX_12BIT;
 
 	if (!of_property_read_u64(np, "ti,poll-period", &val64))
 		ts->poll_period = msecs_to_jiffies(val64);
@@ -332,6 +374,22 @@ static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts)
 			 "GPIO not specified in DT (of_get_gpio returned %d)\n",
 			 ts->gpio);
 
+	dev_dbg(&client->dev,
+			"min/max_x (%4d,%4d)\n",
+			ts->min_x, ts->max_x);
+	dev_dbg(&client->dev,
+			"min/max_y (%4d,%4d)\n",
+			ts->min_y, ts->max_y);
+	dev_dbg(&client->dev,
+			"max_rt (%4d)\n",
+			ts->max_rt);
+	dev_dbg(&client->dev,
+			"size (%4d,%4d)\n",
+			ts->prop.max_x, ts->prop.max_y);
+	dev_dbg(&client->dev,
+			"ts-gpio: %d\n",
+			ts->gpio);
+
 	return 0;
 }
 #else
@@ -349,6 +407,14 @@ static int tsc2007_probe_pdev(struct i2c_client *client, struct tsc2007 *ts,
 	ts->model             = pdata->model;
 	ts->x_plate_ohms      = pdata->x_plate_ohms;
 	ts->max_rt            = pdata->max_rt ? : MAX_12BIT;
+	ts->prop.swap_x_y     = pdata->swap_xy;
+	ts->prop.invert_x     = pdata->invert_x;
+	ts->prop.invert_y     = pdata->invert_y;
+	ts->report_resistance = pdata->report_resistance;
+	ts->min_x             = pdata->min_x ? : 0;
+	ts->min_y             = pdata->min_y ? : 0;
+	ts->max_x             = pdata->max_x ? : MAX_12BIT;
+	ts->max_y             = pdata->max_y ? : MAX_12BIT;
 	ts->poll_period       = msecs_to_jiffies(pdata->poll_period ? : 1);
 	ts->get_pendown_state = pdata->get_pendown_state;
 	ts->clear_penirq      = pdata->clear_penirq;
@@ -388,13 +454,6 @@ static int tsc2007_probe(struct i2c_client *client,
 	if (!ts)
 		return -ENOMEM;
 
-	if (pdata)
-		err = tsc2007_probe_pdev(client, ts, pdata, id);
-	else
-		err = tsc2007_probe_dt(client, ts);
-	if (err)
-		return err;
-
 	input_dev = devm_input_allocate_device(&client->dev);
 	if (!input_dev)
 		return -ENOMEM;
@@ -419,12 +478,25 @@ static int tsc2007_probe(struct i2c_client *client,
 	input_set_drvdata(input_dev, ts);
 
 	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+	input_dev->absbit[0] = BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) |
+				BIT_MASK(ABS_PRESSURE);
 	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
 
-	input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0);
-	input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
-	input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_12BIT,
-			     ts->fuzzz, 0);
+	if (pdata) {
+		err = tsc2007_probe_pdev(client, ts, pdata, id);
+		if (err)
+			return err;
+		input_set_abs_params(input_dev, ABS_X, 0, ts->max_x-ts->min_x,
+							  ts->fuzzx, 0);
+		input_set_abs_params(input_dev, ABS_Y, 0, ts->max_y-ts->min_y,
+							  ts->fuzzy, 0);
+		input_set_abs_params(input_dev, ABS_PRESSURE, 0, ts->max_rt,
+							  ts->fuzzz, 0);
+	} else {
+		err = tsc2007_probe_dt(client, ts);
+		if (err)
+			return err;
+	}
 
 	if (pdata) {
 		if (pdata->exit_platform_hw) {
@@ -443,6 +515,8 @@ static int tsc2007_probe(struct i2c_client *client,
 			pdata->init_platform_hw();
 	}
 
+	dev_dbg(&client->dev, "request irq %d\n",
+			ts->irq);
 	err = devm_request_threaded_irq(&client->dev, ts->irq,
 					tsc2007_hard_irq, tsc2007_soft_irq,
 					IRQF_ONESHOT,
diff --git a/include/linux/i2c/tsc2007.h b/include/linux/i2c/tsc2007.h
index 4f35b6a..632db20 100644
--- a/include/linux/i2c/tsc2007.h
+++ b/include/linux/i2c/tsc2007.h
@@ -6,6 +6,14 @@
 struct tsc2007_platform_data {
 	u16	model;				/* 2007. */
 	u16	x_plate_ohms;	/* must be non-zero value */
+	bool	swap_xy;	/* swap x and y axis */
+	bool	invert_x;
+	bool	invert_y;
+	bool	report_resistance;
+	u16	min_x;	/* min and max values reported by ADC */
+	u16	min_y;
+	u16	max_x;
+	u16	max_y;
 	u16	max_rt; /* max. resistance above which samples are ignored */
 	unsigned long poll_period; /* time (in ms) between samples */
 	int	fuzzx; /* fuzz factor for X, Y and pressure axes */
-- 
2.7.3

[PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

Please note that the old ti,fuzz properties have been removed since they
are replaced by the common bindings touchscreen-fuzz-x/y/z.

Finally, calculate_pressure has been renamed to calculate_resistance
because that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 .../bindings/input/touchscreen/tsc2007.txt         |  20 ++--
 drivers/input/touchscreen/tsc2007.c                | 120 +++++++++++++++++----
 include/linux/i2c/tsc2007.h                        |   8 ++
 3 files changed, 118 insertions(+), 30 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 	&i2c1 {
@@ -35,6 +39,8 @@ Example:
 			interrupts = <0x0 0x8>;
 			gpios = <&gpio4 0 0>;
 			ti,x-plate-ohms = <180>;
+			touchscreen-size-x = <640>;
+			touchscreen-size-y = <480>;
 		};
 
 		/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include <linux/of_device.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/input/touchscreen.h>
 
 #define TSC2007_MEASURE_TEMP0		(0x0 << 4)
 #define TSC2007_MEASURE_AUX		(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
 	u16			model;
 	u16			x_plate_ohms;
+
+	struct touchscreen_properties prop;
+
+	bool			report_resistance;
+	u16			min_x;
+	u16			min_y;
+	u16			max_x;
+	u16			max_y;
 	u16			max_rt;
 	unsigned long		poll_period; /* in jiffies */
 	int			fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
 	tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+					struct ts_event *tc)
 {
 	u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 	struct ts_event tc;
 	u32 rt;
 
+	dev_dbg(&ts->client->dev, "soft irq %d\n", irq);
 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
 		/* pen is down, continue with the measurement */
 		tsc2007_read_values(ts, &tc);
 
-		rt = tsc2007_calculate_pressure(ts, &tc);
+		rt = tsc2007_calculate_resistance(ts, &tc);
 
 		if (!rt && !ts->get_pendown_state) {
 			/*
@@ -194,21 +205,41 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 		}
 
 		if (rt <= ts->max_rt) {
+			int sx, sy;
+
 			dev_dbg(&ts->client->dev,
 				"DOWN point(%4d,%4d), pressure (%4u)\n",
 				tc.x, tc.y, rt);
 
+			if (!ts->report_resistance)
+				rt = ts->max_rt - rt;
+
+			/* scale ADC values to desired output range */
+			sx = (ts->prop.max_x * (tc.x - ts->min_x))
+				/ (ts->max_x - ts->min_x);
+			sy = (ts->prop.max_y * (tc.y - ts->min_y))
+				/ (ts->max_y - ts->min_y);
+			rt = (input->absinfo[ABS_PRESSURE].maximum * rt) /
+				ts->max_rt;
+
+			dev_dbg(&ts->client->dev,
+				"Scaled point(%4d,%4d), pressure (%4u)\n",
+				sx, sy, rt);
+
+			/* report event */
 			input_report_key(input, BTN_TOUCH, 1);
-			input_report_abs(input, ABS_X, tc.x);
-			input_report_abs(input, ABS_Y, tc.y);
+			touchscreen_report_pos(ts->input, &ts->prop,
+						(unsigned int) sx,
+						(unsigned int) sy,
+						false);
 			input_report_abs(input, ABS_PRESSURE, rt);
 
 			input_sync(input);
 
 		} else {
 			/*
-			 * Sample found inconsistent by debouncing or pressure is
-			 * beyond the maximum. Don't report it to user space,
+			 * Sample found inconsistent by debouncing or resistance
+			 * is beyond the maximum. Don't report it to user space,
 			 * repeat at least once more the measurement.
 			 */
 			dev_dbg(&ts->client->dev, "ignored pressure %d\n", rt);
@@ -233,6 +264,7 @@ static irqreturn_t tsc2007_hard_irq(int irq, void *handle)
 {
 	struct tsc2007 *ts = handle;
 
+	dev_dbg(&ts->client->dev, "hard irq %d\n", irq);
 	if (tsc2007_is_pen_down(ts))
 		return IRQ_WAKE_THREAD;
 
@@ -303,14 +335,24 @@ static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts)
 	else
 		ts->max_rt = MAX_12BIT;
 
-	if (!of_property_read_u32(np, "ti,fuzzx", &val32))
-		ts->fuzzx = val32;
+	ts->report_resistance =
+		       of_property_read_bool(np, "ti,report-resistance");
 
-	if (!of_property_read_u32(np, "ti,fuzzy", &val32))
-		ts->fuzzy = val32;
+	touchscreen_parse_properties(ts->input, false, &ts->prop);
 
-	if (!of_property_read_u32(np, "ti,fuzzz", &val32))
-		ts->fuzzz = val32;
+	if (!of_property_read_u32(np, "ti,min-x", &val32))
+		ts->min_x = val32;
+	if (!of_property_read_u32(np, "ti,max-x", &val32))
+		ts->max_x = val32;
+	else
+		ts->max_x = MAX_12BIT;
+
+	if (!of_property_read_u32(np, "ti,min-y", &val32))
+		ts->min_y = val32;
+	if (!of_property_read_u32(np, "ti,max-y", &val32))
+		ts->max_y = val32;
+	else
+		ts->max_y = MAX_12BIT;
 
 	if (!of_property_read_u64(np, "ti,poll-period", &val64))
 		ts->poll_period = msecs_to_jiffies(val64);
@@ -332,6 +374,22 @@ static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts)
 			 "GPIO not specified in DT (of_get_gpio returned %d)\n",
 			 ts->gpio);
 
+	dev_dbg(&client->dev,
+			"min/max_x (%4d,%4d)\n",
+			ts->min_x, ts->max_x);
+	dev_dbg(&client->dev,
+			"min/max_y (%4d,%4d)\n",
+			ts->min_y, ts->max_y);
+	dev_dbg(&client->dev,
+			"max_rt (%4d)\n",
+			ts->max_rt);
+	dev_dbg(&client->dev,
+			"size (%4d,%4d)\n",
+			ts->prop.max_x, ts->prop.max_y);
+	dev_dbg(&client->dev,
+			"ts-gpio: %d\n",
+			ts->gpio);
+
 	return 0;
 }
 #else
@@ -349,6 +407,14 @@ static int tsc2007_probe_pdev(struct i2c_client *client, struct tsc2007 *ts,
 	ts->model             = pdata->model;
 	ts->x_plate_ohms      = pdata->x_plate_ohms;
 	ts->max_rt            = pdata->max_rt ? : MAX_12BIT;
+	ts->prop.swap_x_y     = pdata->swap_xy;
+	ts->prop.invert_x     = pdata->invert_x;
+	ts->prop.invert_y     = pdata->invert_y;
+	ts->report_resistance = pdata->report_resistance;
+	ts->min_x             = pdata->min_x ? : 0;
+	ts->min_y             = pdata->min_y ? : 0;
+	ts->max_x             = pdata->max_x ? : MAX_12BIT;
+	ts->max_y             = pdata->max_y ? : MAX_12BIT;
 	ts->poll_period       = msecs_to_jiffies(pdata->poll_period ? : 1);
 	ts->get_pendown_state = pdata->get_pendown_state;
 	ts->clear_penirq      = pdata->clear_penirq;
@@ -388,13 +454,6 @@ static int tsc2007_probe(struct i2c_client *client,
 	if (!ts)
 		return -ENOMEM;
 
-	if (pdata)
-		err = tsc2007_probe_pdev(client, ts, pdata, id);
-	else
-		err = tsc2007_probe_dt(client, ts);
-	if (err)
-		return err;
-
 	input_dev = devm_input_allocate_device(&client->dev);
 	if (!input_dev)
 		return -ENOMEM;
@@ -419,12 +478,25 @@ static int tsc2007_probe(struct i2c_client *client,
 	input_set_drvdata(input_dev, ts);
 
 	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+	input_dev->absbit[0] = BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) |
+				BIT_MASK(ABS_PRESSURE);
 	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
 
-	input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0);
-	input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
-	input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_12BIT,
-			     ts->fuzzz, 0);
+	if (pdata) {
+		err = tsc2007_probe_pdev(client, ts, pdata, id);
+		if (err)
+			return err;
+		input_set_abs_params(input_dev, ABS_X, 0, ts->max_x-ts->min_x,
+							  ts->fuzzx, 0);
+		input_set_abs_params(input_dev, ABS_Y, 0, ts->max_y-ts->min_y,
+							  ts->fuzzy, 0);
+		input_set_abs_params(input_dev, ABS_PRESSURE, 0, ts->max_rt,
+							  ts->fuzzz, 0);
+	} else {
+		err = tsc2007_probe_dt(client, ts);
+		if (err)
+			return err;
+	}
 
 	if (pdata) {
 		if (pdata->exit_platform_hw) {
@@ -443,6 +515,8 @@ static int tsc2007_probe(struct i2c_client *client,
 			pdata->init_platform_hw();
 	}
 
+	dev_dbg(&client->dev, "request irq %d\n",
+			ts->irq);
 	err = devm_request_threaded_irq(&client->dev, ts->irq,
 					tsc2007_hard_irq, tsc2007_soft_irq,
 					IRQF_ONESHOT,
diff --git a/include/linux/i2c/tsc2007.h b/include/linux/i2c/tsc2007.h
index 4f35b6a..632db20 100644
--- a/include/linux/i2c/tsc2007.h
+++ b/include/linux/i2c/tsc2007.h
@@ -6,6 +6,14 @@
 struct tsc2007_platform_data {
 	u16	model;				/* 2007. */
 	u16	x_plate_ohms;	/* must be non-zero value */
+	bool	swap_xy;	/* swap x and y axis */
+	bool	invert_x;
+	bool	invert_y;
+	bool	report_resistance;
+	u16	min_x;	/* min and max values reported by ADC */
+	u16	min_y;
+	u16	max_x;
+	u16	max_y;
 	u16	max_rt; /* max. resistance above which samples are ignored */
 	unsigned long poll_period; /* time (in ms) between samples */
 	int	fuzzx; /* fuzz factor for X, Y and pressure axes */
-- 
2.7.3

[PATCH v9 2/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[H. Nikolaus Schaller]

1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/input/touchscreen/tsc2007.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index c1d9593..76b462b 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -529,6 +529,14 @@ static int tsc2007_probe(struct i2c_client *client,
 
 	tsc2007_stop(ts);
 
+	/* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+	err = tsc2007_xfer(ts, PWRDOWN);
+	if (err < 0) {
+		dev_err(&client->dev,
+			"Failed to setup chip: %d\n", err);
+		return err;	/* usually, chip does not respond */
+	}
+
 	err = input_register_device(input_dev);
 	if (err) {
 		dev_err(&client->dev,
-- 
2.7.3

[PATCH v9 2/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[H. Nikolaus Schaller]

1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/input/touchscreen/tsc2007.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index c1d9593..76b462b 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -529,6 +529,14 @@ static int tsc2007_probe(struct i2c_client *client,
 
 	tsc2007_stop(ts);
 
+	/* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+	err = tsc2007_xfer(ts, PWRDOWN);
+	if (err < 0) {
+		dev_err(&client->dev,
+			"Failed to setup chip: %d\n", err);
+		return err;	/* usually, chip does not respond */
+	}
+
 	err = input_register_device(input_dev);
 	if (err) {
 		dev_err(&client->dev,
-- 
2.7.3

[PATCH v9 3/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

While we fix the GTA04 we add proper pinmux for the
penirq gpio.

Tested on: GTA04A4 and Pyra-Handheld

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
 			OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4) /* gpio112 */
 		>;
 	};
+
+	penirq_pins: pinmux_penirq_pins {
+		pinctrl-single,pins = <
+			/* here we could enable to wakeup the cpu from suspend by a pen touch */
+			OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4) /* gpio160 */
+		>;
+	};
 };
 
 &omap3_pmx_core2 {
@@ -410,10 +417,24 @@
 	tsc2007@48 {
 		compatible = "ti,tsc2007";
 		reg = <0x48>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&penirq_pins>;
 		interrupt-parent = <&gpio6>;
 		interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-		gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
-		ti,x-plate-ohms = <600>;
+		gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;	/* GPIO_160 */
+		touchscreen-size-x = <480>;
+		touchscreen-size-y = <640>;
+		touchscreen-max-pressure = <1000>;
+		touchscreen-fuzz-x = <3>;
+		touchscreen-fuzz-y = <8>;
+		touchscreen-fuzz-pressure = <10>;
+		touchscreen-inverted-y;
+		ti,min-x = <0x100>;
+		ti,max-x = <0xf00>;
+		ti,min-y = <0x100>;
+		ti,max-y = <0xf00>;
+		ti,max-rt = <4096>;
+		ti,x-plate-ohms = <550>;
 	};
 
 	/* RFID EEPROM */
-- 
2.7.3

[PATCH v9 3/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

While we fix the GTA04 we add proper pinmux for the
penirq gpio.

Tested on: GTA04A4 and Pyra-Handheld

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
 			OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4) /* gpio112 */
 		>;
 	};
+
+	penirq_pins: pinmux_penirq_pins {
+		pinctrl-single,pins = <
+			/* here we could enable to wakeup the cpu from suspend by a pen touch */
+			OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4) /* gpio160 */
+		>;
+	};
 };
 
 &omap3_pmx_core2 {
@@ -410,10 +417,24 @@
 	tsc2007@48 {
 		compatible = "ti,tsc2007";
 		reg = <0x48>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&penirq_pins>;
 		interrupt-parent = <&gpio6>;
 		interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-		gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
-		ti,x-plate-ohms = <600>;
+		gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;	/* GPIO_160 */
+		touchscreen-size-x = <480>;
+		touchscreen-size-y = <640>;
+		touchscreen-max-pressure = <1000>;
+		touchscreen-fuzz-x = <3>;
+		touchscreen-fuzz-y = <8>;
+		touchscreen-fuzz-pressure = <10>;
+		touchscreen-inverted-y;
+		ti,min-x = <0x100>;
+		ti,max-x = <0xf00>;
+		ti,min-y = <0x100>;
+		ti,max-y = <0xf00>;
+		ti,max-rt = <4096>;
+		ti,x-plate-ohms = <550>;
 	};
 
 	/* RFID EEPROM */
-- 
2.7.3

[PATCH v9 4/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/input/ads7846.txt          |  9 +++-
 drivers/input/touchscreen/ads7846.c                | 60 ++++++++++++++++++----
 2 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt
index 9fc47b0..29f91ed 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,6 +26,12 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
 	ti,vref-delay-usecs		vref supply delay in usecs, 0 for
 					external vref (u16).
 	ti,vref-mv			The VREF voltage, in millivolts (u16).
@@ -33,7 +39,7 @@ Optional properties:
 					(ADS7846).
 	ti,keep-vref-on			set to keep vref on for differential
 					measurements as well
-	ti,swap-xy			swap x and y axis
+	ti,swap-xy			deprecated name for touchscreen-swapped-x-y
 	ti,settle-delay-usec		Settling time of the analog signals;
 					a function of Vcc and the capacitance
 					on the X/Y drivers.  If set to non-zero,
@@ -82,6 +88,7 @@ Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
 			pendown-gpio = <&gpio1 8 0>;
 			vcc-supply = <&reg_vcc3>;
 
+			touchscreen-swapped-x-y;
 			ti,x-min = /bits/ 16 <0>;
 			ti,x-max = /bits/ 16 <8000>;
 			ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 1ce3ecb..400e421 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include <linux/spi/ads7846.h>
 #include <linux/regulator/consumer.h>
 #include <linux/module.h>
+#include <linux/input/touchscreen.h>
 #include <asm/irq.h>
 
 /*
@@ -109,8 +110,13 @@ struct ads7846 {
 	u16			vref_delay_usecs;
 	u16			x_plate_ohms;
 	u16			pressure_max;
+	u16			x_min;
+	u16			x_max;
+	u16			y_min;
+	u16			y_max;
+
+	struct touchscreen_properties prop;
 
-	bool			swap_xy;
 	bool			use_internal;
 
 	struct ads7846_packet	*packet;
@@ -825,22 +831,36 @@ static void ads7846_report_state(struct ads7846 *ts)
 	 */
 	if (Rt) {
 		struct input_dev *input = ts->input;
+		int sx, sy;
+
+		dev_dbg(&ts->spi->dev,
+			"Raw point(%4d,%4d), pressure (%4u)\n",
+				x, y, Rt);
+
+		/* scale ADC values to desired output range */
+		sx = (ts->prop.max_x * (x - ts->x_min))
+			/ (ts->x_max - ts->x_min);
+		sy = (ts->prop.max_y * (y - ts->y_min))
+			/ (ts->y_max - ts->y_min);
 
-		if (ts->swap_xy)
-			swap(x, y);
+		dev_dbg(&ts->spi->dev,
+			"Scaled point(%4d,%4d), pressure (%4u)\n",
+				sx, sy, Rt);
 
+		/* report event */
 		if (!ts->pendown) {
 			input_report_key(input, BTN_TOUCH, 1);
 			ts->pendown = true;
 			dev_vdbg(&ts->spi->dev, "DOWN\n");
 		}
 
-		input_report_abs(input, ABS_X, x);
-		input_report_abs(input, ABS_Y, y);
+		touchscreen_report_pos(ts->input, &ts->prop,
+				       (unsigned int) sx, (unsigned int) sy,
+				       false);
 		input_report_abs(input, ABS_PRESSURE, ts->pressure_max - Rt);
 
 		input_sync(input);
-		dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", x, y, Rt);
+		dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", sx, sy, Rt);
 	}
 }
 
@@ -1212,6 +1232,8 @@ static const struct ads7846_platform_data *ads7846_probe_dt(struct device *dev)
 	pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
 
 	pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
+	if (pdata->swap_xy)
+		dev_notice(dev, "please update device tree to use touchscreen-swapped-x-y");
 
 	of_property_read_u16(node, "ti,settle-delay-usec",
 			     &pdata->settle_delay_usecs);
@@ -1315,7 +1337,6 @@ static int ads7846_probe(struct spi_device *spi)
 	ts->pressure_max = pdata->pressure_max ? : ~0;
 
 	ts->vref_mv = pdata->vref_mv;
-	ts->swap_xy = pdata->swap_xy;
 
 	if (pdata->filter != NULL) {
 		if (pdata->filter_init != NULL) {
@@ -1355,18 +1376,35 @@ static int ads7846_probe(struct spi_device *spi)
 	input_dev->dev.parent = &spi->dev;
 
 	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+	input_dev->absbit[0] = BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) |
+				BIT_MASK(ABS_PRESSURE);
 	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+	ts->x_min = pdata->x_min ? : 0;
+	ts->x_max = pdata->x_max ? : MAX_12BIT;
+	ts->y_min = pdata->y_min ? : 0;
+	ts->y_max = pdata->y_max ? : MAX_12BIT;
+
 	input_set_abs_params(input_dev, ABS_X,
-			pdata->x_min ? : 0,
-			pdata->x_max ? : MAX_12BIT,
+			ts->x_min,
+			ts->x_max,
 			0, 0);
 	input_set_abs_params(input_dev, ABS_Y,
-			pdata->y_min ? : 0,
-			pdata->y_max ? : MAX_12BIT,
+			ts->y_min,
+			ts->y_max,
 			0, 0);
 	input_set_abs_params(input_dev, ABS_PRESSURE,
 			pdata->pressure_min, pdata->pressure_max, 0, 0);
 
+	if (spi->dev.of_node) {
+		input_abs_set_min(input_dev, ABS_X, 0);
+		input_abs_set_min(input_dev, ABS_Y, 0);
+
+		touchscreen_parse_properties(ts->input, false, &ts->prop);
+	}
+
+	ts->prop.swap_x_y |= pdata->swap_xy;
+
 	ads7846_setup_spi_msg(ts, pdata);
 
 	ts->reg = regulator_get(&spi->dev, "vcc");
-- 
2.7.3

[PATCH v9 4/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/input/ads7846.txt          |  9 +++-
 drivers/input/touchscreen/ads7846.c                | 60 ++++++++++++++++++----
 2 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt
index 9fc47b0..29f91ed 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,6 +26,12 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
 	ti,vref-delay-usecs		vref supply delay in usecs, 0 for
 					external vref (u16).
 	ti,vref-mv			The VREF voltage, in millivolts (u16).
@@ -33,7 +39,7 @@ Optional properties:
 					(ADS7846).
 	ti,keep-vref-on			set to keep vref on for differential
 					measurements as well
-	ti,swap-xy			swap x and y axis
+	ti,swap-xy			deprecated name for touchscreen-swapped-x-y
 	ti,settle-delay-usec		Settling time of the analog signals;
 					a function of Vcc and the capacitance
 					on the X/Y drivers.  If set to non-zero,
@@ -82,6 +88,7 @@ Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
 			pendown-gpio = <&gpio1 8 0>;
 			vcc-supply = <&reg_vcc3>;
 
+			touchscreen-swapped-x-y;
 			ti,x-min = /bits/ 16 <0>;
 			ti,x-max = /bits/ 16 <8000>;
 			ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 1ce3ecb..400e421 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include <linux/spi/ads7846.h>
 #include <linux/regulator/consumer.h>
 #include <linux/module.h>
+#include <linux/input/touchscreen.h>
 #include <asm/irq.h>
 
 /*
@@ -109,8 +110,13 @@ struct ads7846 {
 	u16			vref_delay_usecs;
 	u16			x_plate_ohms;
 	u16			pressure_max;
+	u16			x_min;
+	u16			x_max;
+	u16			y_min;
+	u16			y_max;
+
+	struct touchscreen_properties prop;
 
-	bool			swap_xy;
 	bool			use_internal;
 
 	struct ads7846_packet	*packet;
@@ -825,22 +831,36 @@ static void ads7846_report_state(struct ads7846 *ts)
 	 */
 	if (Rt) {
 		struct input_dev *input = ts->input;
+		int sx, sy;
+
+		dev_dbg(&ts->spi->dev,
+			"Raw point(%4d,%4d), pressure (%4u)\n",
+				x, y, Rt);
+
+		/* scale ADC values to desired output range */
+		sx = (ts->prop.max_x * (x - ts->x_min))
+			/ (ts->x_max - ts->x_min);
+		sy = (ts->prop.max_y * (y - ts->y_min))
+			/ (ts->y_max - ts->y_min);
 
-		if (ts->swap_xy)
-			swap(x, y);
+		dev_dbg(&ts->spi->dev,
+			"Scaled point(%4d,%4d), pressure (%4u)\n",
+				sx, sy, Rt);
 
+		/* report event */
 		if (!ts->pendown) {
 			input_report_key(input, BTN_TOUCH, 1);
 			ts->pendown = true;
 			dev_vdbg(&ts->spi->dev, "DOWN\n");
 		}
 
-		input_report_abs(input, ABS_X, x);
-		input_report_abs(input, ABS_Y, y);
+		touchscreen_report_pos(ts->input, &ts->prop,
+				       (unsigned int) sx, (unsigned int) sy,
+				       false);
 		input_report_abs(input, ABS_PRESSURE, ts->pressure_max - Rt);
 
 		input_sync(input);
-		dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", x, y, Rt);
+		dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", sx, sy, Rt);
 	}
 }
 
@@ -1212,6 +1232,8 @@ static const struct ads7846_platform_data *ads7846_probe_dt(struct device *dev)
 	pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
 
 	pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
+	if (pdata->swap_xy)
+		dev_notice(dev, "please update device tree to use touchscreen-swapped-x-y");
 
 	of_property_read_u16(node, "ti,settle-delay-usec",
 			     &pdata->settle_delay_usecs);
@@ -1315,7 +1337,6 @@ static int ads7846_probe(struct spi_device *spi)
 	ts->pressure_max = pdata->pressure_max ? : ~0;
 
 	ts->vref_mv = pdata->vref_mv;
-	ts->swap_xy = pdata->swap_xy;
 
 	if (pdata->filter != NULL) {
 		if (pdata->filter_init != NULL) {
@@ -1355,18 +1376,35 @@ static int ads7846_probe(struct spi_device *spi)
 	input_dev->dev.parent = &spi->dev;
 
 	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+	input_dev->absbit[0] = BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) |
+				BIT_MASK(ABS_PRESSURE);
 	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+	ts->x_min = pdata->x_min ? : 0;
+	ts->x_max = pdata->x_max ? : MAX_12BIT;
+	ts->y_min = pdata->y_min ? : 0;
+	ts->y_max = pdata->y_max ? : MAX_12BIT;
+
 	input_set_abs_params(input_dev, ABS_X,
-			pdata->x_min ? : 0,
-			pdata->x_max ? : MAX_12BIT,
+			ts->x_min,
+			ts->x_max,
 			0, 0);
 	input_set_abs_params(input_dev, ABS_Y,
-			pdata->y_min ? : 0,
-			pdata->y_max ? : MAX_12BIT,
+			ts->y_min,
+			ts->y_max,
 			0, 0);
 	input_set_abs_params(input_dev, ABS_PRESSURE,
 			pdata->pressure_min, pdata->pressure_max, 0, 0);
 
+	if (spi->dev.of_node) {
+		input_abs_set_min(input_dev, ABS_X, 0);
+		input_abs_set_min(input_dev, ABS_Y, 0);
+
+		touchscreen_parse_properties(ts->input, false, &ts->prop);
+	}
+
+	ts->prop.swap_x_y |= pdata->swap_xy;
+
 	ads7846_setup_spi_msg(ts, pdata);
 
 	ts->reg = regulator_get(&spi->dev, "vcc");
-- 
2.7.3

[PATCH v9 5/8] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory

[H. Nikolaus Schaller]

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (100%)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
similarity index 100%
rename from Documentation/devicetree/bindings/input/ads7846.txt
rename to Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
-- 
2.7.3

[PATCH v9 5/8] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory

[H. Nikolaus Schaller]

Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (100%)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
similarity index 100%
rename from Documentation/devicetree/bindings/input/ads7846.txt
rename to Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
-- 
2.7.3

[PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/input/touchscreen/ads7846.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 400e421..50c85d2 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1532,6 +1532,16 @@ static int ads7846_remove(struct spi_device *spi)
 	return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+	{ "tsc2046", 0 },
+	{ "ads7843", 0 },
+	{ "ads7845", 0 },
+	{ "ads7846", 0 },
+	{ "ads7873", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
 	.driver = {
 		.name	= "ads7846",
@@ -1546,4 +1556,3 @@ module_spi_driver(ads7846_driver);
 
 MODULE_DESCRIPTION("ADS7846 TouchScreen Driver");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("spi:ads7846");
-- 
2.7.3

[PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/input/touchscreen/ads7846.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 400e421..50c85d2 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1532,6 +1532,16 @@ static int ads7846_remove(struct spi_device *spi)
 	return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+	{ "tsc2046", 0 },
+	{ "ads7843", 0 },
+	{ "ads7845", 0 },
+	{ "ads7846", 0 },
+	{ "ads7873", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
 	.driver = {
 		.name	= "ads7846",
@@ -1546,4 +1556,3 @@ module_spi_driver(ads7846_driver);
 
 MODULE_DESCRIPTION("ADS7846 TouchScreen Driver");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("spi:ads7846");
-- 
2.7.3

[PATCH v9 7/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Tested with OpenPandora.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi              |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi          | 17 +++++++++++++----
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  3 ++-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5..b8b3864 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
 		ti,y-max = /bits/ 16 <3600>;
 		ti,x-plate-ohms = /bits/ 16 <80>;
 		ti,pressure-max = /bits/ 16 <255>;
-		ti,swap-xy;
+		touchscreen-swapped-x-y;
 
 		wakeup-source;
 	};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index b0d1551..d12008a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -700,10 +700,19 @@
 		pendown-gpio = <&gpio3 30 GPIO_ACTIVE_HIGH>;
 		vcc-supply = <&vaux4>;
 
-		ti,x-min = /bits/ 16 <0>;
-		ti,x-max = /bits/ 16 <8000>;
-		ti,y-min = /bits/ 16 <0>;
-		ti,y-max = /bits/ 16 <4800>;
+		touchscreen-size-x = <800>;
+		touchscreen-size-y = <480>;
+		touchscreen-max-pressure = <1000>;
+		touchscreen-fuzz-x = <16>;
+		touchscreen-fuzz-y = <16>;
+		touchscreen-fuzz-pressure = <10>;
+		touchscreen-inverted-x;
+		touchscreen-inverted-y;
+
+		ti,x-min = /bits/ 16 <160>;
+		ti,x-max = /bits/ 16 <3900>;
+		ti,y-min = /bits/ 16 <220>;
+		ti,y-max = /bits/ 16 <3750>;
 		ti,x-plate-ohms = /bits/ 16 <40>;
 		ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345b..3627a63 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -66,6 +66,7 @@
 		ti,x-plate-ohms = /bits/ 16 <40>;
 		ti,pressure-max = /bits/ 16 <255>;
 		ti,swap-xy;
-		wakeup-source;
+		touchscreen-swapped-x-y;
+		linux,wakeup;
 	};
 };
-- 
2.7.3

[PATCH v9 7/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Tested with OpenPandora.

Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi              |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi          | 17 +++++++++++++----
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  3 ++-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5..b8b3864 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
 		ti,y-max = /bits/ 16 <3600>;
 		ti,x-plate-ohms = /bits/ 16 <80>;
 		ti,pressure-max = /bits/ 16 <255>;
-		ti,swap-xy;
+		touchscreen-swapped-x-y;
 
 		wakeup-source;
 	};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index b0d1551..d12008a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -700,10 +700,19 @@
 		pendown-gpio = <&gpio3 30 GPIO_ACTIVE_HIGH>;
 		vcc-supply = <&vaux4>;
 
-		ti,x-min = /bits/ 16 <0>;
-		ti,x-max = /bits/ 16 <8000>;
-		ti,y-min = /bits/ 16 <0>;
-		ti,y-max = /bits/ 16 <4800>;
+		touchscreen-size-x = <800>;
+		touchscreen-size-y = <480>;
+		touchscreen-max-pressure = <1000>;
+		touchscreen-fuzz-x = <16>;
+		touchscreen-fuzz-y = <16>;
+		touchscreen-fuzz-pressure = <10>;
+		touchscreen-inverted-x;
+		touchscreen-inverted-y;
+
+		ti,x-min = /bits/ 16 <160>;
+		ti,x-max = /bits/ 16 <3900>;
+		ti,y-min = /bits/ 16 <220>;
+		ti,y-max = /bits/ 16 <3750>;
 		ti,x-plate-ohms = /bits/ 16 <40>;
 		ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345b..3627a63 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -66,6 +66,7 @@
 		ti,x-plate-ohms = /bits/ 16 <40>;
 		ti,pressure-max = /bits/ 16 <255>;
 		ti,swap-xy;
-		wakeup-source;
+		touchscreen-swapped-x-y;
+		linux,wakeup;
 	};
 };
-- 
2.7.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This extension provides an iio interface for these adc channels.

Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.

This patch also splits the tsc2007 driver in several source files:
tsc2007.h -- constants, structs and stubs
tsc2007_core.c -- functional parts of the original driver
tsc2007_iio.c -- the optional iio stuff

Makefile magic allows to conditionally link the iio stuff
if CONFIG_IIO=y or =m in a way that it works with
CONFIG_TOUCHSCREEN_TSC2007=m.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
---
 drivers/input/touchscreen/Kconfig                  |  10 ++
 drivers/input/touchscreen/Makefile                 |   2 +
 drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
 .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
 drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
 5 files changed, 299 insertions(+), 74 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index efca013..1616a8d 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
 	  To compile this driver as a module, choose M here: the
 	  module will be called tsc2007.
 
+config TOUCHSCREEN_TSC2007_IIO
+	bool "IIO interface for external ADC input and temperature"
+	depends on TOUCHSCREEN_TSC2007
+	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
+	help
+	  Saying Y here adds an iio interface to the tsc2007 which
+	  provides values for the AUX input (used for e.g. battery
+	  or ambient light monitoring), temperature and raw input
+	  values.
+
 config TOUCHSCREEN_W90X900
 	tristate "W90P910 touchscreen driver"
 	depends on ARCH_W90X900
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 81b8645..05d1cc8 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
 obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
+tsc2007-y := tsc2007_core.o
+tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
 obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
new file mode 100644
index 0000000..16efb60
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007.h
@@ -0,0 +1,116 @@
+/*
+ * Copyright (c) 2008 MtekVision Co., Ltd.
+ *	Kwangwoo Lee <kwlee@mtekvision.com>
+ *
+ * Using code from:
+ *  - ads7846.c
+ *	Copyright (c) 2005 David Brownell
+ *	Copyright (c) 2006 Nokia Corporation
+ *  - corgi_ts.c
+ *	Copyright (C) 2004-2005 Richard Purdie
+ *  - omap_ts.[hc], ads7846.h, ts_osk.c
+ *	Copyright (C) 2002 MontaVista Software
+ *	Copyright (C) 2004 Texas Instruments
+ *	Copyright (C) 2005 Dirk Behme
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <linux/input/touchscreen.h>
+
+#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
+#define TSC2007_MEASURE_AUX		(0x2 << 4)
+#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
+#define TSC2007_ACTIVATE_XN		(0x8 << 4)
+#define TSC2007_ACTIVATE_YN		(0x9 << 4)
+#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
+#define TSC2007_SETUP			(0xb << 4)
+#define TSC2007_MEASURE_X		(0xc << 4)
+#define TSC2007_MEASURE_Y		(0xd << 4)
+#define TSC2007_MEASURE_Z1		(0xe << 4)
+#define TSC2007_MEASURE_Z2		(0xf << 4)
+
+#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
+#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
+
+#define TSC2007_12BIT			(0x0 << 1)
+#define TSC2007_8BIT			(0x1 << 1)
+
+#define	MAX_12BIT			((1 << 12) - 1)
+
+#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
+
+#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
+#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
+#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
+#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
+#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
+
+struct ts_event {
+	u16	x;
+	u16	y;
+	u16	z1, z2;
+};
+
+struct tsc2007 {
+	struct input_dev	*input;
+	char			phys[32];
+
+	struct i2c_client	*client;
+
+	u16			model;
+	u16			x_plate_ohms;
+
+	struct touchscreen_properties prop;
+
+	bool			report_resistance;
+	u16			min_x;
+	u16			min_y;
+	u16			max_x;
+	u16			max_y;
+	u16			max_rt;
+	unsigned long		poll_period; /* in jiffies */
+	int			fuzzx;
+	int			fuzzy;
+	int			fuzzz;
+
+	unsigned int		gpio;
+	int			irq;
+
+	wait_queue_head_t	wait;
+	bool			stopped;
+	bool			pendown;
+
+	int			(*get_pendown_state)(struct device *);
+	void			(*clear_penirq)(void);
+
+	struct mutex		mlock;
+	struct iio_dev		*iio_dev;	/* optional */
+};
+
+int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
+u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+					struct ts_event *tc);
+bool tsc2007_is_pen_down(struct tsc2007 *ts);
+
+#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
+
+/* defined in tsc2007_iio.c */
+int tsc2007_iio_configure(struct tsc2007 *ts);
+void tsc2007_iio_unconfigure(struct tsc2007 *ts);
+
+#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
+
+static inline int tsc2007_iio_configure(struct tsc2007 *ts)
+{
+	return 0;
+}
+static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
+{
+}
+
+#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
similarity index 86%
rename from drivers/input/touchscreen/tsc2007.c
rename to drivers/input/touchscreen/tsc2007_core.c
index 76b462b..812ded8 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -27,79 +27,11 @@
 #include <linux/i2c.h>
 #include <linux/i2c/tsc2007.h>
 #include <linux/of_device.h>
-#include <linux/of.h>
 #include <linux/of_gpio.h>
-#include <linux/input/touchscreen.h>
-
-#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
-#define TSC2007_MEASURE_AUX		(0x2 << 4)
-#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
-#define TSC2007_ACTIVATE_XN		(0x8 << 4)
-#define TSC2007_ACTIVATE_YN		(0x9 << 4)
-#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
-#define TSC2007_SETUP			(0xb << 4)
-#define TSC2007_MEASURE_X		(0xc << 4)
-#define TSC2007_MEASURE_Y		(0xd << 4)
-#define TSC2007_MEASURE_Z1		(0xe << 4)
-#define TSC2007_MEASURE_Z2		(0xf << 4)
-
-#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
-#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
-#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
-#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
-
-#define TSC2007_12BIT			(0x0 << 1)
-#define TSC2007_8BIT			(0x1 << 1)
-
-#define	MAX_12BIT			((1 << 12) - 1)
-
-#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
-
-#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
-#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
-#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
-#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
-#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
-
-struct ts_event {
-	u16	x;
-	u16	y;
-	u16	z1, z2;
-};
-
-struct tsc2007 {
-	struct input_dev	*input;
-	char			phys[32];
-
-	struct i2c_client	*client;
-
-	u16			model;
-	u16			x_plate_ohms;
-
-	struct touchscreen_properties prop;
-
-	bool			report_resistance;
-	u16			min_x;
-	u16			min_y;
-	u16			max_x;
-	u16			max_y;
-	u16			max_rt;
-	unsigned long		poll_period; /* in jiffies */
-	int			fuzzx;
-	int			fuzzy;
-	int			fuzzz;
-
-	unsigned		gpio;
-	int			irq;
-
-	wait_queue_head_t	wait;
-	bool			stopped;
+#include "tsc2007.h"
 
-	int			(*get_pendown_state)(struct device *);
-	void			(*clear_penirq)(void);
-};
 
-static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
+int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
 {
 	s32 data;
 	u16 val;
@@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
 	tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
 					struct ts_event *tc)
 {
 	u32 rt = 0;
@@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
 	return rt;
 }
 
-static bool tsc2007_is_pen_down(struct tsc2007 *ts)
+bool tsc2007_is_pen_down(struct tsc2007 *ts)
 {
 	/*
 	 * NOTE: We can't rely on the pressure to determine the pen down
@@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
 		/* pen is down, continue with the measurement */
+
+		mutex_lock(&ts->mlock);
 		tsc2007_read_values(ts, &tc);
+		mutex_unlock(&ts->mlock);
 
 		rt = tsc2007_calculate_resistance(ts, &tc);
 
@@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
 static int tsc2007_probe(struct i2c_client *client,
 			 const struct i2c_device_id *id)
 {
-	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
+	const struct tsc2007_platform_data *pdata =
+		dev_get_platdata(&client->dev);
 	struct tsc2007 *ts;
 	struct input_dev *input_dev;
 	int err;
@@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
 	ts->client = client;
 	ts->irq = client->irq;
 	ts->input = input_dev;
+
 	init_waitqueue_head(&ts->wait);
+	mutex_init(&ts->mlock);
 
 	snprintf(ts->phys, sizeof(ts->phys),
 		 "%s/input0", dev_name(&client->dev));
@@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
 	if (err < 0) {
 		dev_err(&client->dev,
 			"Failed to setup chip: %d\n", err);
-		return err;	/* usually, chip does not respond */
+		return err;	/* chip does not respond */
 	}
 
 	err = input_register_device(input_dev);
@@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
 		return err;
 	}
 
+	return tsc2007_iio_configure(ts);
+}
+
+static int tsc2007_remove(struct i2c_client *client)
+{
+	struct tsc2007 *ts = i2c_get_clientdata(client);
+
+	tsc2007_iio_unconfigure(ts);
 	return 0;
 }
 
@@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
 	},
 	.id_table	= tsc2007_idtable,
 	.probe		= tsc2007_probe,
+	.remove		= tsc2007_remove,
 };
 
 module_i2c_driver(tsc2007_driver);
diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
new file mode 100644
index 0000000..ed79944
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007_iio.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
+ *	Nikolaus Schaller <hns@goldelico.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <linux/i2c.h>
+#include <linux/iio/iio.h>
+#include "tsc2007.h"
+
+struct tsc2007_iio {
+	struct tsc2007 *ts;
+};
+
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+	.datasheet_name = _name, \
+	.type = _type, \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
+			BIT(_chan_info), \
+	.indexed = 1, \
+	.channel = _chan, \
+}
+
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+	struct tsc2007_iio *iio = iio_priv(indio_dev);
+	struct tsc2007 *tsc = iio->ts;
+	int adc_chan = chan->channel;
+	int ret = 0;
+
+	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+		return -EINVAL;
+
+	if (mask != IIO_CHAN_INFO_RAW)
+		return -EINVAL;
+
+	mutex_lock(&tsc->mlock);
+
+	switch (chan->channel) {
+	case 0:
+		*val = tsc2007_xfer(tsc, READ_X);
+		break;
+	case 1:
+		*val = tsc2007_xfer(tsc, READ_Y);
+		break;
+	case 2:
+		*val = tsc2007_xfer(tsc, READ_Z1);
+		break;
+	case 3:
+		*val = tsc2007_xfer(tsc, READ_Z2);
+		break;
+	case 4:
+		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
+		break;
+	case 5: {
+		struct ts_event tc;
+
+		tc.x = tsc2007_xfer(tsc, READ_X);
+		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
+		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
+		*val = tsc2007_calculate_resistance(tsc, &tc);
+		break;
+	}
+	case 6:
+		*val = tsc2007_is_pen_down(tsc);
+		break;
+	case 7:
+		*val = tsc2007_xfer(tsc,
+				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
+		break;
+	case 8:
+		*val = tsc2007_xfer(tsc,
+				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
+		break;
+	}
+
+	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
+	tsc2007_xfer(tsc, PWRDOWN);
+
+	mutex_unlock(&tsc->mlock);
+
+	ret = IIO_VAL_INT;
+
+	return ret;
+}
+
+static const struct iio_info tsc2007_iio_info = {
+	.read_raw = tsc2007_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+int tsc2007_iio_configure(struct tsc2007 *ts)
+{
+	int err;
+	struct iio_dev *indio_dev;
+	struct tsc2007_iio *iio;
+
+	indio_dev = devm_iio_device_alloc(&ts->client->dev,
+		sizeof(struct tsc2007_iio));
+	if (!indio_dev) {
+		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
+		return -ENOMEM;
+	}
+
+	iio = iio_priv(indio_dev);
+	iio->ts = ts;
+	ts->iio_dev = (void *) indio_dev;
+
+	indio_dev->name = "tsc2007";
+	indio_dev->dev.parent = &ts->client->dev;
+	indio_dev->info = &tsc2007_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = tsc2007_iio_channel;
+	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
+
+	err = iio_device_register(indio_dev);
+	if (err < 0) {
+		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
+			err);
+		return err;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(tsc2007_iio_configure);
+
+void tsc2007_iio_unconfigure(struct tsc2007 *ts)
+{
+	struct iio_dev *indio_dev = ts->iio_dev;
+
+	iio_device_unregister(indio_dev);
+}
+EXPORT_SYMBOL(tsc2007_iio_unconfigure);
-- 
2.7.3

[PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This extension provides an iio interface for these adc channels.

Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.

This patch also splits the tsc2007 driver in several source files:
tsc2007.h -- constants, structs and stubs
tsc2007_core.c -- functional parts of the original driver
tsc2007_iio.c -- the optional iio stuff

Makefile magic allows to conditionally link the iio stuff
if CONFIG_IIO=y or =m in a way that it works with
CONFIG_TOUCHSCREEN_TSC2007=m.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
---
 drivers/input/touchscreen/Kconfig                  |  10 ++
 drivers/input/touchscreen/Makefile                 |   2 +
 drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
 .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
 drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
 5 files changed, 299 insertions(+), 74 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index efca013..1616a8d 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
 	  To compile this driver as a module, choose M here: the
 	  module will be called tsc2007.
 
+config TOUCHSCREEN_TSC2007_IIO
+	bool "IIO interface for external ADC input and temperature"
+	depends on TOUCHSCREEN_TSC2007
+	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
+	help
+	  Saying Y here adds an iio interface to the tsc2007 which
+	  provides values for the AUX input (used for e.g. battery
+	  or ambient light monitoring), temperature and raw input
+	  values.
+
 config TOUCHSCREEN_W90X900
 	tristate "W90P910 touchscreen driver"
 	depends on ARCH_W90X900
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 81b8645..05d1cc8 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
 obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
+tsc2007-y := tsc2007_core.o
+tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
 obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
new file mode 100644
index 0000000..16efb60
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007.h
@@ -0,0 +1,116 @@
+/*
+ * Copyright (c) 2008 MtekVision Co., Ltd.
+ *	Kwangwoo Lee <kwlee@mtekvision.com>
+ *
+ * Using code from:
+ *  - ads7846.c
+ *	Copyright (c) 2005 David Brownell
+ *	Copyright (c) 2006 Nokia Corporation
+ *  - corgi_ts.c
+ *	Copyright (C) 2004-2005 Richard Purdie
+ *  - omap_ts.[hc], ads7846.h, ts_osk.c
+ *	Copyright (C) 2002 MontaVista Software
+ *	Copyright (C) 2004 Texas Instruments
+ *	Copyright (C) 2005 Dirk Behme
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <linux/input/touchscreen.h>
+
+#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
+#define TSC2007_MEASURE_AUX		(0x2 << 4)
+#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
+#define TSC2007_ACTIVATE_XN		(0x8 << 4)
+#define TSC2007_ACTIVATE_YN		(0x9 << 4)
+#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
+#define TSC2007_SETUP			(0xb << 4)
+#define TSC2007_MEASURE_X		(0xc << 4)
+#define TSC2007_MEASURE_Y		(0xd << 4)
+#define TSC2007_MEASURE_Z1		(0xe << 4)
+#define TSC2007_MEASURE_Z2		(0xf << 4)
+
+#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
+#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
+
+#define TSC2007_12BIT			(0x0 << 1)
+#define TSC2007_8BIT			(0x1 << 1)
+
+#define	MAX_12BIT			((1 << 12) - 1)
+
+#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
+
+#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
+#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
+#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
+#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
+#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
+
+struct ts_event {
+	u16	x;
+	u16	y;
+	u16	z1, z2;
+};
+
+struct tsc2007 {
+	struct input_dev	*input;
+	char			phys[32];
+
+	struct i2c_client	*client;
+
+	u16			model;
+	u16			x_plate_ohms;
+
+	struct touchscreen_properties prop;
+
+	bool			report_resistance;
+	u16			min_x;
+	u16			min_y;
+	u16			max_x;
+	u16			max_y;
+	u16			max_rt;
+	unsigned long		poll_period; /* in jiffies */
+	int			fuzzx;
+	int			fuzzy;
+	int			fuzzz;
+
+	unsigned int		gpio;
+	int			irq;
+
+	wait_queue_head_t	wait;
+	bool			stopped;
+	bool			pendown;
+
+	int			(*get_pendown_state)(struct device *);
+	void			(*clear_penirq)(void);
+
+	struct mutex		mlock;
+	struct iio_dev		*iio_dev;	/* optional */
+};
+
+int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
+u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+					struct ts_event *tc);
+bool tsc2007_is_pen_down(struct tsc2007 *ts);
+
+#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
+
+/* defined in tsc2007_iio.c */
+int tsc2007_iio_configure(struct tsc2007 *ts);
+void tsc2007_iio_unconfigure(struct tsc2007 *ts);
+
+#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
+
+static inline int tsc2007_iio_configure(struct tsc2007 *ts)
+{
+	return 0;
+}
+static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
+{
+}
+
+#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
similarity index 86%
rename from drivers/input/touchscreen/tsc2007.c
rename to drivers/input/touchscreen/tsc2007_core.c
index 76b462b..812ded8 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -27,79 +27,11 @@
 #include <linux/i2c.h>
 #include <linux/i2c/tsc2007.h>
 #include <linux/of_device.h>
-#include <linux/of.h>
 #include <linux/of_gpio.h>
-#include <linux/input/touchscreen.h>
-
-#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
-#define TSC2007_MEASURE_AUX		(0x2 << 4)
-#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
-#define TSC2007_ACTIVATE_XN		(0x8 << 4)
-#define TSC2007_ACTIVATE_YN		(0x9 << 4)
-#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
-#define TSC2007_SETUP			(0xb << 4)
-#define TSC2007_MEASURE_X		(0xc << 4)
-#define TSC2007_MEASURE_Y		(0xd << 4)
-#define TSC2007_MEASURE_Z1		(0xe << 4)
-#define TSC2007_MEASURE_Z2		(0xf << 4)
-
-#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
-#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
-#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
-#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
-
-#define TSC2007_12BIT			(0x0 << 1)
-#define TSC2007_8BIT			(0x1 << 1)
-
-#define	MAX_12BIT			((1 << 12) - 1)
-
-#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
-
-#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
-#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
-#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
-#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
-#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
-
-struct ts_event {
-	u16	x;
-	u16	y;
-	u16	z1, z2;
-};
-
-struct tsc2007 {
-	struct input_dev	*input;
-	char			phys[32];
-
-	struct i2c_client	*client;
-
-	u16			model;
-	u16			x_plate_ohms;
-
-	struct touchscreen_properties prop;
-
-	bool			report_resistance;
-	u16			min_x;
-	u16			min_y;
-	u16			max_x;
-	u16			max_y;
-	u16			max_rt;
-	unsigned long		poll_period; /* in jiffies */
-	int			fuzzx;
-	int			fuzzy;
-	int			fuzzz;
-
-	unsigned		gpio;
-	int			irq;
-
-	wait_queue_head_t	wait;
-	bool			stopped;
+#include "tsc2007.h"
 
-	int			(*get_pendown_state)(struct device *);
-	void			(*clear_penirq)(void);
-};
 
-static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
+int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
 {
 	s32 data;
 	u16 val;
@@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
 	tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
 					struct ts_event *tc)
 {
 	u32 rt = 0;
@@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
 	return rt;
 }
 
-static bool tsc2007_is_pen_down(struct tsc2007 *ts)
+bool tsc2007_is_pen_down(struct tsc2007 *ts)
 {
 	/*
 	 * NOTE: We can't rely on the pressure to determine the pen down
@@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
 		/* pen is down, continue with the measurement */
+
+		mutex_lock(&ts->mlock);
 		tsc2007_read_values(ts, &tc);
+		mutex_unlock(&ts->mlock);
 
 		rt = tsc2007_calculate_resistance(ts, &tc);
 
@@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
 static int tsc2007_probe(struct i2c_client *client,
 			 const struct i2c_device_id *id)
 {
-	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
+	const struct tsc2007_platform_data *pdata =
+		dev_get_platdata(&client->dev);
 	struct tsc2007 *ts;
 	struct input_dev *input_dev;
 	int err;
@@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
 	ts->client = client;
 	ts->irq = client->irq;
 	ts->input = input_dev;
+
 	init_waitqueue_head(&ts->wait);
+	mutex_init(&ts->mlock);
 
 	snprintf(ts->phys, sizeof(ts->phys),
 		 "%s/input0", dev_name(&client->dev));
@@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
 	if (err < 0) {
 		dev_err(&client->dev,
 			"Failed to setup chip: %d\n", err);
-		return err;	/* usually, chip does not respond */
+		return err;	/* chip does not respond */
 	}
 
 	err = input_register_device(input_dev);
@@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
 		return err;
 	}
 
+	return tsc2007_iio_configure(ts);
+}
+
+static int tsc2007_remove(struct i2c_client *client)
+{
+	struct tsc2007 *ts = i2c_get_clientdata(client);
+
+	tsc2007_iio_unconfigure(ts);
 	return 0;
 }
 
@@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
 	},
 	.id_table	= tsc2007_idtable,
 	.probe		= tsc2007_probe,
+	.remove		= tsc2007_remove,
 };
 
 module_i2c_driver(tsc2007_driver);
diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
new file mode 100644
index 0000000..ed79944
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007_iio.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
+ *	Nikolaus Schaller <hns@goldelico.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <linux/i2c.h>
+#include <linux/iio/iio.h>
+#include "tsc2007.h"
+
+struct tsc2007_iio {
+	struct tsc2007 *ts;
+};
+
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+	.datasheet_name = _name, \
+	.type = _type, \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
+			BIT(_chan_info), \
+	.indexed = 1, \
+	.channel = _chan, \
+}
+
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+	struct tsc2007_iio *iio = iio_priv(indio_dev);
+	struct tsc2007 *tsc = iio->ts;
+	int adc_chan = chan->channel;
+	int ret = 0;
+
+	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+		return -EINVAL;
+
+	if (mask != IIO_CHAN_INFO_RAW)
+		return -EINVAL;
+
+	mutex_lock(&tsc->mlock);
+
+	switch (chan->channel) {
+	case 0:
+		*val = tsc2007_xfer(tsc, READ_X);
+		break;
+	case 1:
+		*val = tsc2007_xfer(tsc, READ_Y);
+		break;
+	case 2:
+		*val = tsc2007_xfer(tsc, READ_Z1);
+		break;
+	case 3:
+		*val = tsc2007_xfer(tsc, READ_Z2);
+		break;
+	case 4:
+		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
+		break;
+	case 5: {
+		struct ts_event tc;
+
+		tc.x = tsc2007_xfer(tsc, READ_X);
+		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
+		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
+		*val = tsc2007_calculate_resistance(tsc, &tc);
+		break;
+	}
+	case 6:
+		*val = tsc2007_is_pen_down(tsc);
+		break;
+	case 7:
+		*val = tsc2007_xfer(tsc,
+				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
+		break;
+	case 8:
+		*val = tsc2007_xfer(tsc,
+				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
+		break;
+	}
+
+	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
+	tsc2007_xfer(tsc, PWRDOWN);
+
+	mutex_unlock(&tsc->mlock);
+
+	ret = IIO_VAL_INT;
+
+	return ret;
+}
+
+static const struct iio_info tsc2007_iio_info = {
+	.read_raw = tsc2007_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+int tsc2007_iio_configure(struct tsc2007 *ts)
+{
+	int err;
+	struct iio_dev *indio_dev;
+	struct tsc2007_iio *iio;
+
+	indio_dev = devm_iio_device_alloc(&ts->client->dev,
+		sizeof(struct tsc2007_iio));
+	if (!indio_dev) {
+		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
+		return -ENOMEM;
+	}
+
+	iio = iio_priv(indio_dev);
+	iio->ts = ts;
+	ts->iio_dev = (void *) indio_dev;
+
+	indio_dev->name = "tsc2007";
+	indio_dev->dev.parent = &ts->client->dev;
+	indio_dev->info = &tsc2007_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = tsc2007_iio_channel;
+	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
+
+	err = iio_device_register(indio_dev);
+	if (err < 0) {
+		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
+			err);
+		return err;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(tsc2007_iio_configure);
+
+void tsc2007_iio_unconfigure(struct tsc2007 *ts)
+{
+	struct iio_dev *indio_dev = ts->iio_dev;
+
+	iio_device_unregister(indio_dev);
+}
+EXPORT_SYMBOL(tsc2007_iio_unconfigure);
-- 
2.7.3

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[Jonathan Cameron]

On 28/12/16 14:53, H. Nikolaus Schaller wrote:
> The tsc2007 chip not only has a resistive touch screen controller but
> also an external AUX adc imput which can be used for an ambient
> light sensor, battery voltage monitoring or any general purpose.
> 
> Additionally it can measure the chip temperature.
> 
> This extension provides an iio interface for these adc channels.
> 
> Since it is not wasting much resources and is very straightforward,
> we simply provide all other adc channels as optional iio interfaces
> as weel. This can be used for debugging or special applications.
> 
> This patch also splits the tsc2007 driver in several source files:
> tsc2007.h -- constants, structs and stubs
> tsc2007_core.c -- functional parts of the original driver
> tsc2007_iio.c -- the optional iio stuff
> 
> Makefile magic allows to conditionally link the iio stuff
> if CONFIG_IIO=y or =m in a way that it works with
> CONFIG_TOUCHSCREEN_TSC2007=m.
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Just for the record, I'm happy with the few changes from earlier versions.

Jonathan
> ---
>  drivers/input/touchscreen/Kconfig                  |  10 ++
>  drivers/input/touchscreen/Makefile                 |   2 +
>  drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
>  .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
>  drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
>  5 files changed, 299 insertions(+), 74 deletions(-)
>  create mode 100644 drivers/input/touchscreen/tsc2007.h
>  rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
>  create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index efca013..1616a8d 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called tsc2007.
>  
> +config TOUCHSCREEN_TSC2007_IIO
> +	bool "IIO interface for external ADC input and temperature"
> +	depends on TOUCHSCREEN_TSC2007
> +	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
> +	help
> +	  Saying Y here adds an iio interface to the tsc2007 which
> +	  provides values for the AUX input (used for e.g. battery
> +	  or ambient light monitoring), temperature and raw input
> +	  values.
> +
>  config TOUCHSCREEN_W90X900
>  	tristate "W90P910 touchscreen driver"
>  	depends on ARCH_W90X900
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 81b8645..05d1cc8 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
> +tsc2007-y := tsc2007_core.o
> +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
>  obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
> diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
> new file mode 100644
> index 0000000..16efb60
> --- /dev/null
> +++ b/drivers/input/touchscreen/tsc2007.h
> @@ -0,0 +1,116 @@
> +/*
> + * Copyright (c) 2008 MtekVision Co., Ltd.
> + *	Kwangwoo Lee <kwlee@mtekvision.com>
> + *
> + * Using code from:
> + *  - ads7846.c
> + *	Copyright (c) 2005 David Brownell
> + *	Copyright (c) 2006 Nokia Corporation
> + *  - corgi_ts.c
> + *	Copyright (C) 2004-2005 Richard Purdie
> + *  - omap_ts.[hc], ads7846.h, ts_osk.c
> + *	Copyright (C) 2002 MontaVista Software
> + *	Copyright (C) 2004 Texas Instruments
> + *	Copyright (C) 2005 Dirk Behme
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/input/touchscreen.h>
> +
> +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> +#define TSC2007_MEASURE_AUX		(0x2 << 4)
> +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> +#define TSC2007_SETUP			(0xb << 4)
> +#define TSC2007_MEASURE_X		(0xc << 4)
> +#define TSC2007_MEASURE_Y		(0xd << 4)
> +#define TSC2007_MEASURE_Z1		(0xe << 4)
> +#define TSC2007_MEASURE_Z2		(0xf << 4)
> +
> +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> +
> +#define TSC2007_12BIT			(0x0 << 1)
> +#define TSC2007_8BIT			(0x1 << 1)
> +
> +#define	MAX_12BIT			((1 << 12) - 1)
> +
> +#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> +
> +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> +#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> +
> +struct ts_event {
> +	u16	x;
> +	u16	y;
> +	u16	z1, z2;
> +};
> +
> +struct tsc2007 {
> +	struct input_dev	*input;
> +	char			phys[32];
> +
> +	struct i2c_client	*client;
> +
> +	u16			model;
> +	u16			x_plate_ohms;
> +
> +	struct touchscreen_properties prop;
> +
> +	bool			report_resistance;
> +	u16			min_x;
> +	u16			min_y;
> +	u16			max_x;
> +	u16			max_y;
> +	u16			max_rt;
> +	unsigned long		poll_period; /* in jiffies */
> +	int			fuzzx;
> +	int			fuzzy;
> +	int			fuzzz;
> +
> +	unsigned int		gpio;
> +	int			irq;
> +
> +	wait_queue_head_t	wait;
> +	bool			stopped;
> +	bool			pendown;
> +
> +	int			(*get_pendown_state)(struct device *);
> +	void			(*clear_penirq)(void);
> +
> +	struct mutex		mlock;
> +	struct iio_dev		*iio_dev;	/* optional */
> +};
> +
> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> +					struct ts_event *tc);
> +bool tsc2007_is_pen_down(struct tsc2007 *ts);
> +
> +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
> +
> +/* defined in tsc2007_iio.c */
> +int tsc2007_iio_configure(struct tsc2007 *ts);
> +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
> +
> +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> +
> +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
> +{
> +	return 0;
> +}
> +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> +{
> +}
> +
> +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
> similarity index 86%
> rename from drivers/input/touchscreen/tsc2007.c
> rename to drivers/input/touchscreen/tsc2007_core.c
> index 76b462b..812ded8 100644
> --- a/drivers/input/touchscreen/tsc2007.c
> +++ b/drivers/input/touchscreen/tsc2007_core.c
> @@ -27,79 +27,11 @@
>  #include <linux/i2c.h>
>  #include <linux/i2c/tsc2007.h>
>  #include <linux/of_device.h>
> -#include <linux/of.h>
>  #include <linux/of_gpio.h>
> -#include <linux/input/touchscreen.h>
> -
> -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> -#define TSC2007_MEASURE_AUX		(0x2 << 4)
> -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> -#define TSC2007_SETUP			(0xb << 4)
> -#define TSC2007_MEASURE_X		(0xc << 4)
> -#define TSC2007_MEASURE_Y		(0xd << 4)
> -#define TSC2007_MEASURE_Z1		(0xe << 4)
> -#define TSC2007_MEASURE_Z2		(0xf << 4)
> -
> -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> -
> -#define TSC2007_12BIT			(0x0 << 1)
> -#define TSC2007_8BIT			(0x1 << 1)
> -
> -#define	MAX_12BIT			((1 << 12) - 1)
> -
> -#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> -
> -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> -#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> -
> -struct ts_event {
> -	u16	x;
> -	u16	y;
> -	u16	z1, z2;
> -};
> -
> -struct tsc2007 {
> -	struct input_dev	*input;
> -	char			phys[32];
> -
> -	struct i2c_client	*client;
> -
> -	u16			model;
> -	u16			x_plate_ohms;
> -
> -	struct touchscreen_properties prop;
> -
> -	bool			report_resistance;
> -	u16			min_x;
> -	u16			min_y;
> -	u16			max_x;
> -	u16			max_y;
> -	u16			max_rt;
> -	unsigned long		poll_period; /* in jiffies */
> -	int			fuzzx;
> -	int			fuzzy;
> -	int			fuzzz;
> -
> -	unsigned		gpio;
> -	int			irq;
> -
> -	wait_queue_head_t	wait;
> -	bool			stopped;
> +#include "tsc2007.h"
>  
> -	int			(*get_pendown_state)(struct device *);
> -	void			(*clear_penirq)(void);
> -};
>  
> -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>  {
>  	s32 data;
>  	u16 val;
> @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
>  	tsc2007_xfer(tsc, PWRDOWN);
>  }
>  
> -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>  					struct ts_event *tc)
>  {
>  	u32 rt = 0;
> @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>  	return rt;
>  }
>  
> -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
> +bool tsc2007_is_pen_down(struct tsc2007 *ts)
>  {
>  	/*
>  	 * NOTE: We can't rely on the pressure to determine the pen down
> @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
>  	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
>  
>  		/* pen is down, continue with the measurement */
> +
> +		mutex_lock(&ts->mlock);
>  		tsc2007_read_values(ts, &tc);
> +		mutex_unlock(&ts->mlock);
>  
>  		rt = tsc2007_calculate_resistance(ts, &tc);
>  
> @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
>  static int tsc2007_probe(struct i2c_client *client,
>  			 const struct i2c_device_id *id)
>  {
> -	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
> +	const struct tsc2007_platform_data *pdata =
> +		dev_get_platdata(&client->dev);
>  	struct tsc2007 *ts;
>  	struct input_dev *input_dev;
>  	int err;
> @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
>  	ts->client = client;
>  	ts->irq = client->irq;
>  	ts->input = input_dev;
> +
>  	init_waitqueue_head(&ts->wait);
> +	mutex_init(&ts->mlock);
>  
>  	snprintf(ts->phys, sizeof(ts->phys),
>  		 "%s/input0", dev_name(&client->dev));
> @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
>  	if (err < 0) {
>  		dev_err(&client->dev,
>  			"Failed to setup chip: %d\n", err);
> -		return err;	/* usually, chip does not respond */
> +		return err;	/* chip does not respond */
>  	}
>  
>  	err = input_register_device(input_dev);
> @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
>  		return err;
>  	}
>  
> +	return tsc2007_iio_configure(ts);
> +}
> +
> +static int tsc2007_remove(struct i2c_client *client)
> +{
> +	struct tsc2007 *ts = i2c_get_clientdata(client);
> +
> +	tsc2007_iio_unconfigure(ts);
>  	return 0;
>  }
>  
> @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
>  	},
>  	.id_table	= tsc2007_idtable,
>  	.probe		= tsc2007_probe,
> +	.remove		= tsc2007_remove,
>  };
>  
>  module_i2c_driver(tsc2007_driver);
> diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
> new file mode 100644
> index 0000000..ed79944
> --- /dev/null
> +++ b/drivers/input/touchscreen/tsc2007_iio.c
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
> + *	Nikolaus Schaller <hns@goldelico.com>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include "tsc2007.h"
> +
> +struct tsc2007_iio {
> +	struct tsc2007 *ts;
> +};
> +
> +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
> +{ \
> +	.datasheet_name = _name, \
> +	.type = _type, \
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
> +			BIT(_chan_info), \
> +	.indexed = 1, \
> +	.channel = _chan, \
> +}
> +
> +static const struct iio_chan_spec tsc2007_iio_channel[] = {
> +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
> +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
> +};
> +
> +static int tsc2007_read_raw(struct iio_dev *indio_dev,
> +	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
> +{
> +	struct tsc2007_iio *iio = iio_priv(indio_dev);
> +	struct tsc2007 *tsc = iio->ts;
> +	int adc_chan = chan->channel;
> +	int ret = 0;
> +
> +	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
> +		return -EINVAL;
> +
> +	if (mask != IIO_CHAN_INFO_RAW)
> +		return -EINVAL;
> +
> +	mutex_lock(&tsc->mlock);
> +
> +	switch (chan->channel) {
> +	case 0:
> +		*val = tsc2007_xfer(tsc, READ_X);
> +		break;
> +	case 1:
> +		*val = tsc2007_xfer(tsc, READ_Y);
> +		break;
> +	case 2:
> +		*val = tsc2007_xfer(tsc, READ_Z1);
> +		break;
> +	case 3:
> +		*val = tsc2007_xfer(tsc, READ_Z2);
> +		break;
> +	case 4:
> +		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
> +		break;
> +	case 5: {
> +		struct ts_event tc;
> +
> +		tc.x = tsc2007_xfer(tsc, READ_X);
> +		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
> +		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
> +		*val = tsc2007_calculate_resistance(tsc, &tc);
> +		break;
> +	}
> +	case 6:
> +		*val = tsc2007_is_pen_down(tsc);
> +		break;
> +	case 7:
> +		*val = tsc2007_xfer(tsc,
> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
> +		break;
> +	case 8:
> +		*val = tsc2007_xfer(tsc,
> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
> +		break;
> +	}
> +
> +	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
> +	tsc2007_xfer(tsc, PWRDOWN);
> +
> +	mutex_unlock(&tsc->mlock);
> +
> +	ret = IIO_VAL_INT;
> +
> +	return ret;
> +}
> +
> +static const struct iio_info tsc2007_iio_info = {
> +	.read_raw = tsc2007_read_raw,
> +	.driver_module = THIS_MODULE,
> +};
> +
> +int tsc2007_iio_configure(struct tsc2007 *ts)
> +{
> +	int err;
> +	struct iio_dev *indio_dev;
> +	struct tsc2007_iio *iio;
> +
> +	indio_dev = devm_iio_device_alloc(&ts->client->dev,
> +		sizeof(struct tsc2007_iio));
> +	if (!indio_dev) {
> +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
> +		return -ENOMEM;
> +	}
> +
> +	iio = iio_priv(indio_dev);
> +	iio->ts = ts;
> +	ts->iio_dev = (void *) indio_dev;
> +
> +	indio_dev->name = "tsc2007";
> +	indio_dev->dev.parent = &ts->client->dev;
> +	indio_dev->info = &tsc2007_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = tsc2007_iio_channel;
> +	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
> +
> +	err = iio_device_register(indio_dev);
> +	if (err < 0) {
> +		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
> +			err);
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(tsc2007_iio_configure);
> +
> +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> +{
> +	struct iio_dev *indio_dev = ts->iio_dev;
> +
> +	iio_device_unregister(indio_dev);
> +}
> +EXPORT_SYMBOL(tsc2007_iio_unconfigure);
> 

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[Jonathan Cameron]

On 28/12/16 14:53, H. Nikolaus Schaller wrote:
> The tsc2007 chip not only has a resistive touch screen controller but
> also an external AUX adc imput which can be used for an ambient
> light sensor, battery voltage monitoring or any general purpose.
> 
> Additionally it can measure the chip temperature.
> 
> This extension provides an iio interface for these adc channels.
> 
> Since it is not wasting much resources and is very straightforward,
> we simply provide all other adc channels as optional iio interfaces
> as weel. This can be used for debugging or special applications.
> 
> This patch also splits the tsc2007 driver in several source files:
> tsc2007.h -- constants, structs and stubs
> tsc2007_core.c -- functional parts of the original driver
> tsc2007_iio.c -- the optional iio stuff
> 
> Makefile magic allows to conditionally link the iio stuff
> if CONFIG_IIO=y or =m in a way that it works with
> CONFIG_TOUCHSCREEN_TSC2007=m.
> 
> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Just for the record, I'm happy with the few changes from earlier versions.

Jonathan
> ---
>  drivers/input/touchscreen/Kconfig                  |  10 ++
>  drivers/input/touchscreen/Makefile                 |   2 +
>  drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
>  .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
>  drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
>  5 files changed, 299 insertions(+), 74 deletions(-)
>  create mode 100644 drivers/input/touchscreen/tsc2007.h
>  rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
>  create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index efca013..1616a8d 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called tsc2007.
>  
> +config TOUCHSCREEN_TSC2007_IIO
> +	bool "IIO interface for external ADC input and temperature"
> +	depends on TOUCHSCREEN_TSC2007
> +	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
> +	help
> +	  Saying Y here adds an iio interface to the tsc2007 which
> +	  provides values for the AUX input (used for e.g. battery
> +	  or ambient light monitoring), temperature and raw input
> +	  values.
> +
>  config TOUCHSCREEN_W90X900
>  	tristate "W90P910 touchscreen driver"
>  	depends on ARCH_W90X900
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 81b8645..05d1cc8 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
> +tsc2007-y := tsc2007_core.o
> +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
>  obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
>  obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
> diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
> new file mode 100644
> index 0000000..16efb60
> --- /dev/null
> +++ b/drivers/input/touchscreen/tsc2007.h
> @@ -0,0 +1,116 @@
> +/*
> + * Copyright (c) 2008 MtekVision Co., Ltd.
> + *	Kwangwoo Lee <kwlee-ec7hoAtq5SbSUeElwK9/Pw@public.gmane.org>
> + *
> + * Using code from:
> + *  - ads7846.c
> + *	Copyright (c) 2005 David Brownell
> + *	Copyright (c) 2006 Nokia Corporation
> + *  - corgi_ts.c
> + *	Copyright (C) 2004-2005 Richard Purdie
> + *  - omap_ts.[hc], ads7846.h, ts_osk.c
> + *	Copyright (C) 2002 MontaVista Software
> + *	Copyright (C) 2004 Texas Instruments
> + *	Copyright (C) 2005 Dirk Behme
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/input/touchscreen.h>
> +
> +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> +#define TSC2007_MEASURE_AUX		(0x2 << 4)
> +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> +#define TSC2007_SETUP			(0xb << 4)
> +#define TSC2007_MEASURE_X		(0xc << 4)
> +#define TSC2007_MEASURE_Y		(0xd << 4)
> +#define TSC2007_MEASURE_Z1		(0xe << 4)
> +#define TSC2007_MEASURE_Z2		(0xf << 4)
> +
> +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> +
> +#define TSC2007_12BIT			(0x0 << 1)
> +#define TSC2007_8BIT			(0x1 << 1)
> +
> +#define	MAX_12BIT			((1 << 12) - 1)
> +
> +#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> +
> +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> +#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> +
> +struct ts_event {
> +	u16	x;
> +	u16	y;
> +	u16	z1, z2;
> +};
> +
> +struct tsc2007 {
> +	struct input_dev	*input;
> +	char			phys[32];
> +
> +	struct i2c_client	*client;
> +
> +	u16			model;
> +	u16			x_plate_ohms;
> +
> +	struct touchscreen_properties prop;
> +
> +	bool			report_resistance;
> +	u16			min_x;
> +	u16			min_y;
> +	u16			max_x;
> +	u16			max_y;
> +	u16			max_rt;
> +	unsigned long		poll_period; /* in jiffies */
> +	int			fuzzx;
> +	int			fuzzy;
> +	int			fuzzz;
> +
> +	unsigned int		gpio;
> +	int			irq;
> +
> +	wait_queue_head_t	wait;
> +	bool			stopped;
> +	bool			pendown;
> +
> +	int			(*get_pendown_state)(struct device *);
> +	void			(*clear_penirq)(void);
> +
> +	struct mutex		mlock;
> +	struct iio_dev		*iio_dev;	/* optional */
> +};
> +
> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> +					struct ts_event *tc);
> +bool tsc2007_is_pen_down(struct tsc2007 *ts);
> +
> +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
> +
> +/* defined in tsc2007_iio.c */
> +int tsc2007_iio_configure(struct tsc2007 *ts);
> +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
> +
> +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> +
> +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
> +{
> +	return 0;
> +}
> +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> +{
> +}
> +
> +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
> similarity index 86%
> rename from drivers/input/touchscreen/tsc2007.c
> rename to drivers/input/touchscreen/tsc2007_core.c
> index 76b462b..812ded8 100644
> --- a/drivers/input/touchscreen/tsc2007.c
> +++ b/drivers/input/touchscreen/tsc2007_core.c
> @@ -27,79 +27,11 @@
>  #include <linux/i2c.h>
>  #include <linux/i2c/tsc2007.h>
>  #include <linux/of_device.h>
> -#include <linux/of.h>
>  #include <linux/of_gpio.h>
> -#include <linux/input/touchscreen.h>
> -
> -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> -#define TSC2007_MEASURE_AUX		(0x2 << 4)
> -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> -#define TSC2007_SETUP			(0xb << 4)
> -#define TSC2007_MEASURE_X		(0xc << 4)
> -#define TSC2007_MEASURE_Y		(0xd << 4)
> -#define TSC2007_MEASURE_Z1		(0xe << 4)
> -#define TSC2007_MEASURE_Z2		(0xf << 4)
> -
> -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> -
> -#define TSC2007_12BIT			(0x0 << 1)
> -#define TSC2007_8BIT			(0x1 << 1)
> -
> -#define	MAX_12BIT			((1 << 12) - 1)
> -
> -#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> -
> -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> -#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> -
> -struct ts_event {
> -	u16	x;
> -	u16	y;
> -	u16	z1, z2;
> -};
> -
> -struct tsc2007 {
> -	struct input_dev	*input;
> -	char			phys[32];
> -
> -	struct i2c_client	*client;
> -
> -	u16			model;
> -	u16			x_plate_ohms;
> -
> -	struct touchscreen_properties prop;
> -
> -	bool			report_resistance;
> -	u16			min_x;
> -	u16			min_y;
> -	u16			max_x;
> -	u16			max_y;
> -	u16			max_rt;
> -	unsigned long		poll_period; /* in jiffies */
> -	int			fuzzx;
> -	int			fuzzy;
> -	int			fuzzz;
> -
> -	unsigned		gpio;
> -	int			irq;
> -
> -	wait_queue_head_t	wait;
> -	bool			stopped;
> +#include "tsc2007.h"
>  
> -	int			(*get_pendown_state)(struct device *);
> -	void			(*clear_penirq)(void);
> -};
>  
> -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>  {
>  	s32 data;
>  	u16 val;
> @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
>  	tsc2007_xfer(tsc, PWRDOWN);
>  }
>  
> -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>  					struct ts_event *tc)
>  {
>  	u32 rt = 0;
> @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>  	return rt;
>  }
>  
> -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
> +bool tsc2007_is_pen_down(struct tsc2007 *ts)
>  {
>  	/*
>  	 * NOTE: We can't rely on the pressure to determine the pen down
> @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
>  	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
>  
>  		/* pen is down, continue with the measurement */
> +
> +		mutex_lock(&ts->mlock);
>  		tsc2007_read_values(ts, &tc);
> +		mutex_unlock(&ts->mlock);
>  
>  		rt = tsc2007_calculate_resistance(ts, &tc);
>  
> @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
>  static int tsc2007_probe(struct i2c_client *client,
>  			 const struct i2c_device_id *id)
>  {
> -	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
> +	const struct tsc2007_platform_data *pdata =
> +		dev_get_platdata(&client->dev);
>  	struct tsc2007 *ts;
>  	struct input_dev *input_dev;
>  	int err;
> @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
>  	ts->client = client;
>  	ts->irq = client->irq;
>  	ts->input = input_dev;
> +
>  	init_waitqueue_head(&ts->wait);
> +	mutex_init(&ts->mlock);
>  
>  	snprintf(ts->phys, sizeof(ts->phys),
>  		 "%s/input0", dev_name(&client->dev));
> @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
>  	if (err < 0) {
>  		dev_err(&client->dev,
>  			"Failed to setup chip: %d\n", err);
> -		return err;	/* usually, chip does not respond */
> +		return err;	/* chip does not respond */
>  	}
>  
>  	err = input_register_device(input_dev);
> @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
>  		return err;
>  	}
>  
> +	return tsc2007_iio_configure(ts);
> +}
> +
> +static int tsc2007_remove(struct i2c_client *client)
> +{
> +	struct tsc2007 *ts = i2c_get_clientdata(client);
> +
> +	tsc2007_iio_unconfigure(ts);
>  	return 0;
>  }
>  
> @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
>  	},
>  	.id_table	= tsc2007_idtable,
>  	.probe		= tsc2007_probe,
> +	.remove		= tsc2007_remove,
>  };
>  
>  module_i2c_driver(tsc2007_driver);
> diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
> new file mode 100644
> index 0000000..ed79944
> --- /dev/null
> +++ b/drivers/input/touchscreen/tsc2007_iio.c
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
> + *	Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include "tsc2007.h"
> +
> +struct tsc2007_iio {
> +	struct tsc2007 *ts;
> +};
> +
> +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
> +{ \
> +	.datasheet_name = _name, \
> +	.type = _type, \
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
> +			BIT(_chan_info), \
> +	.indexed = 1, \
> +	.channel = _chan, \
> +}
> +
> +static const struct iio_chan_spec tsc2007_iio_channel[] = {
> +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
> +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
> +};
> +
> +static int tsc2007_read_raw(struct iio_dev *indio_dev,
> +	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
> +{
> +	struct tsc2007_iio *iio = iio_priv(indio_dev);
> +	struct tsc2007 *tsc = iio->ts;
> +	int adc_chan = chan->channel;
> +	int ret = 0;
> +
> +	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
> +		return -EINVAL;
> +
> +	if (mask != IIO_CHAN_INFO_RAW)
> +		return -EINVAL;
> +
> +	mutex_lock(&tsc->mlock);
> +
> +	switch (chan->channel) {
> +	case 0:
> +		*val = tsc2007_xfer(tsc, READ_X);
> +		break;
> +	case 1:
> +		*val = tsc2007_xfer(tsc, READ_Y);
> +		break;
> +	case 2:
> +		*val = tsc2007_xfer(tsc, READ_Z1);
> +		break;
> +	case 3:
> +		*val = tsc2007_xfer(tsc, READ_Z2);
> +		break;
> +	case 4:
> +		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
> +		break;
> +	case 5: {
> +		struct ts_event tc;
> +
> +		tc.x = tsc2007_xfer(tsc, READ_X);
> +		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
> +		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
> +		*val = tsc2007_calculate_resistance(tsc, &tc);
> +		break;
> +	}
> +	case 6:
> +		*val = tsc2007_is_pen_down(tsc);
> +		break;
> +	case 7:
> +		*val = tsc2007_xfer(tsc,
> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
> +		break;
> +	case 8:
> +		*val = tsc2007_xfer(tsc,
> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
> +		break;
> +	}
> +
> +	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
> +	tsc2007_xfer(tsc, PWRDOWN);
> +
> +	mutex_unlock(&tsc->mlock);
> +
> +	ret = IIO_VAL_INT;
> +
> +	return ret;
> +}
> +
> +static const struct iio_info tsc2007_iio_info = {
> +	.read_raw = tsc2007_read_raw,
> +	.driver_module = THIS_MODULE,
> +};
> +
> +int tsc2007_iio_configure(struct tsc2007 *ts)
> +{
> +	int err;
> +	struct iio_dev *indio_dev;
> +	struct tsc2007_iio *iio;
> +
> +	indio_dev = devm_iio_device_alloc(&ts->client->dev,
> +		sizeof(struct tsc2007_iio));
> +	if (!indio_dev) {
> +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
> +		return -ENOMEM;
> +	}
> +
> +	iio = iio_priv(indio_dev);
> +	iio->ts = ts;
> +	ts->iio_dev = (void *) indio_dev;
> +
> +	indio_dev->name = "tsc2007";
> +	indio_dev->dev.parent = &ts->client->dev;
> +	indio_dev->info = &tsc2007_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = tsc2007_iio_channel;
> +	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
> +
> +	err = iio_device_register(indio_dev);
> +	if (err < 0) {
> +		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
> +			err);
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(tsc2007_iio_configure);
> +
> +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> +{
> +	struct iio_dev *indio_dev = ts->iio_dev;
> +
> +	iio_device_unregister(indio_dev);
> +}
> +EXPORT_SYMBOL(tsc2007_iio_unconfigure);
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Rob Herring]

On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
> 
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
> 
> A new feature is to introduce scaling the min/max ADC values to the screen
> size.
> 
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> well enough operate the touch before a user space calibration step can
> improve the precision.
> 
> Please note that the old ti,fuzz properties have been removed since they
> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> 
> Finally, calculate_pressure has been renamed to calculate_resistance
> because that is what it is doing.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  .../bindings/input/touchscreen/tsc2007.txt         |  20 ++--

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

>  drivers/input/touchscreen/tsc2007.c                | 120 +++++++++++++++++----
>  include/linux/i2c/tsc2007.h                        |   8 ++
>  3 files changed, 118 insertions(+), 30 deletions(-)

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Rob Herring]

On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
> 
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
> 
> A new feature is to introduce scaling the min/max ADC values to the screen
> size.
> 
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> well enough operate the touch before a user space calibration step can
> improve the precision.
> 
> Please note that the old ti,fuzz properties have been removed since they
> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> 
> Finally, calculate_pressure has been renamed to calculate_resistance
> because that is what it is doing.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  .../bindings/input/touchscreen/tsc2007.txt         |  20 ++--

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

>  drivers/input/touchscreen/tsc2007.c                | 120 +++++++++++++++++----
>  include/linux/i2c/tsc2007.h                        |   8 ++
>  3 files changed, 118 insertions(+), 30 deletions(-)

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

ping

> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Changes V9:
> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
> * make the tsc2007 iio patch the last one in this sequence
> 
> 2016-11-22 15:02:42: Changes V8:
> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23@kernel.org>)
> * add some more Reviewed-by: and Acked-by:
> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> ** drop patch "send pendown and penup only once" (input core does take care of it now)
> ** remove not necessary EXPORT_SYMBOL
> ** remove explicit file names from comment header
> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
> ** remove unnecessary input_unregister_device() 
> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
> 
> 2016-11-11 20:02:11: Changes V7:
> * rearranged the include files (asked for by Jonathan Cameron <jic23@kernel.org>)
> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
> * add some Acked-by:
> 
> 2016-10-27 10:44:29: Changes V6:
> * iio patch (no changes elsewhere)
> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
> 	- tsc2007_iio: fix copyright (this file is 100% original work)
> 
> 2016-10-25 21:26:46: Changes V5:
> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd@ti.com>)
> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd@ti.com>)
> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23@kernel.org>)
> 
> 2016-10-17 16:00:02: Changes V4:
> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23@kernel.org>)
> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23@kernel.org>)
> * swapped patch 3/n and patch 4/n to remove internal dependency
> 
> 2016-09-23 14:41:23: Changes V3:
> * fix an issue with swapping
> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> 
> 2015-11-13 21:36:07: Changes V2:
> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
> 
> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
> OpenPandora and Pyra devices.
> 
> New common bindings have been defined by
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
> 
> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> which also defines a helper function to parse the DT. These new parameters
> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
> swapping of x and y to achieve inversion and rotation so that the touch
> coordinate axes match the natural orientation of the display panel.
> 
> Another improvement is to better use the min/max ADC values and
> scale to the screen size as defined by the DT. This allows to coarsely
> calibrate the touch to match the LCD to which it is glued on so that the
> touch can quite precisely be operated before any user-space fine-calibration
> can be (and needs to be) started.
> 
> For the adc7846 we fix an issue with the spi module table.
> 
> Finally we add an iio interface for the AUX and temperature ADC channels of
> the tsc2007 and also provide the touch screen raw values. This allows to read
> an optional ambient light sensor installed on the gta04 board and improves
> calibration and hardware monitoring.
> 
> 
> H. Nikolaus Schaller (8):
>  drivers:input:tsc2007: add new common binding names, pre-calibration,
>    flipping and rotation
>  drivers:input:tsc2007: check for presence and power down tsc2007
>    during probe
>  DT:omap3+tsc2007: use new common touchscreen bindings
>  drivers:input:ads7846(+tsc2046): add new common binding names,
>    pre-calibration and flipping
>  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>  drivers:input:ads7846(+tsc2046): fix spi module table
>  DT:omap3+ads7846: use new common touchscreen bindings
>  drivers:input:tsc2007: add iio interface to read external ADC input
>    and temperature
> 
> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
> drivers/input/touchscreen/Kconfig                  |  10 +
> drivers/input/touchscreen/Makefile                 |   2 +
> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
> include/linux/i2c/tsc2007.h                        |   8 +
> 13 files changed, 520 insertions(+), 114 deletions(-)
> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
> create mode 100644 drivers/input/touchscreen/tsc2007.h
> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
> 
> -- 
> 2.7.3
> 

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

ping

> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> 
> Changes V9:
> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>)
> * make the tsc2007 iio patch the last one in this sequence
> 
> 2016-11-22 15:02:42: Changes V8:
> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
> * add some more Reviewed-by: and Acked-by:
> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> ** drop patch "send pendown and penup only once" (input core does take care of it now)
> ** remove not necessary EXPORT_SYMBOL
> ** remove explicit file names from comment header
> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
> ** remove unnecessary input_unregister_device() 
> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
> 
> 2016-11-11 20:02:11: Changes V7:
> * rearranged the include files (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
> * add some Acked-by:
> 
> 2016-10-27 10:44:29: Changes V6:
> * iio patch (no changes elsewhere)
> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
> 	- tsc2007_iio: fix copyright (this file is 100% original work)
> 
> 2016-10-25 21:26:46: Changes V5:
> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
> 
> 2016-10-17 16:00:02: Changes V4:
> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
> * swapped patch 3/n and patch 4/n to remove internal dependency
> 
> 2016-09-23 14:41:23: Changes V3:
> * fix an issue with swapping
> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> 
> 2015-11-13 21:36:07: Changes V2:
> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
> 
> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
> OpenPandora and Pyra devices.
> 
> New common bindings have been defined by
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
> 
> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> which also defines a helper function to parse the DT. These new parameters
> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
> swapping of x and y to achieve inversion and rotation so that the touch
> coordinate axes match the natural orientation of the display panel.
> 
> Another improvement is to better use the min/max ADC values and
> scale to the screen size as defined by the DT. This allows to coarsely
> calibrate the touch to match the LCD to which it is glued on so that the
> touch can quite precisely be operated before any user-space fine-calibration
> can be (and needs to be) started.
> 
> For the adc7846 we fix an issue with the spi module table.
> 
> Finally we add an iio interface for the AUX and temperature ADC channels of
> the tsc2007 and also provide the touch screen raw values. This allows to read
> an optional ambient light sensor installed on the gta04 board and improves
> calibration and hardware monitoring.
> 
> 
> H. Nikolaus Schaller (8):
>  drivers:input:tsc2007: add new common binding names, pre-calibration,
>    flipping and rotation
>  drivers:input:tsc2007: check for presence and power down tsc2007
>    during probe
>  DT:omap3+tsc2007: use new common touchscreen bindings
>  drivers:input:ads7846(+tsc2046): add new common binding names,
>    pre-calibration and flipping
>  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>  drivers:input:ads7846(+tsc2046): fix spi module table
>  DT:omap3+ads7846: use new common touchscreen bindings
>  drivers:input:tsc2007: add iio interface to read external ADC input
>    and temperature
> 
> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
> drivers/input/touchscreen/Kconfig                  |  10 +
> drivers/input/touchscreen/Makefile                 |   2 +
> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
> include/linux/i2c/tsc2007.h                        |   8 +
> 13 files changed, 520 insertions(+), 114 deletions(-)
> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
> create mode 100644 drivers/input/touchscreen/tsc2007.h
> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
> 
> -- 
> 2.7.3
> 

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

ping

> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>=20
> Changes V9:
> * added explicit CONFIG for TSC2007_IIO and simplified Makefile =
(suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
> * make the tsc2007 iio patch the last one in this sequence
>=20
> 2016-11-22 15:02:42: Changes V8:
> * fix compilation for CONFIG_IIO=3Dm (reported by Jonathan Cameron =
<jic23@kernel.org>)
> * add some more Reviewed-by: and Acked-by:
> * mutiple improvements suggested by Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
> ** drop patch "send pendown and penup only once" (input core does take =
care of it now)
> ** remove not necessary EXPORT_SYMBOL
> ** remove explicit file names from comment header
> ** move tsc2007_iio_configure() to the end of the probe process and =
simplify the error path again
> ** remove unnecessary input_unregister_device()=20
> ** improvement for compilation with CONFIG_IIO=3Dm and =
CONFIG_TSC2007=3Dy
>=20
> 2016-11-11 20:02:11: Changes V7:
> * rearranged the include files (asked for by Jonathan Cameron =
<jic23@kernel.org>)
> * forward reference struct iio_dev * instead of condition in tsc2007.h =
(asked for by Jonathan Cameron <jic23@kernel.org>)
> * add some Acked-by:
>=20
> 2016-10-27 10:44:29: Changes V6:
> * iio patch (no changes elsewhere)
> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by =
kbuid test robot)
> 	- tsc2007_core: group error return paths so that =
tsc2007_iio_unconfigure is called at only one place
> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>=20
> 2016-10-25 21:26:46: Changes V5:
> * ads7846: remove an empty line (suggested by Andrew F. Davis =
<afd@ti.com>)
> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis =
<afd@ti.com>)
> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by =
kbuild test robot)
> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by =
Jonathan Cameron <jic23@kernel.org>)
>=20
> 2016-10-17 16:00:02: Changes V4:
> * fix a merge/squash issue resulting in a non-bisectable patch set =
(suggested by kbuid test robot)
> * remove some unnecessary #include (suggested by Jonathan Cameron =
<jic23@kernel.org>)
> * make the iio extension depend on CONFIG_IIO rather than selecting it =
(suggested by Jonathan Cameron <jic23@kernel.org>)
> * swapped patch 3/n and patch 4/n to remove internal dependency
>=20
> 2016-09-23 14:41:23: Changes V3:
> * fix an issue with swapping
> * remove hard clipping to min/max rectangle - some systems expect to =
handle negative coordinates
> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add =
support for inverted / swapped axes")
>=20
> 2015-11-13 21:36:07: Changes V2:
> * add a patch to make drivers still recognise the old "ti,swap-xy" =
property (suggested by Rob Herring)
>=20
> 2015-11-06 16:14:53: V1: This patch series improves the drivers for =
the tsc2007 and
> ads7846/tsc2046 touchscreen controllers which are e.g. used by the =
GTA04
> OpenPandora and Pyra devices.
>=20
> New common bindings have been defined by
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>=20
> 	=
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>=20
> which also defines a helper function to parse the DT. These new =
parameters
> allow to specify the fuzz factors (jitter suppression), inversion of x =
or y axis and
> swapping of x and y to achieve inversion and rotation so that the =
touch
> coordinate axes match the natural orientation of the display panel.
>=20
> Another improvement is to better use the min/max ADC values and
> scale to the screen size as defined by the DT. This allows to coarsely
> calibrate the touch to match the LCD to which it is glued on so that =
the
> touch can quite precisely be operated before any user-space =
fine-calibration
> can be (and needs to be) started.
>=20
> For the adc7846 we fix an issue with the spi module table.
>=20
> Finally we add an iio interface for the AUX and temperature ADC =
channels of
> the tsc2007 and also provide the touch screen raw values. This allows =
to read
> an optional ambient light sensor installed on the gta04 board and =
improves
> calibration and hardware monitoring.
>=20
>=20
> H. Nikolaus Schaller (8):
>  drivers:input:tsc2007: add new common binding names, pre-calibration,
>    flipping and rotation
>  drivers:input:tsc2007: check for presence and power down tsc2007
>    during probe
>  DT:omap3+tsc2007: use new common touchscreen bindings
>  drivers:input:ads7846(+tsc2046): add new common binding names,
>    pre-calibration and flipping
>  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>  drivers:input:ads7846(+tsc2046): fix spi module table
>  DT:omap3+ads7846: use new common touchscreen bindings
>  drivers:input:tsc2007: add iio interface to read external ADC input
>    and temperature
>=20
> .../bindings/input/{ =3D> touchscreen}/ads7846.txt   |   9 +-
> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
> drivers/input/touchscreen/Kconfig                  |  10 +
> drivers/input/touchscreen/Makefile                 |   2 +
> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
> .../touchscreen/{tsc2007.c =3D> tsc2007_core.c}      | 201 =
++++++++++++---------
> drivers/input/touchscreen/tsc2007_iio.c            | 150 =
+++++++++++++++
> include/linux/i2c/tsc2007.h                        |   8 +
> 13 files changed, 520 insertions(+), 114 deletions(-)
> rename Documentation/devicetree/bindings/input/{ =3D> =
touchscreen}/ads7846.txt (90%)
> create mode 100644 drivers/input/touchscreen/tsc2007.h
> rename drivers/input/touchscreen/{tsc2007.c =3D> tsc2007_core.c} (74%)
> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>=20
> --=20
> 2.7.3
>=20

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[Jonathan Cameron]

On 16/01/17 06:34, H. Nikolaus Schaller wrote:
> ping
Always good to say who you are pinging ;)  Saves the rest of us wondering
if we have missing something we should have reviewed.

Guessing it's Dmitry in this case!

Jonathan
> 
>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>
>> Changes V9:
>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
>> * make the tsc2007 iio patch the last one in this sequence
>>
>> 2016-11-22 15:02:42: Changes V8:
>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23@kernel.org>)
>> * add some more Reviewed-by: and Acked-by:
>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>> ** remove not necessary EXPORT_SYMBOL
>> ** remove explicit file names from comment header
>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>> ** remove unnecessary input_unregister_device() 
>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>
>> 2016-11-11 20:02:11: Changes V7:
>> * rearranged the include files (asked for by Jonathan Cameron <jic23@kernel.org>)
>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
>> * add some Acked-by:
>>
>> 2016-10-27 10:44:29: Changes V6:
>> * iio patch (no changes elsewhere)
>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>
>> 2016-10-25 21:26:46: Changes V5:
>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd@ti.com>)
>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd@ti.com>)
>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23@kernel.org>)
>>
>> 2016-10-17 16:00:02: Changes V4:
>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23@kernel.org>)
>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23@kernel.org>)
>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>
>> 2016-09-23 14:41:23: Changes V3:
>> * fix an issue with swapping
>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>
>> 2015-11-13 21:36:07: Changes V2:
>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>
>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>> OpenPandora and Pyra devices.
>>
>> New common bindings have been defined by
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>
>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>
>> which also defines a helper function to parse the DT. These new parameters
>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>> swapping of x and y to achieve inversion and rotation so that the touch
>> coordinate axes match the natural orientation of the display panel.
>>
>> Another improvement is to better use the min/max ADC values and
>> scale to the screen size as defined by the DT. This allows to coarsely
>> calibrate the touch to match the LCD to which it is glued on so that the
>> touch can quite precisely be operated before any user-space fine-calibration
>> can be (and needs to be) started.
>>
>> For the adc7846 we fix an issue with the spi module table.
>>
>> Finally we add an iio interface for the AUX and temperature ADC channels of
>> the tsc2007 and also provide the touch screen raw values. This allows to read
>> an optional ambient light sensor installed on the gta04 board and improves
>> calibration and hardware monitoring.
>>
>>
>> H. Nikolaus Schaller (8):
>>  drivers:input:tsc2007: add new common binding names, pre-calibration,
>>    flipping and rotation
>>  drivers:input:tsc2007: check for presence and power down tsc2007
>>    during probe
>>  DT:omap3+tsc2007: use new common touchscreen bindings
>>  drivers:input:ads7846(+tsc2046): add new common binding names,
>>    pre-calibration and flipping
>>  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>  drivers:input:ads7846(+tsc2046): fix spi module table
>>  DT:omap3+ads7846: use new common touchscreen bindings
>>  drivers:input:tsc2007: add iio interface to read external ADC input
>>    and temperature
>>
>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>> drivers/input/touchscreen/Kconfig                  |  10 +
>> drivers/input/touchscreen/Makefile                 |   2 +
>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>> include/linux/i2c/tsc2007.h                        |   8 +
>> 13 files changed, 520 insertions(+), 114 deletions(-)
>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>
>> -- 
>> 2.7.3
>>
> 

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[Jonathan Cameron]

On 16/01/17 06:34, H. Nikolaus Schaller wrote:
> ping
Always good to say who you are pinging ;)  Saves the rest of us wondering
if we have missing something we should have reviewed.

Guessing it's Dmitry in this case!

Jonathan
> 
>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>
>> Changes V9:
>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>)
>> * make the tsc2007 iio patch the last one in this sequence
>>
>> 2016-11-22 15:02:42: Changes V8:
>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>> * add some more Reviewed-by: and Acked-by:
>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>> ** remove not necessary EXPORT_SYMBOL
>> ** remove explicit file names from comment header
>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>> ** remove unnecessary input_unregister_device() 
>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>
>> 2016-11-11 20:02:11: Changes V7:
>> * rearranged the include files (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>> * add some Acked-by:
>>
>> 2016-10-27 10:44:29: Changes V6:
>> * iio patch (no changes elsewhere)
>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>
>> 2016-10-25 21:26:46: Changes V5:
>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>
>> 2016-10-17 16:00:02: Changes V4:
>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>
>> 2016-09-23 14:41:23: Changes V3:
>> * fix an issue with swapping
>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>
>> 2015-11-13 21:36:07: Changes V2:
>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>
>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>> OpenPandora and Pyra devices.
>>
>> New common bindings have been defined by
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>
>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>
>> which also defines a helper function to parse the DT. These new parameters
>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>> swapping of x and y to achieve inversion and rotation so that the touch
>> coordinate axes match the natural orientation of the display panel.
>>
>> Another improvement is to better use the min/max ADC values and
>> scale to the screen size as defined by the DT. This allows to coarsely
>> calibrate the touch to match the LCD to which it is glued on so that the
>> touch can quite precisely be operated before any user-space fine-calibration
>> can be (and needs to be) started.
>>
>> For the adc7846 we fix an issue with the spi module table.
>>
>> Finally we add an iio interface for the AUX and temperature ADC channels of
>> the tsc2007 and also provide the touch screen raw values. This allows to read
>> an optional ambient light sensor installed on the gta04 board and improves
>> calibration and hardware monitoring.
>>
>>
>> H. Nikolaus Schaller (8):
>>  drivers:input:tsc2007: add new common binding names, pre-calibration,
>>    flipping and rotation
>>  drivers:input:tsc2007: check for presence and power down tsc2007
>>    during probe
>>  DT:omap3+tsc2007: use new common touchscreen bindings
>>  drivers:input:ads7846(+tsc2046): add new common binding names,
>>    pre-calibration and flipping
>>  dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>  drivers:input:ads7846(+tsc2046): fix spi module table
>>  DT:omap3+ads7846: use new common touchscreen bindings
>>  drivers:input:tsc2007: add iio interface to read external ADC input
>>    and temperature
>>
>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>> drivers/input/touchscreen/Kconfig                  |  10 +
>> drivers/input/touchscreen/Makefile                 |   2 +
>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>> include/linux/i2c/tsc2007.h                        |   8 +
>> 13 files changed, 520 insertions(+), 114 deletions(-)
>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>
>> -- 
>> 2.7.3
>>
> 

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

> Am 21.01.2017 um 14:08 schrieb Jonathan Cameron <jic23@kernel.org>:
> 
> On 16/01/17 06:34, H. Nikolaus Schaller wrote:
>> ping
> Always good to say who you are pinging ;)

default = Maintainer

Only he/she can finally accept a patch series so I assume he has
to take action if there are no more things to debate.

>  Saves the rest of us wondering
> if we have missing something we should have reviewed.
> 
> Guessing it's Dmitry in this case!

Yes, you are right. Since there have not been any more comments for a
while, I formally ask to add this to some tree so that it appears in
linux-next for further tests.

BR and thanks,
Nikolaus

> 
> Jonathan
>> 
>>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>> 
>>> Changes V9:
>>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
>>> * make the tsc2007 iio patch the last one in this sequence
>>> 
>>> 2016-11-22 15:02:42: Changes V8:
>>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23@kernel.org>)
>>> * add some more Reviewed-by: and Acked-by:
>>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>>> ** remove not necessary EXPORT_SYMBOL
>>> ** remove explicit file names from comment header
>>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>>> ** remove unnecessary input_unregister_device() 
>>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>> 
>>> 2016-11-11 20:02:11: Changes V7:
>>> * rearranged the include files (asked for by Jonathan Cameron <jic23@kernel.org>)
>>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
>>> * add some Acked-by:
>>> 
>>> 2016-10-27 10:44:29: Changes V6:
>>> * iio patch (no changes elsewhere)
>>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>> 
>>> 2016-10-25 21:26:46: Changes V5:
>>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd@ti.com>)
>>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd@ti.com>)
>>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23@kernel.org>)
>>> 
>>> 2016-10-17 16:00:02: Changes V4:
>>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23@kernel.org>)
>>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23@kernel.org>)
>>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>> 
>>> 2016-09-23 14:41:23: Changes V3:
>>> * fix an issue with swapping
>>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>> 
>>> 2015-11-13 21:36:07: Changes V2:
>>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>> 
>>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>>> OpenPandora and Pyra devices.
>>> 
>>> New common bindings have been defined by
>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>> 
>>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>> 
>>> which also defines a helper function to parse the DT. These new parameters
>>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>>> swapping of x and y to achieve inversion and rotation so that the touch
>>> coordinate axes match the natural orientation of the display panel.
>>> 
>>> Another improvement is to better use the min/max ADC values and
>>> scale to the screen size as defined by the DT. This allows to coarsely
>>> calibrate the touch to match the LCD to which it is glued on so that the
>>> touch can quite precisely be operated before any user-space fine-calibration
>>> can be (and needs to be) started.
>>> 
>>> For the adc7846 we fix an issue with the spi module table.
>>> 
>>> Finally we add an iio interface for the AUX and temperature ADC channels of
>>> the tsc2007 and also provide the touch screen raw values. This allows to read
>>> an optional ambient light sensor installed on the gta04 board and improves
>>> calibration and hardware monitoring.
>>> 
>>> 
>>> H. Nikolaus Schaller (8):
>>> drivers:input:tsc2007: add new common binding names, pre-calibration,
>>>   flipping and rotation
>>> drivers:input:tsc2007: check for presence and power down tsc2007
>>>   during probe
>>> DT:omap3+tsc2007: use new common touchscreen bindings
>>> drivers:input:ads7846(+tsc2046): add new common binding names,
>>>   pre-calibration and flipping
>>> dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>> drivers:input:ads7846(+tsc2046): fix spi module table
>>> DT:omap3+ads7846: use new common touchscreen bindings
>>> drivers:input:tsc2007: add iio interface to read external ADC input
>>>   and temperature
>>> 
>>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>>> drivers/input/touchscreen/Kconfig                  |  10 +
>>> drivers/input/touchscreen/Makefile                 |   2 +
>>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>>> include/linux/i2c/tsc2007.h                        |   8 +
>>> 13 files changed, 520 insertions(+), 114 deletions(-)
>>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>> 
>>> -- 
>>> 2.7.3
>>> 
>> 
> 

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

> Am 21.01.2017 um 14:08 schrieb Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> 
> On 16/01/17 06:34, H. Nikolaus Schaller wrote:
>> ping
> Always good to say who you are pinging ;)

default = Maintainer

Only he/she can finally accept a patch series so I assume he has
to take action if there are no more things to debate.

>  Saves the rest of us wondering
> if we have missing something we should have reviewed.
> 
> Guessing it's Dmitry in this case!

Yes, you are right. Since there have not been any more comments for a
while, I formally ask to add this to some tree so that it appears in
linux-next for further tests.

BR and thanks,
Nikolaus

> 
> Jonathan
>> 
>>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>> 
>>> Changes V9:
>>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>)
>>> * make the tsc2007 iio patch the last one in this sequence
>>> 
>>> 2016-11-22 15:02:42: Changes V8:
>>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>> * add some more Reviewed-by: and Acked-by:
>>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>>> ** remove not necessary EXPORT_SYMBOL
>>> ** remove explicit file names from comment header
>>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>>> ** remove unnecessary input_unregister_device() 
>>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>> 
>>> 2016-11-11 20:02:11: Changes V7:
>>> * rearranged the include files (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>> * add some Acked-by:
>>> 
>>> 2016-10-27 10:44:29: Changes V6:
>>> * iio patch (no changes elsewhere)
>>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>> 
>>> 2016-10-25 21:26:46: Changes V5:
>>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
>>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
>>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>> 
>>> 2016-10-17 16:00:02: Changes V4:
>>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>> 
>>> 2016-09-23 14:41:23: Changes V3:
>>> * fix an issue with swapping
>>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>> 
>>> 2015-11-13 21:36:07: Changes V2:
>>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>> 
>>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>>> OpenPandora and Pyra devices.
>>> 
>>> New common bindings have been defined by
>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>> 
>>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>> 
>>> which also defines a helper function to parse the DT. These new parameters
>>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>>> swapping of x and y to achieve inversion and rotation so that the touch
>>> coordinate axes match the natural orientation of the display panel.
>>> 
>>> Another improvement is to better use the min/max ADC values and
>>> scale to the screen size as defined by the DT. This allows to coarsely
>>> calibrate the touch to match the LCD to which it is glued on so that the
>>> touch can quite precisely be operated before any user-space fine-calibration
>>> can be (and needs to be) started.
>>> 
>>> For the adc7846 we fix an issue with the spi module table.
>>> 
>>> Finally we add an iio interface for the AUX and temperature ADC channels of
>>> the tsc2007 and also provide the touch screen raw values. This allows to read
>>> an optional ambient light sensor installed on the gta04 board and improves
>>> calibration and hardware monitoring.
>>> 
>>> 
>>> H. Nikolaus Schaller (8):
>>> drivers:input:tsc2007: add new common binding names, pre-calibration,
>>>   flipping and rotation
>>> drivers:input:tsc2007: check for presence and power down tsc2007
>>>   during probe
>>> DT:omap3+tsc2007: use new common touchscreen bindings
>>> drivers:input:ads7846(+tsc2046): add new common binding names,
>>>   pre-calibration and flipping
>>> dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>> drivers:input:ads7846(+tsc2046): fix spi module table
>>> DT:omap3+ads7846: use new common touchscreen bindings
>>> drivers:input:tsc2007: add iio interface to read external ADC input
>>>   and temperature
>>> 
>>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>>> drivers/input/touchscreen/Kconfig                  |  10 +
>>> drivers/input/touchscreen/Makefile                 |   2 +
>>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>>> include/linux/i2c/tsc2007.h                        |   8 +
>>> 13 files changed, 520 insertions(+), 114 deletions(-)
>>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>> 
>>> -- 
>>> 2.7.3
>>> 
>> 
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

> Am 21.01.2017 um 14:08 schrieb Jonathan Cameron <jic23@kernel.org>:
>=20
> On 16/01/17 06:34, H. Nikolaus Schaller wrote:
>> ping
> Always good to say who you are pinging ;)

default =3D Maintainer

Only he/she can finally accept a patch series so I assume he has
to take action if there are no more things to debate.

>  Saves the rest of us wondering
> if we have missing something we should have reviewed.
>=20
> Guessing it's Dmitry in this case!

Yes, you are right. Since there have not been any more comments for a
while, I formally ask to add this to some tree so that it appears in
linux-next for further tests.

BR and thanks,
Nikolaus

>=20
> Jonathan
>>=20
>>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>>>=20
>>> Changes V9:
>>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile =
(suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
>>> * make the tsc2007 iio patch the last one in this sequence
>>>=20
>>> 2016-11-22 15:02:42: Changes V8:
>>> * fix compilation for CONFIG_IIO=3Dm (reported by Jonathan Cameron =
<jic23@kernel.org>)
>>> * add some more Reviewed-by: and Acked-by:
>>> * mutiple improvements suggested by Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>> ** drop patch "send pendown and penup only once" (input core does =
take care of it now)
>>> ** remove not necessary EXPORT_SYMBOL
>>> ** remove explicit file names from comment header
>>> ** move tsc2007_iio_configure() to the end of the probe process and =
simplify the error path again
>>> ** remove unnecessary input_unregister_device()=20
>>> ** improvement for compilation with CONFIG_IIO=3Dm and =
CONFIG_TSC2007=3Dy
>>>=20
>>> 2016-11-11 20:02:11: Changes V7:
>>> * rearranged the include files (asked for by Jonathan Cameron =
<jic23@kernel.org>)
>>> * forward reference struct iio_dev * instead of condition in =
tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
>>> * add some Acked-by:
>>>=20
>>> 2016-10-27 10:44:29: Changes V6:
>>> * iio patch (no changes elsewhere)
>>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by =
kbuid test robot)
>>> 	- tsc2007_core: group error return paths so that =
tsc2007_iio_unconfigure is called at only one place
>>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>>=20
>>> 2016-10-25 21:26:46: Changes V5:
>>> * ads7846: remove an empty line (suggested by Andrew F. Davis =
<afd@ti.com>)
>>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis =
<afd@ti.com>)
>>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by =
kbuild test robot)
>>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by =
Jonathan Cameron <jic23@kernel.org>)
>>>=20
>>> 2016-10-17 16:00:02: Changes V4:
>>> * fix a merge/squash issue resulting in a non-bisectable patch set =
(suggested by kbuid test robot)
>>> * remove some unnecessary #include (suggested by Jonathan Cameron =
<jic23@kernel.org>)
>>> * make the iio extension depend on CONFIG_IIO rather than selecting =
it (suggested by Jonathan Cameron <jic23@kernel.org>)
>>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>>=20
>>> 2016-09-23 14:41:23: Changes V3:
>>> * fix an issue with swapping
>>> * remove hard clipping to min/max rectangle - some systems expect to =
handle negative coordinates
>>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add =
support for inverted / swapped axes")
>>>=20
>>> 2015-11-13 21:36:07: Changes V2:
>>> * add a patch to make drivers still recognise the old "ti,swap-xy" =
property (suggested by Rob Herring)
>>>=20
>>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for =
the tsc2007 and
>>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the =
GTA04
>>> OpenPandora and Pyra devices.
>>>=20
>>> New common bindings have been defined by
>>> commit b98abe52fa8e ("Input: add common DT binding for =
touchscreens"):
>>>=20
>>> 	=
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>>=20
>>> which also defines a helper function to parse the DT. These new =
parameters
>>> allow to specify the fuzz factors (jitter suppression), inversion of =
x or y axis and
>>> swapping of x and y to achieve inversion and rotation so that the =
touch
>>> coordinate axes match the natural orientation of the display panel.
>>>=20
>>> Another improvement is to better use the min/max ADC values and
>>> scale to the screen size as defined by the DT. This allows to =
coarsely
>>> calibrate the touch to match the LCD to which it is glued on so that =
the
>>> touch can quite precisely be operated before any user-space =
fine-calibration
>>> can be (and needs to be) started.
>>>=20
>>> For the adc7846 we fix an issue with the spi module table.
>>>=20
>>> Finally we add an iio interface for the AUX and temperature ADC =
channels of
>>> the tsc2007 and also provide the touch screen raw values. This =
allows to read
>>> an optional ambient light sensor installed on the gta04 board and =
improves
>>> calibration and hardware monitoring.
>>>=20
>>>=20
>>> H. Nikolaus Schaller (8):
>>> drivers:input:tsc2007: add new common binding names, =
pre-calibration,
>>>   flipping and rotation
>>> drivers:input:tsc2007: check for presence and power down tsc2007
>>>   during probe
>>> DT:omap3+tsc2007: use new common touchscreen bindings
>>> drivers:input:ads7846(+tsc2046): add new common binding names,
>>>   pre-calibration and flipping
>>> dt-bindings: input: move ads7846 bindings to touchscreen =
subdirectory
>>> drivers:input:ads7846(+tsc2046): fix spi module table
>>> DT:omap3+ads7846: use new common touchscreen bindings
>>> drivers:input:tsc2007: add iio interface to read external ADC input
>>>   and temperature
>>>=20
>>> .../bindings/input/{ =3D> touchscreen}/ads7846.txt   |   9 +-
>>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>>> drivers/input/touchscreen/Kconfig                  |  10 +
>>> drivers/input/touchscreen/Makefile                 |   2 +
>>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>>> drivers/input/touchscreen/tsc2007.h                | 116 =
++++++++++++
>>> .../touchscreen/{tsc2007.c =3D> tsc2007_core.c}      | 201 =
++++++++++++---------
>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 =
+++++++++++++++
>>> include/linux/i2c/tsc2007.h                        |   8 +
>>> 13 files changed, 520 insertions(+), 114 deletions(-)
>>> rename Documentation/devicetree/bindings/input/{ =3D> =
touchscreen}/ads7846.txt (90%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c =3D> tsc2007_core.c} =
(74%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>=20
>>> --=20
>>> 2.7.3
>>>=20
>>=20
>=20

Re: [Letux-kernel] [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,
there have been no further comments/complaints about this patch series in the last month.
And it appears as if only your action is needed.

What is missing for this patch series to be finally accepted?

BR,
Nikolaus


> Am 21.01.2017 um 14:17 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> 
>> Am 21.01.2017 um 14:08 schrieb Jonathan Cameron <jic23@kernel.org>:
>> 
>> On 16/01/17 06:34, H. Nikolaus Schaller wrote:
>>> ping
>> Always good to say who you are pinging ;)
> 
> default = Maintainer
> 
> Only he/she can finally accept a patch series so I assume he has
> to take action if there are no more things to debate.
> 
>> Saves the rest of us wondering
>> if we have missing something we should have reviewed.
>> 
>> Guessing it's Dmitry in this case!
> 
> Yes, you are right. Since there have not been any more comments for a
> while, I formally ask to add this to some tree so that it appears in
> linux-next for further tests.
> 
> BR and thanks,
> Nikolaus
> 
>> 
>> Jonathan
>>> 
>>>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> Changes V9:
>>>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
>>>> * make the tsc2007 iio patch the last one in this sequence
>>>> 
>>>> 2016-11-22 15:02:42: Changes V8:
>>>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23@kernel.org>)
>>>> * add some more Reviewed-by: and Acked-by:
>>>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>>>> ** remove not necessary EXPORT_SYMBOL
>>>> ** remove explicit file names from comment header
>>>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>>>> ** remove unnecessary input_unregister_device() 
>>>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>>> 
>>>> 2016-11-11 20:02:11: Changes V7:
>>>> * rearranged the include files (asked for by Jonathan Cameron <jic23@kernel.org>)
>>>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
>>>> * add some Acked-by:
>>>> 
>>>> 2016-10-27 10:44:29: Changes V6:
>>>> * iio patch (no changes elsewhere)
>>>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>>>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>>>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>>> 
>>>> 2016-10-25 21:26:46: Changes V5:
>>>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd@ti.com>)
>>>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd@ti.com>)
>>>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>>>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23@kernel.org>)
>>>> 
>>>> 2016-10-17 16:00:02: Changes V4:
>>>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>>>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23@kernel.org>)
>>>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23@kernel.org>)
>>>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>>> 
>>>> 2016-09-23 14:41:23: Changes V3:
>>>> * fix an issue with swapping
>>>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>>>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> 
>>>> 2015-11-13 21:36:07: Changes V2:
>>>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>>> 
>>>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>>>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>>>> OpenPandora and Pyra devices.
>>>> 
>>>> New common bindings have been defined by
>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>>> 
>>>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>>> 
>>>> which also defines a helper function to parse the DT. These new parameters
>>>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>>>> swapping of x and y to achieve inversion and rotation so that the touch
>>>> coordinate axes match the natural orientation of the display panel.
>>>> 
>>>> Another improvement is to better use the min/max ADC values and
>>>> scale to the screen size as defined by the DT. This allows to coarsely
>>>> calibrate the touch to match the LCD to which it is glued on so that the
>>>> touch can quite precisely be operated before any user-space fine-calibration
>>>> can be (and needs to be) started.
>>>> 
>>>> For the adc7846 we fix an issue with the spi module table.
>>>> 
>>>> Finally we add an iio interface for the AUX and temperature ADC channels of
>>>> the tsc2007 and also provide the touch screen raw values. This allows to read
>>>> an optional ambient light sensor installed on the gta04 board and improves
>>>> calibration and hardware monitoring.
>>>> 
>>>> 
>>>> H. Nikolaus Schaller (8):
>>>> drivers:input:tsc2007: add new common binding names, pre-calibration,
>>>>  flipping and rotation
>>>> drivers:input:tsc2007: check for presence and power down tsc2007
>>>>  during probe
>>>> DT:omap3+tsc2007: use new common touchscreen bindings
>>>> drivers:input:ads7846(+tsc2046): add new common binding names,
>>>>  pre-calibration and flipping
>>>> dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>>> drivers:input:ads7846(+tsc2046): fix spi module table
>>>> DT:omap3+ads7846: use new common touchscreen bindings
>>>> drivers:input:tsc2007: add iio interface to read external ADC input
>>>>  and temperature
>>>> 
>>>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>>>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>>>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>>>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>>>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>>>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>>>> drivers/input/touchscreen/Kconfig                  |  10 +
>>>> drivers/input/touchscreen/Makefile                 |   2 +
>>>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>>>> include/linux/i2c/tsc2007.h                        |   8 +
>>>> 13 files changed, 520 insertions(+), 114 deletions(-)
>>>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>> 
>>>> -- 
>>>> 2.7.3
>>>> 
>>> 
>> 
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

Re: [Letux-kernel] [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,
there have been no further comments/complaints about this patch series in the last month.
And it appears as if only your action is needed.

What is missing for this patch series to be finally accepted?

BR,
Nikolaus


> Am 21.01.2017 um 14:17 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> 
> 
>> Am 21.01.2017 um 14:08 schrieb Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> 
>> On 16/01/17 06:34, H. Nikolaus Schaller wrote:
>>> ping
>> Always good to say who you are pinging ;)
> 
> default = Maintainer
> 
> Only he/she can finally accept a patch series so I assume he has
> to take action if there are no more things to debate.
> 
>> Saves the rest of us wondering
>> if we have missing something we should have reviewed.
>> 
>> Guessing it's Dmitry in this case!
> 
> Yes, you are right. Since there have not been any more comments for a
> while, I formally ask to add this to some tree so that it appears in
> linux-next for further tests.
> 
> BR and thanks,
> Nikolaus
> 
>> 
>> Jonathan
>>> 
>>>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>>> 
>>>> Changes V9:
>>>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>)
>>>> * make the tsc2007 iio patch the last one in this sequence
>>>> 
>>>> 2016-11-22 15:02:42: Changes V8:
>>>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>>> * add some more Reviewed-by: and Acked-by:
>>>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>>>> ** remove not necessary EXPORT_SYMBOL
>>>> ** remove explicit file names from comment header
>>>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>>>> ** remove unnecessary input_unregister_device() 
>>>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>>> 
>>>> 2016-11-11 20:02:11: Changes V7:
>>>> * rearranged the include files (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>>> * add some Acked-by:
>>>> 
>>>> 2016-10-27 10:44:29: Changes V6:
>>>> * iio patch (no changes elsewhere)
>>>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>>>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>>>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>>> 
>>>> 2016-10-25 21:26:46: Changes V5:
>>>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
>>>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
>>>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>>>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>>> 
>>>> 2016-10-17 16:00:02: Changes V4:
>>>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>>>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
>>>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>>> 
>>>> 2016-09-23 14:41:23: Changes V3:
>>>> * fix an issue with swapping
>>>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>>>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> 
>>>> 2015-11-13 21:36:07: Changes V2:
>>>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>>> 
>>>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>>>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>>>> OpenPandora and Pyra devices.
>>>> 
>>>> New common bindings have been defined by
>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>>> 
>>>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>>> 
>>>> which also defines a helper function to parse the DT. These new parameters
>>>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>>>> swapping of x and y to achieve inversion and rotation so that the touch
>>>> coordinate axes match the natural orientation of the display panel.
>>>> 
>>>> Another improvement is to better use the min/max ADC values and
>>>> scale to the screen size as defined by the DT. This allows to coarsely
>>>> calibrate the touch to match the LCD to which it is glued on so that the
>>>> touch can quite precisely be operated before any user-space fine-calibration
>>>> can be (and needs to be) started.
>>>> 
>>>> For the adc7846 we fix an issue with the spi module table.
>>>> 
>>>> Finally we add an iio interface for the AUX and temperature ADC channels of
>>>> the tsc2007 and also provide the touch screen raw values. This allows to read
>>>> an optional ambient light sensor installed on the gta04 board and improves
>>>> calibration and hardware monitoring.
>>>> 
>>>> 
>>>> H. Nikolaus Schaller (8):
>>>> drivers:input:tsc2007: add new common binding names, pre-calibration,
>>>>  flipping and rotation
>>>> drivers:input:tsc2007: check for presence and power down tsc2007
>>>>  during probe
>>>> DT:omap3+tsc2007: use new common touchscreen bindings
>>>> drivers:input:ads7846(+tsc2046): add new common binding names,
>>>>  pre-calibration and flipping
>>>> dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>>> drivers:input:ads7846(+tsc2046): fix spi module table
>>>> DT:omap3+ads7846: use new common touchscreen bindings
>>>> drivers:input:tsc2007: add iio interface to read external ADC input
>>>>  and temperature
>>>> 
>>>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>>>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>>>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>>>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>>>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>>>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>>>> drivers/input/touchscreen/Kconfig                  |  10 +
>>>> drivers/input/touchscreen/Makefile                 |   2 +
>>>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>>>> include/linux/i2c/tsc2007.h                        |   8 +
>>>> 13 files changed, 520 insertions(+), 114 deletions(-)
>>>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>> 
>>>> -- 
>>>> 2.7.3
>>>> 
>>> 
>> 
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel-S0jZdbWzriLCfDggNXIi3w@public.gmane.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

Re: [Letux-kernel] [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,
there have been no further comments/complaints about this patch series in the last month.
And it appears as if only your action is needed.

What is missing for this patch series to be finally accepted?

BR,
Nikolaus


> Am 21.01.2017 um 14:17 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> 
>> Am 21.01.2017 um 14:08 schrieb Jonathan Cameron <jic23@kernel.org>:
>> 
>> On 16/01/17 06:34, H. Nikolaus Schaller wrote:
>>> ping
>> Always good to say who you are pinging ;)
> 
> default = Maintainer
> 
> Only he/she can finally accept a patch series so I assume he has
> to take action if there are no more things to debate.
> 
>> Saves the rest of us wondering
>> if we have missing something we should have reviewed.
>> 
>> Guessing it's Dmitry in this case!
> 
> Yes, you are right. Since there have not been any more comments for a
> while, I formally ask to add this to some tree so that it appears in
> linux-next for further tests.
> 
> BR and thanks,
> Nikolaus
> 
>> 
>> Jonathan
>>> 
>>>> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> Changes V9:
>>>> * added explicit CONFIG for TSC2007_IIO and simplified Makefile (suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>)
>>>> * make the tsc2007 iio patch the last one in this sequence
>>>> 
>>>> 2016-11-22 15:02:42: Changes V8:
>>>> * fix compilation for CONFIG_IIO=m (reported by Jonathan Cameron <jic23@kernel.org>)
>>>> * add some more Reviewed-by: and Acked-by:
>>>> * mutiple improvements suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>> ** drop patch "send pendown and penup only once" (input core does take care of it now)
>>>> ** remove not necessary EXPORT_SYMBOL
>>>> ** remove explicit file names from comment header
>>>> ** move tsc2007_iio_configure() to the end of the probe process and simplify the error path again
>>>> ** remove unnecessary input_unregister_device() 
>>>> ** improvement for compilation with CONFIG_IIO=m and CONFIG_TSC2007=y
>>>> 
>>>> 2016-11-11 20:02:11: Changes V7:
>>>> * rearranged the include files (asked for by Jonathan Cameron <jic23@kernel.org>)
>>>> * forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23@kernel.org>)
>>>> * add some Acked-by:
>>>> 
>>>> 2016-10-27 10:44:29: Changes V6:
>>>> * iio patch (no changes elsewhere)
>>>> 	- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
>>>> 	- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
>>>> 	- tsc2007_iio: fix copyright (this file is 100% original work)
>>>> 
>>>> 2016-10-25 21:26:46: Changes V5:
>>>> * ads7846: remove an empty line (suggested by Andrew F. Davis <afd@ti.com>)
>>>> * ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd@ti.com>)
>>>> * tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
>>>> * refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23@kernel.org>)
>>>> 
>>>> 2016-10-17 16:00:02: Changes V4:
>>>> * fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
>>>> * remove some unnecessary #include (suggested by Jonathan Cameron <jic23@kernel.org>)
>>>> * make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23@kernel.org>)
>>>> * swapped patch 3/n and patch 4/n to remove internal dependency
>>>> 
>>>> 2016-09-23 14:41:23: Changes V3:
>>>> * fix an issue with swapping
>>>> * remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
>>>> * make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> 
>>>> 2015-11-13 21:36:07: Changes V2:
>>>> * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring)
>>>> 
>>>> 2015-11-06 16:14:53: V1: This patch series improves the drivers for the tsc2007 and
>>>> ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
>>>> OpenPandora and Pyra devices.
>>>> 
>>>> New common bindings have been defined by
>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
>>>> 
>>>> 	Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>>> 
>>>> which also defines a helper function to parse the DT. These new parameters
>>>> allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and
>>>> swapping of x and y to achieve inversion and rotation so that the touch
>>>> coordinate axes match the natural orientation of the display panel.
>>>> 
>>>> Another improvement is to better use the min/max ADC values and
>>>> scale to the screen size as defined by the DT. This allows to coarsely
>>>> calibrate the touch to match the LCD to which it is glued on so that the
>>>> touch can quite precisely be operated before any user-space fine-calibration
>>>> can be (and needs to be) started.
>>>> 
>>>> For the adc7846 we fix an issue with the spi module table.
>>>> 
>>>> Finally we add an iio interface for the AUX and temperature ADC channels of
>>>> the tsc2007 and also provide the touch screen raw values. This allows to read
>>>> an optional ambient light sensor installed on the gta04 board and improves
>>>> calibration and hardware monitoring.
>>>> 
>>>> 
>>>> H. Nikolaus Schaller (8):
>>>> drivers:input:tsc2007: add new common binding names, pre-calibration,
>>>>  flipping and rotation
>>>> drivers:input:tsc2007: check for presence and power down tsc2007
>>>>  during probe
>>>> DT:omap3+tsc2007: use new common touchscreen bindings
>>>> drivers:input:ads7846(+tsc2046): add new common binding names,
>>>>  pre-calibration and flipping
>>>> dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
>>>> drivers:input:ads7846(+tsc2046): fix spi module table
>>>> DT:omap3+ads7846: use new common touchscreen bindings
>>>> drivers:input:tsc2007: add iio interface to read external ADC input
>>>>  and temperature
>>>> 
>>>> .../bindings/input/{ => touchscreen}/ads7846.txt   |   9 +-
>>>> .../bindings/input/touchscreen/tsc2007.txt         |  20 +-
>>>> arch/arm/boot/dts/omap3-gta04.dtsi                 |  25 ++-
>>>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi            |   2 +-
>>>> arch/arm/boot/dts/omap3-pandora-common.dtsi        |  17 +-
>>>> .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi    |   3 +-
>>>> drivers/input/touchscreen/Kconfig                  |  10 +
>>>> drivers/input/touchscreen/Makefile                 |   2 +
>>>> drivers/input/touchscreen/ads7846.c                |  71 ++++++--
>>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++
>>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      | 201 ++++++++++++---------
>>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++
>>>> include/linux/i2c/tsc2007.h                        |   8 +
>>>> 13 files changed, 520 insertions(+), 114 deletions(-)
>>>> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
>>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (74%)
>>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>> 
>>>> -- 
>>>> 2.7.3
>>>> 
>>> 
>> 
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

Hi Nikolaus,

On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
> 
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
> 
> A new feature is to introduce scaling the min/max ADC values to the screen
> size.
> 
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> well enough operate the touch before a user space calibration step can
> improve the precision.

I question whether doing scaling in kernel is really right solution.

Why do you want this? If your touch resolution is lower than your screen
then it might be useful, but if it is lower then you are losing data
that can be very helpful for gesture recognition, and I hope you design
your userspace so it can handle not only "bad" hardware, but "good" as
well. And even with "bad" there are a lot of tricks that can be done to
get "better" touch position in userspace.

> 
> Please note that the old ti,fuzz properties have been removed since they
> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> 
> Finally, calculate_pressure has been renamed to calculate_resistance
> because that is what it is doing.

That is not what your patch does though. In the presence of
"ti,report-resistance" parameter you start reporting resistance through
ABS_PRESSURE without any indication to the userspace that meaning of
event changed. This is no better if than reporting it through ABS_X. You
should not override meaning of input events.

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

Hi Nikolaus,

On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> added another helper for parsing axis inversion and swapping
> and applying them to x and y coordinates.
> 
> Both helpers have been integrated to accommodate any orientation of the
> touch panel in relation to the LCD.
> 
> A new feature is to introduce scaling the min/max ADC values to the screen
> size.
> 
> This makes it possible to pre-calibrate the touch so that is (almost)
> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> well enough operate the touch before a user space calibration step can
> improve the precision.

I question whether doing scaling in kernel is really right solution.

Why do you want this? If your touch resolution is lower than your screen
then it might be useful, but if it is lower then you are losing data
that can be very helpful for gesture recognition, and I hope you design
your userspace so it can handle not only "bad" hardware, but "good" as
well. And even with "bad" there are a lot of tricks that can be done to
get "better" touch position in userspace.

> 
> Please note that the old ti,fuzz properties have been removed since they
> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> 
> Finally, calculate_pressure has been renamed to calculate_resistance
> because that is what it is doing.

That is not what your patch does though. In the presence of
"ti,report-resistance" parameter you start reporting resistance through
ABS_PRESSURE without any indication to the userspace that meaning of
event changed. This is no better if than reporting it through ABS_X. You
should not override meaning of input events.

Thanks.

-- 
Dmitry

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Dmitry Torokhov]

On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
> Fix module table so that the driver is loaded if compiled
> as module and requested by DT.
> 

I believe I already replied to a similar patch: we alreadyhave necessary
aliases in this driver, we need to fix module loading to use it.

Thanks.

-- 
Dmitry

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Dmitry Torokhov]

On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
> Fix module table so that the driver is loaded if compiled
> as module and requested by DT.
> 

I believe I already replied to a similar patch: we alreadyhave necessary
aliases in this driver, we need to fix module loading to use it.

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> Hi Nikolaus,
> 
> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>> introduced common DT bindings for touchscreens [1] and a helper function to
>> parse the DT.
>> 
>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>> added another helper for parsing axis inversion and swapping
>> and applying them to x and y coordinates.
>> 
>> Both helpers have been integrated to accommodate any orientation of the
>> touch panel in relation to the LCD.
>> 
>> A new feature is to introduce scaling the min/max ADC values to the screen
>> size.
>> 
>> This makes it possible to pre-calibrate the touch so that is (almost)
>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>> well enough operate the touch before a user space calibration step can
>> improve the precision.
> 
> I question whether doing scaling in kernel is really right solution.

Since lower left corner does not exactly report [0 0] and upper right corner
does not report [4095 4095] from the ADC we need offset and steepness correction
of the ADC values.

This steepness is the scaling that must happen in kernel and I don't understand
why you want to propagate this ADC errors to user-space by avoiding scaling.

Let me iterate what we want to achieve:
* use new common bindings
* offset and steepness calibration of the ADC (called pre-calibration).
  This makes a real device much more reliable to operate with factory installed
  scaling factors.
* flipping and rotation

(note that touch pixel to LCD pixel scaling is not explicitly on this list!)

Now to achieve the ADC pre-calibration we must calculate

	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0

This is scaled up to what is defined by touchscreen-size-x, i.e.

	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)

How do you want to avoid this scaling to take place? It happens automatically.
It is not even an additional line of code. And is necessary for compensating ADC
offsets and steepness.

So the only way to avoid the scaling option is to eliminate the precalibration/ADC
compensation which is essential for a device which has no means to properly
calibrate before operating the device through touch.

The other option would be to avoid common bindings and set

	touchscreen-size-x = (ti,max-x-ti,min-x)

This is heavily dependent on specific ADC offsets forwarded to user-space.
IMHO the worst we can do (and the current tsc2007 driver does it that way!).

> 
> Why do you want this?

It seems that you assume that we want to enforce 1:1 scaling between touch pixels
and LCD pixels and have designed code to achieve exactly that.

This is not the case. It is just a byproduct that you can do it.

And since it is easier to understand we have made the examples this way.

> If your touch resolution is lower than your screen
> then it might be useful, but if it is lower then you are losing data
> that can be very helpful for gesture recognition, and I hope you design
> your userspace so it can handle not only "bad" hardware, but "good" as
> well. And even with "bad" there are a lot of tricks that can be done to
> get "better" touch position in userspace.

You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
This of course reduces the touch precision to full LCD pixels. For finger-
touch operated devices, subpixel precision is rarely needed.

Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
such an 1:1 mapping and they will be perfectly happy about this. 

But, if you can modify your user-space easily, you can also choose a different
factor.

You can for example define touchscreen-size-x=<4096> and then you get almost
the highest precision of the ADC and won't loose any bits. Or even define a
bigger range and get steps >1 bit.

LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.

So effectively we get for LCD pixels when the touch sets a mouse pointer:

	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))

The most simple setup would then be but others are possible:

	user-space-scale = 1
	touchscreen-size-x = LCD-size-x

Let me cite myself:

>> This makes it possible to pre-calibrate the touch so that is (almost)


> 
>> 
>> Please note that the old ti,fuzz properties have been removed since they
>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>> 
>> Finally, calculate_pressure has been renamed to calculate_resistance
>> because that is what it is doing.
> 
> That is not what your patch does though. In the presence of
> "ti,report-resistance" parameter you start reporting resistance through
> ABS_PRESSURE

Well, there is some historic confusion wether this driver reports resistance
or pressure.

The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
the fly (because a separate patch is much more complex than doing it right
immediately).

This ti,report-resistance property is a means to get the old (wrong) meaning back
in case someone urgently needs it and can't fix the user-space workaround which
he must be using.

AFAIK there is no mainline board using the DT except ours (and the upcoming
OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
compatibility property. We don't need it for our devices.

That the function name is wrong is a second issue and this double negation might
confuse a litte.

Please test on a real device if the patched driver reports pressure now (unless
ti,report-resistance is specified).

> without any indication to the userspace that meaning of
> event changed. This is no better if than reporting it through ABS_X. You
> should not override meaning of input events.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> Hi Nikolaus,
> 
> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>> introduced common DT bindings for touchscreens [1] and a helper function to
>> parse the DT.
>> 
>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>> added another helper for parsing axis inversion and swapping
>> and applying them to x and y coordinates.
>> 
>> Both helpers have been integrated to accommodate any orientation of the
>> touch panel in relation to the LCD.
>> 
>> A new feature is to introduce scaling the min/max ADC values to the screen
>> size.
>> 
>> This makes it possible to pre-calibrate the touch so that is (almost)
>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>> well enough operate the touch before a user space calibration step can
>> improve the precision.
> 
> I question whether doing scaling in kernel is really right solution.

Since lower left corner does not exactly report [0 0] and upper right corner
does not report [4095 4095] from the ADC we need offset and steepness correction
of the ADC values.

This steepness is the scaling that must happen in kernel and I don't understand
why you want to propagate this ADC errors to user-space by avoiding scaling.

Let me iterate what we want to achieve:
* use new common bindings
* offset and steepness calibration of the ADC (called pre-calibration).
  This makes a real device much more reliable to operate with factory installed
  scaling factors.
* flipping and rotation

(note that touch pixel to LCD pixel scaling is not explicitly on this list!)

Now to achieve the ADC pre-calibration we must calculate

	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0

This is scaled up to what is defined by touchscreen-size-x, i.e.

	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)

How do you want to avoid this scaling to take place? It happens automatically.
It is not even an additional line of code. And is necessary for compensating ADC
offsets and steepness.

So the only way to avoid the scaling option is to eliminate the precalibration/ADC
compensation which is essential for a device which has no means to properly
calibrate before operating the device through touch.

The other option would be to avoid common bindings and set

	touchscreen-size-x = (ti,max-x-ti,min-x)

This is heavily dependent on specific ADC offsets forwarded to user-space.
IMHO the worst we can do (and the current tsc2007 driver does it that way!).

> 
> Why do you want this?

It seems that you assume that we want to enforce 1:1 scaling between touch pixels
and LCD pixels and have designed code to achieve exactly that.

This is not the case. It is just a byproduct that you can do it.

And since it is easier to understand we have made the examples this way.

> If your touch resolution is lower than your screen
> then it might be useful, but if it is lower then you are losing data
> that can be very helpful for gesture recognition, and I hope you design
> your userspace so it can handle not only "bad" hardware, but "good" as
> well. And even with "bad" there are a lot of tricks that can be done to
> get "better" touch position in userspace.

You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
This of course reduces the touch precision to full LCD pixels. For finger-
touch operated devices, subpixel precision is rarely needed.

Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
such an 1:1 mapping and they will be perfectly happy about this. 

But, if you can modify your user-space easily, you can also choose a different
factor.

You can for example define touchscreen-size-x=<4096> and then you get almost
the highest precision of the ADC and won't loose any bits. Or even define a
bigger range and get steps >1 bit.

LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.

So effectively we get for LCD pixels when the touch sets a mouse pointer:

	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))

The most simple setup would then be but others are possible:

	user-space-scale = 1
	touchscreen-size-x = LCD-size-x

Let me cite myself:

>> This makes it possible to pre-calibrate the touch so that is (almost)


> 
>> 
>> Please note that the old ti,fuzz properties have been removed since they
>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>> 
>> Finally, calculate_pressure has been renamed to calculate_resistance
>> because that is what it is doing.
> 
> That is not what your patch does though. In the presence of
> "ti,report-resistance" parameter you start reporting resistance through
> ABS_PRESSURE

Well, there is some historic confusion wether this driver reports resistance
or pressure.

The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
the fly (because a separate patch is much more complex than doing it right
immediately).

This ti,report-resistance property is a means to get the old (wrong) meaning back
in case someone urgently needs it and can't fix the user-space workaround which
he must be using.

AFAIK there is no mainline board using the DT except ours (and the upcoming
OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
compatibility property. We don't need it for our devices.

That the function name is wrong is a second issue and this double negation might
confuse a litte.

Please test on a real device if the patched driver reports pressure now (unless
ti,report-resistance is specified).

> without any indication to the userspace that meaning of
> event changed. This is no better if than reporting it through ABS_X. You
> should not override meaning of input events.

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> Hi Nikolaus,
>=20
> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>> introduced common DT bindings for touchscreens [1] and a helper =
function to
>> parse the DT.
>>=20
>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for =
inverted / swapped axes")
>> added another helper for parsing axis inversion and swapping
>> and applying them to x and y coordinates.
>>=20
>> Both helpers have been integrated to accommodate any orientation of =
the
>> touch panel in relation to the LCD.
>>=20
>> A new feature is to introduce scaling the min/max ADC values to the =
screen
>> size.
>>=20
>> This makes it possible to pre-calibrate the touch so that is (almost)
>> exactly matches the LCD pixel coordinates it is glued onto. This =
allows to
>> well enough operate the touch before a user space calibration step =
can
>> improve the precision.
>=20
> I question whether doing scaling in kernel is really right solution.

Since lower left corner does not exactly report [0 0] and upper right =
corner
does not report [4095 4095] from the ADC we need offset and steepness =
correction
of the ADC values.

This steepness is the scaling that must happen in kernel and I don't =
understand
why you want to propagate this ADC errors to user-space by avoiding =
scaling.

Let me iterate what we want to achieve:
* use new common bindings
* offset and steepness calibration of the ADC (called pre-calibration).
  This makes a real device much more reliable to operate with factory =
installed
  scaling factors.
* flipping and rotation

(note that touch pixel to LCD pixel scaling is not explicitly on this =
list!)

Now to achieve the ADC pre-calibration we must calculate

	x' =3D (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from =
0.0 ... 1.0

This is scaled up to what is defined by touchscreen-size-x, i.e.

	x' =3D (touchscreen-size-x * (x - ti,min-x)) / =
(ti,max-x-ti,min-x)

How do you want to avoid this scaling to take place? It happens =
automatically.
It is not even an additional line of code. And is necessary for =
compensating ADC
offsets and steepness.

So the only way to avoid the scaling option is to eliminate the =
precalibration/ADC
compensation which is essential for a device which has no means to =
properly
calibrate before operating the device through touch.

The other option would be to avoid common bindings and set

	touchscreen-size-x =3D (ti,max-x-ti,min-x)

This is heavily dependent on specific ADC offsets forwarded to =
user-space.
IMHO the worst we can do (and the current tsc2007 driver does it that =
way!).

>=20
> Why do you want this?

It seems that you assume that we want to enforce 1:1 scaling between =
touch pixels
and LCD pixels and have designed code to achieve exactly that.

This is not the case. It is just a byproduct that you can do it.

And since it is easier to understand we have made the examples this way.

> If your touch resolution is lower than your screen
> then it might be useful, but if it is lower then you are losing data
> that can be very helpful for gesture recognition, and I hope you =
design
> your userspace so it can handle not only "bad" hardware, but "good" as
> well. And even with "bad" there are a lot of tricks that can be done =
to
> get "better" touch position in userspace.

You can just *choose* DT parameters touchscreen-size-x to match the LCD =
size.
This of course reduces the touch precision to full LCD pixels. For =
finger-
touch operated devices, subpixel precision is rarely needed.

Also, some user-spaces (e.g. older Replicant for GTA04) assume that =
there is
such an 1:1 mapping and they will be perfectly happy about this.=20

But, if you can modify your user-space easily, you can also choose a =
different
factor.

You can for example define touchscreen-size-x=3D<4096> and then you get =
almost
the highest precision of the ADC and won't loose any bits. Or even =
define a
bigger range and get steps >1 bit.

LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD =
pixels.

So effectively we get for LCD pixels when the touch sets a mouse =
pointer:

	x'' =3D user-space-scale * <<input-event<< ((touchscreen-size-x =
* (x - ti,min-x)) / (ti,max-x-ti,min-x))

The most simple setup would then be but others are possible:

	user-space-scale =3D 1
	touchscreen-size-x =3D LCD-size-x

Let me cite myself:

>> This makes it possible to pre-calibrate the touch so that is (almost)


>=20
>>=20
>> Please note that the old ti,fuzz properties have been removed since =
they
>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>=20
>> Finally, calculate_pressure has been renamed to calculate_resistance
>> because that is what it is doing.
>=20
> That is not what your patch does though. In the presence of
> "ti,report-resistance" parameter you start reporting resistance =
through
> ABS_PRESSURE

Well, there is some historic confusion wether this driver reports =
resistance
or pressure.

The unpatched tsc2007 driver does it wrong (please test!) and we fix it =
on
the fly (because a separate patch is much more complex than doing it =
right
immediately).

This ti,report-resistance property is a means to get the old (wrong) =
meaning back
in case someone urgently needs it and can't fix the user-space =
workaround which
he must be using.

AFAIK there is no mainline board using the DT except ours (and the =
upcoming
OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can =
remove this
compatibility property. We don't need it for our devices.

That the function name is wrong is a second issue and this double =
negation might
confuse a litte.

Please test on a real device if the patched driver reports pressure now =
(unless
ti,report-resistance is specified).

> without any indication to the userspace that meaning of
> event changed. This is no better if than reporting it through ABS_X. =
You
> should not override meaning of input events.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>> Fix module table so that the driver is loaded if compiled
>> as module and requested by DT.
>> 
> 
> I believe I already replied to a similar patch: we alreadyhave necessary
> aliases in this driver, we need to fix module loading to use it.

Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):

>> We really need to fix it between spi/i23c core and module utils instead
>> of keeping adding duplicate IDs all over drivers. We already have OF
>> module device table containing the same data, we should be able to use
>> it.

And Javier Martinez Canillas replied (23 Nov 2016):

> Agreed, unfortunately until the I2C and SPI core are changed to properly
> report OF modaliases, we will have to keep adding these duplicated IDs.
> 
> And changing the I2C and SPI core isn't trivial since it could break a
> lot of drivers that rely on a platform modalias being reported (i.e: no
> OF device IDs present in the drivers even when are registered via DT).

Therefore I didn't see a need to change it.

BR,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>> Fix module table so that the driver is loaded if compiled
>> as module and requested by DT.
>> 
> 
> I believe I already replied to a similar patch: we alreadyhave necessary
> aliases in this driver, we need to fix module loading to use it.

Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):

>> We really need to fix it between spi/i23c core and module utils instead
>> of keeping adding duplicate IDs all over drivers. We already have OF
>> module device table containing the same data, we should be able to use
>> it.

And Javier Martinez Canillas replied (23 Nov 2016):

> Agreed, unfortunately until the I2C and SPI core are changed to properly
> report OF modaliases, we will have to keep adding these duplicated IDs.
> 
> And changing the I2C and SPI core isn't trivial since it could break a
> lot of drivers that rely on a platform modalias being reported (i.e: no
> OF device IDs present in the drivers even when are registered via DT).

Therefore I didn't see a need to change it.

BR,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Dmitry Torokhov]

On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
> >> Fix module table so that the driver is loaded if compiled
> >> as module and requested by DT.
> >> 
> > 
> > I believe I already replied to a similar patch: we alreadyhave necessary
> > aliases in this driver, we need to fix module loading to use it.
> 
> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
> 
> >> We really need to fix it between spi/i23c core and module utils instead
> >> of keeping adding duplicate IDs all over drivers. We already have OF
> >> module device table containing the same data, we should be able to use
> >> it.
> 
> And Javier Martinez Canillas replied (23 Nov 2016):
> 
> > Agreed, unfortunately until the I2C and SPI core are changed to properly
> > report OF modaliases, we will have to keep adding these duplicated IDs.
> > 
> > And changing the I2C and SPI core isn't trivial since it could break a
> > lot of drivers that rely on a platform modalias being reported (i.e: no
> > OF device IDs present in the drivers even when are registered via DT).
> 
> Therefore I didn't see a need to change it.

I agree that changing I2C and SPI core is not trivial, however this is
no reason for piling up workarounds in all drivers. Are you seriously
advocating going though *every* driver and copying OF data into I2C/SPI
instead of doing the right thing and fixing the root of the issue?

Thanks.

-- 
Dmitry

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Dmitry Torokhov]

On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
> >> Fix module table so that the driver is loaded if compiled
> >> as module and requested by DT.
> >> 
> > 
> > I believe I already replied to a similar patch: we alreadyhave necessary
> > aliases in this driver, we need to fix module loading to use it.
> 
> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
> 
> >> We really need to fix it between spi/i23c core and module utils instead
> >> of keeping adding duplicate IDs all over drivers. We already have OF
> >> module device table containing the same data, we should be able to use
> >> it.
> 
> And Javier Martinez Canillas replied (23 Nov 2016):
> 
> > Agreed, unfortunately until the I2C and SPI core are changed to properly
> > report OF modaliases, we will have to keep adding these duplicated IDs.
> > 
> > And changing the I2C and SPI core isn't trivial since it could break a
> > lot of drivers that rely on a platform modalias being reported (i.e: no
> > OF device IDs present in the drivers even when are registered via DT).
> 
> Therefore I didn't see a need to change it.

I agree that changing I2C and SPI core is not trivial, however this is
no reason for piling up workarounds in all drivers. Are you seriously
advocating going though *every* driver and copying OF data into I2C/SPI
instead of doing the right thing and fixing the root of the issue?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> 
>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>> Fix module table so that the driver is loaded if compiled
>>>> as module and requested by DT.
>>>> 
>>> 
>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>> aliases in this driver, we need to fix module loading to use it.
>> 
>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>> 
>>>> We really need to fix it between spi/i23c core and module utils instead
>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>> module device table containing the same data, we should be able to use
>>>> it.
>> 
>> And Javier Martinez Canillas replied (23 Nov 2016):
>> 
>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>> 
>>> And changing the I2C and SPI core isn't trivial since it could break a
>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>> OF device IDs present in the drivers even when are registered via DT).
>> 
>> Therefore I didn't see a need to change it.
> 
> I agree that changing I2C and SPI core is not trivial, however this is
> no reason for piling up workarounds in all drivers. Are you seriously
> advocating going though *every* driver and copying OF data into I2C/SPI
> instead of doing the right thing and fixing the root of the issue?

If you prefer to have this done (and I agree it would be a tiny improvement),
please do it for us all. But please after merging this workaround.

I can't do it since I have no idea how to and as you say it is non-trivial.
I am just a poor driver developer who has to use what he finds in core APIs
but has the task to make the driver work and be accepted upstream.

What I don't like is if core development tasks are piggybacked on top of a
driver patch series and used as argument against acceptance of the driver
patch. IMHO, the core developers should have the task to clean up such
workarounds after developing a modification for core and it seems to be
common practise in other subsystems if you follow what Linus is merging
every week.

Anyways, it piles up only in code. If you do not CONFIG the driver it does
not even matter that there are 10 more source code lines. And they are
factored out into a clean patch 6/8 that can easily be reverted.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> 
>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>> Fix module table so that the driver is loaded if compiled
>>>> as module and requested by DT.
>>>> 
>>> 
>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>> aliases in this driver, we need to fix module loading to use it.
>> 
>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>> 
>>>> We really need to fix it between spi/i23c core and module utils instead
>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>> module device table containing the same data, we should be able to use
>>>> it.
>> 
>> And Javier Martinez Canillas replied (23 Nov 2016):
>> 
>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>> 
>>> And changing the I2C and SPI core isn't trivial since it could break a
>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>> OF device IDs present in the drivers even when are registered via DT).
>> 
>> Therefore I didn't see a need to change it.
> 
> I agree that changing I2C and SPI core is not trivial, however this is
> no reason for piling up workarounds in all drivers. Are you seriously
> advocating going though *every* driver and copying OF data into I2C/SPI
> instead of doing the right thing and fixing the root of the issue?

If you prefer to have this done (and I agree it would be a tiny improvement),
please do it for us all. But please after merging this workaround.

I can't do it since I have no idea how to and as you say it is non-trivial.
I am just a poor driver developer who has to use what he finds in core APIs
but has the task to make the driver work and be accepted upstream.

What I don't like is if core development tasks are piggybacked on top of a
driver patch series and used as argument against acceptance of the driver
patch. IMHO, the core developers should have the task to clean up such
workarounds after developing a modification for core and it seems to be
common practise in other subsystems if you follow what Linus is merging
every week.

Anyways, it piles up only in code. If you do not CONFIG the driver it does
not even matter that there are 10 more source code lines. And they are
factored out into a clean patch 6/8 that can easily be reverted.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>=20
>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>=20
>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller =
wrote:
>>>> Fix module table so that the driver is loaded if compiled
>>>> as module and requested by DT.
>>>>=20
>>>=20
>>> I believe I already replied to a similar patch: we alreadyhave =
necessary
>>> aliases in this driver, we need to fix module loading to use it.
>>=20
>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>=20
>>>> We really need to fix it between spi/i23c core and module utils =
instead
>>>> of keeping adding duplicate IDs all over drivers. We already have =
OF
>>>> module device table containing the same data, we should be able to =
use
>>>> it.
>>=20
>> And Javier Martinez Canillas replied (23 Nov 2016):
>>=20
>>> Agreed, unfortunately until the I2C and SPI core are changed to =
properly
>>> report OF modaliases, we will have to keep adding these duplicated =
IDs.
>>>=20
>>> And changing the I2C and SPI core isn't trivial since it could break =
a
>>> lot of drivers that rely on a platform modalias being reported (i.e: =
no
>>> OF device IDs present in the drivers even when are registered via =
DT).
>>=20
>> Therefore I didn't see a need to change it.
>=20
> I agree that changing I2C and SPI core is not trivial, however this is
> no reason for piling up workarounds in all drivers. Are you seriously
> advocating going though *every* driver and copying OF data into =
I2C/SPI
> instead of doing the right thing and fixing the root of the issue?

If you prefer to have this done (and I agree it would be a tiny =
improvement),
please do it for us all. But please after merging this workaround.

I can't do it since I have no idea how to and as you say it is =
non-trivial.
I am just a poor driver developer who has to use what he finds in core =
APIs
but has the task to make the driver work and be accepted upstream.

What I don't like is if core development tasks are piggybacked on top of =
a
driver patch series and used as argument against acceptance of the =
driver
patch. IMHO, the core developers should have the task to clean up such
workarounds after developing a modification for core and it seems to be
common practise in other subsystems if you follow what Linus is merging
every week.

Anyways, it piles up only in code. If you do not CONFIG the driver it =
does
not even matter that there are 10 more source code lines. And they are
factored out into a clean patch 6/8 that can easily be reverted.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry, Javier,

> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Dmitry,
> 
>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> 
>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>> 
>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>> Fix module table so that the driver is loaded if compiled
>>>>> as module and requested by DT.
>>>>> 
>>>> 
>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>> aliases in this driver, we need to fix module loading to use it.
>>> 
>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>> 
>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>> module device table containing the same data, we should be able to use
>>>>> it.
>>> 
>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>> 
>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>> 
>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>> OF device IDs present in the drivers even when are registered via DT).
>>> 
>>> Therefore I didn't see a need to change it.
>> 
>> I agree that changing I2C and SPI core is not trivial, however this is
>> no reason for piling up workarounds in all drivers. Are you seriously
>> advocating going though *every* driver and copying OF data into I2C/SPI
>> instead of doing the right thing and fixing the root of the issue?
> 
> If you prefer to have this done (and I agree it would be a tiny improvement),
> please do it for us all. But please after merging this workaround.

Have we been lucky to find someone who is able and willing to work on this?

If not, I'd recommend to stay with the current level of optimality.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry, Javier,

> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Dmitry,
> 
>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> 
>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>> 
>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>> Fix module table so that the driver is loaded if compiled
>>>>> as module and requested by DT.
>>>>> 
>>>> 
>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>> aliases in this driver, we need to fix module loading to use it.
>>> 
>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>> 
>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>> module device table containing the same data, we should be able to use
>>>>> it.
>>> 
>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>> 
>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>> 
>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>> OF device IDs present in the drivers even when are registered via DT).
>>> 
>>> Therefore I didn't see a need to change it.
>> 
>> I agree that changing I2C and SPI core is not trivial, however this is
>> no reason for piling up workarounds in all drivers. Are you seriously
>> advocating going though *every* driver and copying OF data into I2C/SPI
>> instead of doing the right thing and fixing the root of the issue?
> 
> If you prefer to have this done (and I agree it would be a tiny improvement),
> please do it for us all. But please after merging this workaround.

Have we been lucky to find someone who is able and willing to work on this?

If not, I'd recommend to stay with the current level of optimality.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi Dmitry, Javier,

> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>=20
> Hi Dmitry,
>=20
>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>=20
>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>>=20
>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>>=20
>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller =
wrote:
>>>>> Fix module table so that the driver is loaded if compiled
>>>>> as module and requested by DT.
>>>>>=20
>>>>=20
>>>> I believe I already replied to a similar patch: we alreadyhave =
necessary
>>>> aliases in this driver, we need to fix module loading to use it.
>>>=20
>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>>=20
>>>>> We really need to fix it between spi/i23c core and module utils =
instead
>>>>> of keeping adding duplicate IDs all over drivers. We already have =
OF
>>>>> module device table containing the same data, we should be able to =
use
>>>>> it.
>>>=20
>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>>=20
>>>> Agreed, unfortunately until the I2C and SPI core are changed to =
properly
>>>> report OF modaliases, we will have to keep adding these duplicated =
IDs.
>>>>=20
>>>> And changing the I2C and SPI core isn't trivial since it could =
break a
>>>> lot of drivers that rely on a platform modalias being reported =
(i.e: no
>>>> OF device IDs present in the drivers even when are registered via =
DT).
>>>=20
>>> Therefore I didn't see a need to change it.
>>=20
>> I agree that changing I2C and SPI core is not trivial, however this =
is
>> no reason for piling up workarounds in all drivers. Are you seriously
>> advocating going though *every* driver and copying OF data into =
I2C/SPI
>> instead of doing the right thing and fixing the root of the issue?
>=20
> If you prefer to have this done (and I agree it would be a tiny =
improvement),
> please do it for us all. But please after merging this workaround.

Have we been lucky to find someone who is able and willing to work on =
this?

If not, I'd recommend to stay with the current level of optimality.

BR and thanks,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Javier Martinez Canillas]

Hello Nikolaus,

On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
> Hi Dmitry, Javier,
> 
>> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>
>> Hi Dmitry,
>>
>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>
>>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>>
>>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>>
>>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>>> Fix module table so that the driver is loaded if compiled
>>>>>> as module and requested by DT.
>>>>>>
>>>>>
>>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>>> aliases in this driver, we need to fix module loading to use it.
>>>>
>>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>>>
>>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>>> module device table containing the same data, we should be able to use
>>>>>> it.
>>>>
>>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>>>
>>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>>>
>>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>>> OF device IDs present in the drivers even when are registered via DT).
>>>>
>>>> Therefore I didn't see a need to change it.
>>>
>>> I agree that changing I2C and SPI core is not trivial, however this is
>>> no reason for piling up workarounds in all drivers. Are you seriously
>>> advocating going though *every* driver and copying OF data into I2C/SPI
>>> instead of doing the right thing and fixing the root of the issue?
>>
>> If you prefer to have this done (and I agree it would be a tiny improvement),
>> please do it for us all. But please after merging this workaround.
> 
> Have we been lucky to find someone who is able and willing to work on this?
>

As said, changing the core is trivial. A RFC patch is [0].

The problem is how to make sure that this change won't cause regressions
in existing drivers.

There was particularly tricky for the spi-nor driver, it doesn't help that
a lot of DT are using undocumented compatible strings (sometimes with no
vendor prefix). You can see the discussion here [1].

In the same thread Mark Brown said that it wasn't that bad to have the
information in the OF device ID table duplicated in a SPI device table.

Certainly isn't the best approach but IMHO is better than the module not
loading.

https://patchwork.kernel.org/patch/7041141/
https://patchwork.ozlabs.org/patch/545125/
 
> If not, I'd recommend to stay with the current level of optimality.
> 
> BR and thanks,
> Nikolaus
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Javier Martinez Canillas]

Hello Nikolaus,

On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
> Hi Dmitry, Javier,
> 
>> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>
>> Hi Dmitry,
>>
>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>
>>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>>
>>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>>
>>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>>> Fix module table so that the driver is loaded if compiled
>>>>>> as module and requested by DT.
>>>>>>
>>>>>
>>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>>> aliases in this driver, we need to fix module loading to use it.
>>>>
>>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>>>
>>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>>> module device table containing the same data, we should be able to use
>>>>>> it.
>>>>
>>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>>>
>>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>>>
>>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>>> OF device IDs present in the drivers even when are registered via DT).
>>>>
>>>> Therefore I didn't see a need to change it.
>>>
>>> I agree that changing I2C and SPI core is not trivial, however this is
>>> no reason for piling up workarounds in all drivers. Are you seriously
>>> advocating going though *every* driver and copying OF data into I2C/SPI
>>> instead of doing the right thing and fixing the root of the issue?
>>
>> If you prefer to have this done (and I agree it would be a tiny improvement),
>> please do it for us all. But please after merging this workaround.
> 
> Have we been lucky to find someone who is able and willing to work on this?
>

As said, changing the core is trivial. A RFC patch is [0].

The problem is how to make sure that this change won't cause regressions
in existing drivers.

There was particularly tricky for the spi-nor driver, it doesn't help that
a lot of DT are using undocumented compatible strings (sometimes with no
vendor prefix). You can see the discussion here [1].

In the same thread Mark Brown said that it wasn't that bad to have the
information in the OF device ID table duplicated in a SPI device table.

Certainly isn't the best approach but IMHO is better than the module not
loading.

https://patchwork.kernel.org/patch/7041141/
https://patchwork.ozlabs.org/patch/545125/
 
> If not, I'd recommend to stay with the current level of optimality.
> 
> BR and thanks,
> Nikolaus
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Dmitry Torokhov]

On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:
> Hello Nikolaus,
> 
> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
> > Hi Dmitry, Javier,
> > 
> >> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >>
> >> Hi Dmitry,
> >>
> >>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >>>
> >>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
> >>>> Hi Dmitry,
> >>>>
> >>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >>>>>
> >>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
> >>>>>> Fix module table so that the driver is loaded if compiled
> >>>>>> as module and requested by DT.
> >>>>>>
> >>>>>
> >>>>> I believe I already replied to a similar patch: we alreadyhave necessary
> >>>>> aliases in this driver, we need to fix module loading to use it.
> >>>>
> >>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
> >>>>
> >>>>>> We really need to fix it between spi/i23c core and module utils instead
> >>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
> >>>>>> module device table containing the same data, we should be able to use
> >>>>>> it.
> >>>>
> >>>> And Javier Martinez Canillas replied (23 Nov 2016):
> >>>>
> >>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
> >>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
> >>>>>
> >>>>> And changing the I2C and SPI core isn't trivial since it could break a
> >>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
> >>>>> OF device IDs present in the drivers even when are registered via DT).
> >>>>
> >>>> Therefore I didn't see a need to change it.
> >>>
> >>> I agree that changing I2C and SPI core is not trivial, however this is
> >>> no reason for piling up workarounds in all drivers. Are you seriously
> >>> advocating going though *every* driver and copying OF data into I2C/SPI
> >>> instead of doing the right thing and fixing the root of the issue?
> >>
> >> If you prefer to have this done (and I agree it would be a tiny improvement),
> >> please do it for us all. But please after merging this workaround.
> > 
> > Have we been lucky to find someone who is able and willing to work on this?
> >
> 
> As said, changing the core is trivial. A RFC patch is [0].
> 
> The problem is how to make sure that this change won't cause regressions
> in existing drivers.

If the concern with drivers having I2C or SPI device table, but not OF
device table, then I think cocinnelle could be used to scan and find
them.

> 
> There was particularly tricky for the spi-nor driver, it doesn't help that
> a lot of DT are using undocumented compatible strings (sometimes with no
> vendor prefix). You can see the discussion here [1].
> 
> In the same thread Mark Brown said that it wasn't that bad to have the
> information in the OF device ID table duplicated in a SPI device table.
> 
> Certainly isn't the best approach but IMHO is better than the module not
> loading.

You can always build the module into kernel or load it by hand if it is
that important. Module autoloading does not work anyway if you have
several compatible strings, like

	compatible = "vendor,new-device", "vendor,generic-device";

Thanks.

-- 
Dmitry

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Dmitry Torokhov]

On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:
> Hello Nikolaus,
> 
> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
> > Hi Dmitry, Javier,
> > 
> >> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> >>
> >> Hi Dmitry,
> >>
> >>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>>
> >>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
> >>>> Hi Dmitry,
> >>>>
> >>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>>>>
> >>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
> >>>>>> Fix module table so that the driver is loaded if compiled
> >>>>>> as module and requested by DT.
> >>>>>>
> >>>>>
> >>>>> I believe I already replied to a similar patch: we alreadyhave necessary
> >>>>> aliases in this driver, we need to fix module loading to use it.
> >>>>
> >>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
> >>>>
> >>>>>> We really need to fix it between spi/i23c core and module utils instead
> >>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
> >>>>>> module device table containing the same data, we should be able to use
> >>>>>> it.
> >>>>
> >>>> And Javier Martinez Canillas replied (23 Nov 2016):
> >>>>
> >>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
> >>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
> >>>>>
> >>>>> And changing the I2C and SPI core isn't trivial since it could break a
> >>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
> >>>>> OF device IDs present in the drivers even when are registered via DT).
> >>>>
> >>>> Therefore I didn't see a need to change it.
> >>>
> >>> I agree that changing I2C and SPI core is not trivial, however this is
> >>> no reason for piling up workarounds in all drivers. Are you seriously
> >>> advocating going though *every* driver and copying OF data into I2C/SPI
> >>> instead of doing the right thing and fixing the root of the issue?
> >>
> >> If you prefer to have this done (and I agree it would be a tiny improvement),
> >> please do it for us all. But please after merging this workaround.
> > 
> > Have we been lucky to find someone who is able and willing to work on this?
> >
> 
> As said, changing the core is trivial. A RFC patch is [0].
> 
> The problem is how to make sure that this change won't cause regressions
> in existing drivers.

If the concern with drivers having I2C or SPI device table, but not OF
device table, then I think cocinnelle could be used to scan and find
them.

> 
> There was particularly tricky for the spi-nor driver, it doesn't help that
> a lot of DT are using undocumented compatible strings (sometimes with no
> vendor prefix). You can see the discussion here [1].
> 
> In the same thread Mark Brown said that it wasn't that bad to have the
> information in the OF device ID table duplicated in a SPI device table.
> 
> Certainly isn't the best approach but IMHO is better than the module not
> loading.

You can always build the module into kernel or load it by hand if it is
that important. Module autoloading does not work anyway if you have
several compatible strings, like

	compatible = "vendor,new-device", "vendor,generic-device";

Thanks.

-- 
Dmitry

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Javier Martinez Canillas]

Hello Dmitry,

On 02/01/2017 07:28 PM, Dmitry Torokhov wrote:

[snip]

>>
>> As said, changing the core is trivial. A RFC patch is [0].
>>
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
>

I don't think coccinelle is a good fit for this since you may have to look if
a DTS is using in its compatible string a device that's in an SPI table or if
a DT binding documents this device as a compatible string.

But yes I get your point and I agree that is just a matter of having a script
to look for these. Someone should have the time to write it though :)

>>
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>>
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>>
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important. Module autoloading does not work anyway if you have
> several compatible strings, like
> 
> 	compatible = "vendor,new-device", "vendor,generic-device";
> 
> Thanks.
>

Agree.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[Javier Martinez Canillas]

Hello Dmitry,

On 02/01/2017 07:28 PM, Dmitry Torokhov wrote:

[snip]

>>
>> As said, changing the core is trivial. A RFC patch is [0].
>>
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
>

I don't think coccinelle is a good fit for this since you may have to look if
a DTS is using in its compatible string a device that's in an SPI table or if
a DT binding documents this device as a compatible string.

But yes I get your point and I agree that is just a matter of having a script
to look for these. Someone should have the time to write it though :)

>>
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>>
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>>
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important. Module autoloading does not work anyway if you have
> several compatible strings, like
> 
> 	compatible = "vendor,new-device", "vendor,generic-device";
> 
> Thanks.
>

Agree.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi,

> Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:
>> Hello Nikolaus,
>> 
>> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
>>> Hi Dmitry, Javier,
>>> 
>>>> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> Hi Dmitry,
>>>> 
>>>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>> 
>>>>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>> 
>>>>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>>>> 
>>>>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>>>>> Fix module table so that the driver is loaded if compiled
>>>>>>>> as module and requested by DT.
>>>>>>>> 
>>>>>>> 
>>>>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>>>>> aliases in this driver, we need to fix module loading to use it.
>>>>>> 
>>>>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>>>>> 
>>>>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>>>>> module device table containing the same data, we should be able to use
>>>>>>>> it.
>>>>>> 
>>>>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>>>>> 
>>>>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>>>>> 
>>>>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>>>>> OF device IDs present in the drivers even when are registered via DT).
>>>>>> 
>>>>>> Therefore I didn't see a need to change it.
>>>>> 
>>>>> I agree that changing I2C and SPI core is not trivial, however this is
>>>>> no reason for piling up workarounds in all drivers. Are you seriously
>>>>> advocating going though *every* driver and copying OF data into I2C/SPI
>>>>> instead of doing the right thing and fixing the root of the issue?
>>>> 
>>>> If you prefer to have this done (and I agree it would be a tiny improvement),
>>>> please do it for us all. But please after merging this workaround.
>>> 
>>> Have we been lucky to find someone who is able and willing to work on this?
>>> 
>> 
>> As said, changing the core is trivial. A RFC patch is [0].
>> 
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
> 
>> 
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>> 
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>> 
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important.

Well, it is the only exception on the OpenPandora that does NOT yet load
automatically from the DT.

And sure we can always find a hack or workaround in user-space for everything
the kernel isn't doing well.

> Module autoloading does not work anyway if you have
> several compatible strings, like
> 
> 	compatible = "vendor,new-device", "vendor,generic-device";

We don't use that mechanism here since there is only one ads7846 installed
and it won't change.

BR,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi,

> Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:
>> Hello Nikolaus,
>> 
>> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
>>> Hi Dmitry, Javier,
>>> 
>>>> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> Hi Dmitry,
>>>> 
>>>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>> 
>>>>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>> 
>>>>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>>>> 
>>>>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>>>>> Fix module table so that the driver is loaded if compiled
>>>>>>>> as module and requested by DT.
>>>>>>>> 
>>>>>>> 
>>>>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>>>>> aliases in this driver, we need to fix module loading to use it.
>>>>>> 
>>>>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>>>>> 
>>>>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>>>>> module device table containing the same data, we should be able to use
>>>>>>>> it.
>>>>>> 
>>>>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>>>>> 
>>>>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>>>>> 
>>>>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>>>>> OF device IDs present in the drivers even when are registered via DT).
>>>>>> 
>>>>>> Therefore I didn't see a need to change it.
>>>>> 
>>>>> I agree that changing I2C and SPI core is not trivial, however this is
>>>>> no reason for piling up workarounds in all drivers. Are you seriously
>>>>> advocating going though *every* driver and copying OF data into I2C/SPI
>>>>> instead of doing the right thing and fixing the root of the issue?
>>>> 
>>>> If you prefer to have this done (and I agree it would be a tiny improvement),
>>>> please do it for us all. But please after merging this workaround.
>>> 
>>> Have we been lucky to find someone who is able and willing to work on this?
>>> 
>> 
>> As said, changing the core is trivial. A RFC patch is [0].
>> 
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
> 
>> 
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>> 
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>> 
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important.

Well, it is the only exception on the OpenPandora that does NOT yet load
automatically from the DT.

And sure we can always find a hack or workaround in user-space for everything
the kernel isn't doing well.

> Module autoloading does not work anyway if you have
> several compatible strings, like
> 
> 	compatible = "vendor,new-device", "vendor,generic-device";

We don't use that mechanism here since there is only one ads7846 installed
and it won't change.

BR,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi,

> Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas =
wrote:
>> Hello Nikolaus,
>>=20
>> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
>>> Hi Dmitry, Javier,
>>>=20
>>>> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>>>>=20
>>>> Hi Dmitry,
>>>>=20
>>>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>>>=20
>>>>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller =
wrote:
>>>>>> Hi Dmitry,
>>>>>>=20
>>>>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>>>>>=20
>>>>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller =
wrote:
>>>>>>>> Fix module table so that the driver is loaded if compiled
>>>>>>>> as module and requested by DT.
>>>>>>>>=20
>>>>>>>=20
>>>>>>> I believe I already replied to a similar patch: we alreadyhave =
necessary
>>>>>>> aliases in this driver, we need to fix module loading to use it.
>>>>>>=20
>>>>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>>>>>=20
>>>>>>>> We really need to fix it between spi/i23c core and module utils =
instead
>>>>>>>> of keeping adding duplicate IDs all over drivers. We already =
have OF
>>>>>>>> module device table containing the same data, we should be able =
to use
>>>>>>>> it.
>>>>>>=20
>>>>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>>>>>=20
>>>>>>> Agreed, unfortunately until the I2C and SPI core are changed to =
properly
>>>>>>> report OF modaliases, we will have to keep adding these =
duplicated IDs.
>>>>>>>=20
>>>>>>> And changing the I2C and SPI core isn't trivial since it could =
break a
>>>>>>> lot of drivers that rely on a platform modalias being reported =
(i.e: no
>>>>>>> OF device IDs present in the drivers even when are registered =
via DT).
>>>>>>=20
>>>>>> Therefore I didn't see a need to change it.
>>>>>=20
>>>>> I agree that changing I2C and SPI core is not trivial, however =
this is
>>>>> no reason for piling up workarounds in all drivers. Are you =
seriously
>>>>> advocating going though *every* driver and copying OF data into =
I2C/SPI
>>>>> instead of doing the right thing and fixing the root of the issue?
>>>>=20
>>>> If you prefer to have this done (and I agree it would be a tiny =
improvement),
>>>> please do it for us all. But please after merging this workaround.
>>>=20
>>> Have we been lucky to find someone who is able and willing to work =
on this?
>>>=20
>>=20
>> As said, changing the core is trivial. A RFC patch is [0].
>>=20
>> The problem is how to make sure that this change won't cause =
regressions
>> in existing drivers.
>=20
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
>=20
>>=20
>> There was particularly tricky for the spi-nor driver, it doesn't help =
that
>> a lot of DT are using undocumented compatible strings (sometimes with =
no
>> vendor prefix). You can see the discussion here [1].
>>=20
>> In the same thread Mark Brown said that it wasn't that bad to have =
the
>> information in the OF device ID table duplicated in a SPI device =
table.
>>=20
>> Certainly isn't the best approach but IMHO is better than the module =
not
>> loading.
>=20
> You can always build the module into kernel or load it by hand if it =
is
> that important.

Well, it is the only exception on the OpenPandora that does NOT yet load
automatically from the DT.

And sure we can always find a hack or workaround in user-space for =
everything
the kernel isn't doing well.

> Module autoloading does not work anyway if you have
> several compatible strings, like
>=20
> 	compatible =3D "vendor,new-device", "vendor,generic-device";

We don't use that mechanism here since there is only one ads7846 =
installed
and it won't change.

BR,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Dmitry,
> there have been no further comments/complaints about this patch series in the last month.
> And it appears as if only your action is needed.
> 
> What is missing for this patch series to be finally accepted?

Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?

Is there anything open which prohibits inclusion to (and further testing within) linux/next?

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Dmitry,
> there have been no further comments/complaints about this patch series in the last month.
> And it appears as if only your action is needed.
> 
> What is missing for this patch series to be finally accepted?

Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?

Is there anything open which prohibits inclusion to (and further testing within) linux/next?

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>=20
> Hi Dmitry,
> there have been no further comments/complaints about this patch series =
in the last month.
> And it appears as if only your action is needed.
>=20
> What is missing for this patch series to be finally accepted?

Did you find time to look into my comment on patch 1/9 and make a =
decision on patch 6/8?

Is there anything open which prohibits inclusion to (and further testing =
within) linux/next?

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Dmitry,
> 
>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>> 
>> Hi Dmitry,
>> there have been no further comments/complaints about this patch series in the last month.
>> And it appears as if only your action is needed.
>> 
>> What is missing for this patch series to be finally accepted?
> 
> Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
> 
> Is there anything open which prohibits inclusion to (and further testing within) linux/next?

May I ask a question for my fundamental understanding of the Linux integration process.
Maybe, I have a wrong expectation which you can clarify.

My question is how it does come that patches like

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14

appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
and there have been no further comments from the community for weeks?

What is still missing what we can do or provide as information?

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> 
> Hi Dmitry,
> 
>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>> 
>> Hi Dmitry,
>> there have been no further comments/complaints about this patch series in the last month.
>> And it appears as if only your action is needed.
>> 
>> What is missing for this patch series to be finally accepted?
> 
> Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
> 
> Is there anything open which prohibits inclusion to (and further testing within) linux/next?

May I ask a question for my fundamental understanding of the Linux integration process.
Maybe, I have a wrong expectation which you can clarify.

My question is how it does come that patches like

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14

appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
and there have been no further comments from the community for weeks?

What is still missing what we can do or provide as information?

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>=20
> Hi Dmitry,
>=20
>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>>=20
>> Hi Dmitry,
>> there have been no further comments/complaints about this patch =
series in the last month.
>> And it appears as if only your action is needed.
>>=20
>> What is missing for this patch series to be finally accepted?
>=20
> Did you find time to look into my comment on patch 1/9 and make a =
decision on patch 6/8?
>=20
> Is there anything open which prohibits inclusion to (and further =
testing within) linux/next?

May I ask a question for my fundamental understanding of the Linux =
integration process.
Maybe, I have a wrong expectation which you can clarify.

My question is how it does come that patches like

=
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?i=
d=3D449aa83e69ff10d77fe088eadacafe1e97937c14

appear within 2 days in linux-next, but our patch series had months of =
review (we are at v9)
and there have been no further comments from the community for weeks?

What is still missing what we can do or provide as information?

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

Hi Nikolaus,

On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > Hi Nikolaus,
> > 
> > On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> >> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> >> introduced common DT bindings for touchscreens [1] and a helper function to
> >> parse the DT.
> >> 
> >> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> >> added another helper for parsing axis inversion and swapping
> >> and applying them to x and y coordinates.
> >> 
> >> Both helpers have been integrated to accommodate any orientation of the
> >> touch panel in relation to the LCD.
> >> 
> >> A new feature is to introduce scaling the min/max ADC values to the screen
> >> size.
> >> 
> >> This makes it possible to pre-calibrate the touch so that is (almost)
> >> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> >> well enough operate the touch before a user space calibration step can
> >> improve the precision.
> > 
> > I question whether doing scaling in kernel is really right solution.
> 
> Since lower left corner does not exactly report [0 0] and upper right corner
> does not report [4095 4095] from the ADC we need offset and steepness correction
> of the ADC values.
> 
> This steepness is the scaling that must happen in kernel and I don't understand
> why you want to propagate this ADC errors to user-space by avoiding scaling.
> 
> Let me iterate what we want to achieve:
> * use new common bindings
> * offset and steepness calibration of the ADC (called pre-calibration).
>   This makes a real device much more reliable to operate with factory installed
>   scaling factors.
> * flipping and rotation
> 
> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)

That was explicitly called out in the patch:

"A new feature is to introduce scaling the min/max ADC values to the
screen size."

> 
> Now to achieve the ADC pre-calibration we must calculate
> 
> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
> 
> This is scaled up to what is defined by touchscreen-size-x, i.e.
> 
> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
> 
> How do you want to avoid this scaling to take place? It happens automatically.
> It is not even an additional line of code. And is necessary for compensating ADC
> offsets and steepness.
> 
> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
> compensation which is essential for a device which has no means to properly
> calibrate before operating the device through touch.
> 
> The other option would be to avoid common bindings and set
> 
> 	touchscreen-size-x = (ti,max-x-ti,min-x)
> 
> This is heavily dependent on specific ADC offsets forwarded to user-space.
> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
> 
> > 
> > Why do you want this?
> 
> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
> and LCD pixels and have designed code to achieve exactly that.
> 
> This is not the case. It is just a byproduct that you can do it.
> 
> And since it is easier to understand we have made the examples this way.
> 
> > If your touch resolution is lower than your screen
> > then it might be useful, but if it is lower then you are losing data
> > that can be very helpful for gesture recognition, and I hope you design
> > your userspace so it can handle not only "bad" hardware, but "good" as
> > well. And even with "bad" there are a lot of tricks that can be done to
> > get "better" touch position in userspace.
> 
> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
> This of course reduces the touch precision to full LCD pixels. For finger-
> touch operated devices, subpixel precision is rarely needed.
> 
> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
> such an 1:1 mapping and they will be perfectly happy about this. 
> 
> But, if you can modify your user-space easily, you can also choose a different
> factor.
> 
> You can for example define touchscreen-size-x=<4096> and then you get almost
> the highest precision of the ADC and won't loose any bits. Or even define a
> bigger range and get steps >1 bit.
> 
> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
> 
> So effectively we get for LCD pixels when the touch sets a mouse pointer:
> 
> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
> 
> The most simple setup would then be but others are possible:
> 
> 	user-space-scale = 1
> 	touchscreen-size-x = LCD-size-x
> 
> Let me cite myself:
> 
> >> This makes it possible to pre-calibrate the touch so that is (almost)

Yes, it allows you to pre-calibrate, I get it. But you still do properly
calibrate later, right? So you are doing double work here, once in
kernel, and second time in userspace.

I'd be more open to allowing setting the "min-axis" values to allow
reporting typical range for given device, and let userspace scale as it
sees fit.

> 
> > 
> >> 
> >> Please note that the old ti,fuzz properties have been removed since they
> >> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> >> 
> >> Finally, calculate_pressure has been renamed to calculate_resistance
> >> because that is what it is doing.
> > 
> > That is not what your patch does though. In the presence of
> > "ti,report-resistance" parameter you start reporting resistance through
> > ABS_PRESSURE
> 
> Well, there is some historic confusion wether this driver reports resistance
> or pressure.
> 
> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> the fly (because a separate patch is much more complex than doing it right
> immediately).
> 
> This ti,report-resistance property is a means to get the old (wrong) meaning back
> in case someone urgently needs it and can't fix the user-space workaround which
> he must be using.
>
> 
> AFAIK there is no mainline board using the DT except ours (and the upcoming
> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> compatibility property. We don't need it for our devices.
>

You seem to be treating DT data as something very fluid, which is wrong.
You need to treat it as a firmware, unlikely to change once device is
shipped. Unlike legacy platform data, the fact that DTS files are not
present in mainline does not mean that we can ignore such users and
change behavior at will.

That said, if driver behavior is out of line from the subsystem
expectations, we need to fix it.

 
> That the function name is wrong is a second issue and this double negation might
> confuse a litte.
> 
> Please test on a real device if the patched driver reports pressure now (unless
> ti,report-resistance is specified).

I unfortunately can not test this driver as I do not have the hardware.
So all my observations are from code and data sheets.

That said, what is the values emitted as ABS_PRESSURE when finger is not
touching the device, barely touching the device, or pressing firmly?
It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
confusion as to what is being reported.

I am adding a few more folks to the CC so we can try and soft this out.
Sebastian, Pali, Pavel, any input here?

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

Hi Nikolaus,

On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > Hi Nikolaus,
> > 
> > On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> >> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> >> introduced common DT bindings for touchscreens [1] and a helper function to
> >> parse the DT.
> >> 
> >> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> >> added another helper for parsing axis inversion and swapping
> >> and applying them to x and y coordinates.
> >> 
> >> Both helpers have been integrated to accommodate any orientation of the
> >> touch panel in relation to the LCD.
> >> 
> >> A new feature is to introduce scaling the min/max ADC values to the screen
> >> size.
> >> 
> >> This makes it possible to pre-calibrate the touch so that is (almost)
> >> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> >> well enough operate the touch before a user space calibration step can
> >> improve the precision.
> > 
> > I question whether doing scaling in kernel is really right solution.
> 
> Since lower left corner does not exactly report [0 0] and upper right corner
> does not report [4095 4095] from the ADC we need offset and steepness correction
> of the ADC values.
> 
> This steepness is the scaling that must happen in kernel and I don't understand
> why you want to propagate this ADC errors to user-space by avoiding scaling.
> 
> Let me iterate what we want to achieve:
> * use new common bindings
> * offset and steepness calibration of the ADC (called pre-calibration).
>   This makes a real device much more reliable to operate with factory installed
>   scaling factors.
> * flipping and rotation
> 
> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)

That was explicitly called out in the patch:

"A new feature is to introduce scaling the min/max ADC values to the
screen size."

> 
> Now to achieve the ADC pre-calibration we must calculate
> 
> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
> 
> This is scaled up to what is defined by touchscreen-size-x, i.e.
> 
> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
> 
> How do you want to avoid this scaling to take place? It happens automatically.
> It is not even an additional line of code. And is necessary for compensating ADC
> offsets and steepness.
> 
> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
> compensation which is essential for a device which has no means to properly
> calibrate before operating the device through touch.
> 
> The other option would be to avoid common bindings and set
> 
> 	touchscreen-size-x = (ti,max-x-ti,min-x)
> 
> This is heavily dependent on specific ADC offsets forwarded to user-space.
> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
> 
> > 
> > Why do you want this?
> 
> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
> and LCD pixels and have designed code to achieve exactly that.
> 
> This is not the case. It is just a byproduct that you can do it.
> 
> And since it is easier to understand we have made the examples this way.
> 
> > If your touch resolution is lower than your screen
> > then it might be useful, but if it is lower then you are losing data
> > that can be very helpful for gesture recognition, and I hope you design
> > your userspace so it can handle not only "bad" hardware, but "good" as
> > well. And even with "bad" there are a lot of tricks that can be done to
> > get "better" touch position in userspace.
> 
> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
> This of course reduces the touch precision to full LCD pixels. For finger-
> touch operated devices, subpixel precision is rarely needed.
> 
> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
> such an 1:1 mapping and they will be perfectly happy about this. 
> 
> But, if you can modify your user-space easily, you can also choose a different
> factor.
> 
> You can for example define touchscreen-size-x=<4096> and then you get almost
> the highest precision of the ADC and won't loose any bits. Or even define a
> bigger range and get steps >1 bit.
> 
> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
> 
> So effectively we get for LCD pixels when the touch sets a mouse pointer:
> 
> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
> 
> The most simple setup would then be but others are possible:
> 
> 	user-space-scale = 1
> 	touchscreen-size-x = LCD-size-x
> 
> Let me cite myself:
> 
> >> This makes it possible to pre-calibrate the touch so that is (almost)

Yes, it allows you to pre-calibrate, I get it. But you still do properly
calibrate later, right? So you are doing double work here, once in
kernel, and second time in userspace.

I'd be more open to allowing setting the "min-axis" values to allow
reporting typical range for given device, and let userspace scale as it
sees fit.

> 
> > 
> >> 
> >> Please note that the old ti,fuzz properties have been removed since they
> >> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> >> 
> >> Finally, calculate_pressure has been renamed to calculate_resistance
> >> because that is what it is doing.
> > 
> > That is not what your patch does though. In the presence of
> > "ti,report-resistance" parameter you start reporting resistance through
> > ABS_PRESSURE
> 
> Well, there is some historic confusion wether this driver reports resistance
> or pressure.
> 
> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> the fly (because a separate patch is much more complex than doing it right
> immediately).
> 
> This ti,report-resistance property is a means to get the old (wrong) meaning back
> in case someone urgently needs it and can't fix the user-space workaround which
> he must be using.
>
> 
> AFAIK there is no mainline board using the DT except ours (and the upcoming
> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> compatibility property. We don't need it for our devices.
>

You seem to be treating DT data as something very fluid, which is wrong.
You need to treat it as a firmware, unlikely to change once device is
shipped. Unlike legacy platform data, the fact that DTS files are not
present in mainline does not mean that we can ignore such users and
change behavior at will.

That said, if driver behavior is out of line from the subsystem
expectations, we need to fix it.

 
> That the function name is wrong is a second issue and this double negation might
> confuse a litte.
> 
> Please test on a real device if the patched driver reports pressure now (unless
> ti,report-resistance is specified).

I unfortunately can not test this driver as I do not have the hardware.
So all my observations are from code and data sheets.

That said, what is the values emitted as ABS_PRESSURE when finger is not
touching the device, barely touching the device, or pressing firmly?
It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
confusion as to what is being reported.

I am adding a few more folks to the CC so we can try and soft this out.
Sebastian, Pali, Pavel, any input here?

Thanks.

-- 
Dmitry

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[Dmitry Torokhov]

On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > 
> > Hi Dmitry,
> > 
> >> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >> 
> >> Hi Dmitry,
> >> there have been no further comments/complaints about this patch series in the last month.
> >> And it appears as if only your action is needed.
> >> 
> >> What is missing for this patch series to be finally accepted?
> > 
> > Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
> > 
> > Is there anything open which prohibits inclusion to (and further testing within) linux/next?
> 
> May I ask a question for my fundamental understanding of the Linux integration process.
> Maybe, I have a wrong expectation which you can clarify.
> 
> My question is how it does come that patches like
> 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14
> 
> appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
> and there have been no further comments from the community for weeks?

Simpler patches are easy to apply, patches that have some contention
tend to get unapplied longer, as they require more consideration.

> 
> What is still missing what we can do or provide as information?

I just replied to the other email from you.

Thanks.

-- 
Dmitry

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[Dmitry Torokhov]

On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> > 
> > Hi Dmitry,
> > 
> >> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> >> 
> >> Hi Dmitry,
> >> there have been no further comments/complaints about this patch series in the last month.
> >> And it appears as if only your action is needed.
> >> 
> >> What is missing for this patch series to be finally accepted?
> > 
> > Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
> > 
> > Is there anything open which prohibits inclusion to (and further testing within) linux/next?
> 
> May I ask a question for my fundamental understanding of the Linux integration process.
> Maybe, I have a wrong expectation which you can clarify.
> 
> My question is how it does come that patches like
> 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14
> 
> appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
> and there have been no further comments from the community for weeks?

Simpler patches are easy to apply, patches that have some contention
tend to get unapplied longer, as they require more consideration.

> 
> What is still missing what we can do or provide as information?

I just replied to the other email from you.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[Dmitry Torokhov]

On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > 
> > Hi Dmitry,
> > 
> >> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >> 
> >> Hi Dmitry,
> >> there have been no further comments/complaints about this patch series in the last month.
> >> And it appears as if only your action is needed.
> >> 
> >> What is missing for this patch series to be finally accepted?
> > 
> > Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
> > 
> > Is there anything open which prohibits inclusion to (and further testing within) linux/next?
> 
> May I ask a question for my fundamental understanding of the Linux integration process.
> Maybe, I have a wrong expectation which you can clarify.
> 
> My question is how it does come that patches like
> 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14
> 
> appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
> and there have been no further comments from the community for weeks?

Simpler patches are easy to apply, patches that have some contention
tend to get unapplied longer, as they require more consideration.

> 
> What is still missing what we can do or provide as information?

I just replied to the other email from you.

Thanks.

-- 
Dmitry

Re: [PATCH v9 2/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[Dmitry Torokhov]

On Wed, Dec 28, 2016 at 03:53:17PM +0100, H. Nikolaus Schaller wrote:
> 1. check if chip is really present and don't succeed if it isn't.
> 2. if it succeeds, power down the chip until accessed
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>

Applied, thank you.

> ---
>  drivers/input/touchscreen/tsc2007.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
> index c1d9593..76b462b 100644
> --- a/drivers/input/touchscreen/tsc2007.c
> +++ b/drivers/input/touchscreen/tsc2007.c
> @@ -529,6 +529,14 @@ static int tsc2007_probe(struct i2c_client *client,
>  
>  	tsc2007_stop(ts);
>  
> +	/* power down the chip (TSC2007_SETUP does not ACK on I2C) */
> +	err = tsc2007_xfer(ts, PWRDOWN);
> +	if (err < 0) {
> +		dev_err(&client->dev,
> +			"Failed to setup chip: %d\n", err);
> +		return err;	/* usually, chip does not respond */
> +	}
> +
>  	err = input_register_device(input_dev);
>  	if (err) {
>  		dev_err(&client->dev,
> -- 
> 2.7.3
> 

-- 
Dmitry

Re: [PATCH v9 2/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[Dmitry Torokhov]

On Wed, Dec 28, 2016 at 03:53:17PM +0100, H. Nikolaus Schaller wrote:
> 1. check if chip is really present and don't succeed if it isn't.
> 2. if it succeeds, power down the chip until accessed
> 
> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>

Applied, thank you.

> ---
>  drivers/input/touchscreen/tsc2007.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
> index c1d9593..76b462b 100644
> --- a/drivers/input/touchscreen/tsc2007.c
> +++ b/drivers/input/touchscreen/tsc2007.c
> @@ -529,6 +529,14 @@ static int tsc2007_probe(struct i2c_client *client,
>  
>  	tsc2007_stop(ts);
>  
> +	/* power down the chip (TSC2007_SETUP does not ACK on I2C) */
> +	err = tsc2007_xfer(ts, PWRDOWN);
> +	if (err < 0) {
> +		dev_err(&client->dev,
> +			"Failed to setup chip: %d\n", err);
> +		return err;	/* usually, chip does not respond */
> +	}
> +
>  	err = input_register_device(input_dev);
>  	if (err) {
>  		dev_err(&client->dev,
> -- 
> 2.7.3
> 

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[Dmitry Torokhov]

On Fri, Dec 30, 2016 at 08:36:30PM +0000, Jonathan Cameron wrote:
> On 28/12/16 14:53, H. Nikolaus Schaller wrote:
> > The tsc2007 chip not only has a resistive touch screen controller but
> > also an external AUX adc imput which can be used for an ambient
> > light sensor, battery voltage monitoring or any general purpose.
> > 
> > Additionally it can measure the chip temperature.
> > 
> > This extension provides an iio interface for these adc channels.
> > 
> > Since it is not wasting much resources and is very straightforward,
> > we simply provide all other adc channels as optional iio interfaces
> > as weel. This can be used for debugging or special applications.
> > 
> > This patch also splits the tsc2007 driver in several source files:
> > tsc2007.h -- constants, structs and stubs
> > tsc2007_core.c -- functional parts of the original driver
> > tsc2007_iio.c -- the optional iio stuff
> > 
> > Makefile magic allows to conditionally link the iio stuff
> > if CONFIG_IIO=y or =m in a way that it works with
> > CONFIG_TOUCHSCREEN_TSC2007=m.
> > 
> > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> > Reviewed-by: Jonathan Cameron <jic23@kernel.org>
> Just for the record, I'm happy with the few changes from earlier versions.

I untangled this from the rest of the patches (as it turned out to be
the least controversial ;) ) and applied with some minor changes (see
below). Please take a look at my tsc2007 branch on kernel.org to see if
I missed anything.

Thanks.

> 
> Jonathan
> > ---
> >  drivers/input/touchscreen/Kconfig                  |  10 ++
> >  drivers/input/touchscreen/Makefile                 |   2 +
> >  drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
> >  .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
> >  drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
> >  5 files changed, 299 insertions(+), 74 deletions(-)
> >  create mode 100644 drivers/input/touchscreen/tsc2007.h
> >  rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
> >  create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> > index efca013..1616a8d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
> >  	  To compile this driver as a module, choose M here: the
> >  	  module will be called tsc2007.
> >  
> > +config TOUCHSCREEN_TSC2007_IIO
> > +	bool "IIO interface for external ADC input and temperature"
> > +	depends on TOUCHSCREEN_TSC2007
> > +	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
> > +	help
> > +	  Saying Y here adds an iio interface to the tsc2007 which
> > +	  provides values for the AUX input (used for e.g. battery
> > +	  or ambient light monitoring), temperature and raw input
> > +	  values.
> > +
> >  config TOUCHSCREEN_W90X900
> >  	tristate "W90P910 touchscreen driver"
> >  	depends on ARCH_W90X900
> > diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> > index 81b8645..05d1cc8 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
> > +tsc2007-y := tsc2007_core.o
> > +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
> >  obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
> > diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
> > new file mode 100644
> > index 0000000..16efb60
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/tsc2007.h
> > @@ -0,0 +1,116 @@
> > +/*
> > + * Copyright (c) 2008 MtekVision Co., Ltd.
> > + *	Kwangwoo Lee <kwlee@mtekvision.com>
> > + *
> > + * Using code from:
> > + *  - ads7846.c
> > + *	Copyright (c) 2005 David Brownell
> > + *	Copyright (c) 2006 Nokia Corporation
> > + *  - corgi_ts.c
> > + *	Copyright (C) 2004-2005 Richard Purdie
> > + *  - omap_ts.[hc], ads7846.h, ts_osk.c
> > + *	Copyright (C) 2002 MontaVista Software
> > + *	Copyright (C) 2004 Texas Instruments
> > + *	Copyright (C) 2005 Dirk Behme
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License version 2 as
> > + *  published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/input/touchscreen.h>
> > +
> > +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> > +#define TSC2007_MEASURE_AUX		(0x2 << 4)
> > +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> > +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> > +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> > +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> > +#define TSC2007_SETUP			(0xb << 4)
> > +#define TSC2007_MEASURE_X		(0xc << 4)
> > +#define TSC2007_MEASURE_Y		(0xd << 4)
> > +#define TSC2007_MEASURE_Z1		(0xe << 4)
> > +#define TSC2007_MEASURE_Z2		(0xf << 4)
> > +
> > +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> > +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> > +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> > +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> > +
> > +#define TSC2007_12BIT			(0x0 << 1)
> > +#define TSC2007_8BIT			(0x1 << 1)
> > +
> > +#define	MAX_12BIT			((1 << 12) - 1)
> > +
> > +#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> > +
> > +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> > +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> > +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> > +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> > +#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> > +
> > +struct ts_event {
> > +	u16	x;
> > +	u16	y;
> > +	u16	z1, z2;
> > +};
> > +
> > +struct tsc2007 {
> > +	struct input_dev	*input;
> > +	char			phys[32];
> > +
> > +	struct i2c_client	*client;
> > +
> > +	u16			model;
> > +	u16			x_plate_ohms;
> > +
> > +	struct touchscreen_properties prop;
> > +
> > +	bool			report_resistance;
> > +	u16			min_x;
> > +	u16			min_y;
> > +	u16			max_x;
> > +	u16			max_y;
> > +	u16			max_rt;
> > +	unsigned long		poll_period; /* in jiffies */
> > +	int			fuzzx;
> > +	int			fuzzy;
> > +	int			fuzzz;
> > +
> > +	unsigned int		gpio;
> > +	int			irq;
> > +
> > +	wait_queue_head_t	wait;
> > +	bool			stopped;
> > +	bool			pendown;
> > +
> > +	int			(*get_pendown_state)(struct device *);
> > +	void			(*clear_penirq)(void);
> > +
> > +	struct mutex		mlock;
> > +	struct iio_dev		*iio_dev;	/* optional */
> > +};
> > +
> > +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
> > +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> > +					struct ts_event *tc);
> > +bool tsc2007_is_pen_down(struct tsc2007 *ts);
> > +
> > +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
> > +
> > +/* defined in tsc2007_iio.c */
> > +int tsc2007_iio_configure(struct tsc2007 *ts);
> > +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
> > +
> > +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> > +
> > +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
> > +{
> > +	return 0;
> > +}
> > +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> > +{
> > +}
> > +
> > +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> > diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
> > similarity index 86%
> > rename from drivers/input/touchscreen/tsc2007.c
> > rename to drivers/input/touchscreen/tsc2007_core.c
> > index 76b462b..812ded8 100644
> > --- a/drivers/input/touchscreen/tsc2007.c
> > +++ b/drivers/input/touchscreen/tsc2007_core.c
> > @@ -27,79 +27,11 @@
> >  #include <linux/i2c.h>
> >  #include <linux/i2c/tsc2007.h>
> >  #include <linux/of_device.h>
> > -#include <linux/of.h>
> >  #include <linux/of_gpio.h>
> > -#include <linux/input/touchscreen.h>
> > -
> > -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> > -#define TSC2007_MEASURE_AUX		(0x2 << 4)
> > -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> > -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> > -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> > -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> > -#define TSC2007_SETUP			(0xb << 4)
> > -#define TSC2007_MEASURE_X		(0xc << 4)
> > -#define TSC2007_MEASURE_Y		(0xd << 4)
> > -#define TSC2007_MEASURE_Z1		(0xe << 4)
> > -#define TSC2007_MEASURE_Z2		(0xf << 4)
> > -
> > -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> > -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> > -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> > -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> > -
> > -#define TSC2007_12BIT			(0x0 << 1)
> > -#define TSC2007_8BIT			(0x1 << 1)
> > -
> > -#define	MAX_12BIT			((1 << 12) - 1)
> > -
> > -#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> > -
> > -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> > -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> > -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> > -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> > -#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> > -
> > -struct ts_event {
> > -	u16	x;
> > -	u16	y;
> > -	u16	z1, z2;
> > -};
> > -
> > -struct tsc2007 {
> > -	struct input_dev	*input;
> > -	char			phys[32];
> > -
> > -	struct i2c_client	*client;
> > -
> > -	u16			model;
> > -	u16			x_plate_ohms;
> > -
> > -	struct touchscreen_properties prop;
> > -
> > -	bool			report_resistance;
> > -	u16			min_x;
> > -	u16			min_y;
> > -	u16			max_x;
> > -	u16			max_y;
> > -	u16			max_rt;
> > -	unsigned long		poll_period; /* in jiffies */
> > -	int			fuzzx;
> > -	int			fuzzy;
> > -	int			fuzzz;
> > -
> > -	unsigned		gpio;
> > -	int			irq;
> > -
> > -	wait_queue_head_t	wait;
> > -	bool			stopped;
> > +#include "tsc2007.h"
> >  
> > -	int			(*get_pendown_state)(struct device *);
> > -	void			(*clear_penirq)(void);
> > -};
> >  
> > -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
> > +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
> >  {
> >  	s32 data;
> >  	u16 val;
> > @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
> >  	tsc2007_xfer(tsc, PWRDOWN);
> >  }
> >  
> > -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,

Kept as tsc2007_calculate_resistance for now.

> > +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> >  					struct ts_event *tc)
> >  {
> >  	u32 rt = 0;
> > @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> >  	return rt;
> >  }
> >  
> > -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
> > +bool tsc2007_is_pen_down(struct tsc2007 *ts)
> >  {
> >  	/*
> >  	 * NOTE: We can't rely on the pressure to determine the pen down
> > @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
> >  	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
> >  
> >  		/* pen is down, continue with the measurement */
> > +
> > +		mutex_lock(&ts->mlock);
> >  		tsc2007_read_values(ts, &tc);
> > +		mutex_unlock(&ts->mlock);
> >  
> >  		rt = tsc2007_calculate_resistance(ts, &tc);
> >  
> > @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
> >  static int tsc2007_probe(struct i2c_client *client,
> >  			 const struct i2c_device_id *id)
> >  {
> > -	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
> > +	const struct tsc2007_platform_data *pdata =
> > +		dev_get_platdata(&client->dev);
> >  	struct tsc2007 *ts;
> >  	struct input_dev *input_dev;
> >  	int err;
> > @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
> >  	ts->client = client;
> >  	ts->irq = client->irq;
> >  	ts->input = input_dev;
> > +
> >  	init_waitqueue_head(&ts->wait);
> > +	mutex_init(&ts->mlock);
> >  
> >  	snprintf(ts->phys, sizeof(ts->phys),
> >  		 "%s/input0", dev_name(&client->dev));
> > @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
> >  	if (err < 0) {
> >  		dev_err(&client->dev,
> >  			"Failed to setup chip: %d\n", err);
> > -		return err;	/* usually, chip does not respond */
> > +		return err;	/* chip does not respond */
> >  	}
> >  
> >  	err = input_register_device(input_dev);
> > @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
> >  		return err;
> >  	}
> >  
> > +	return tsc2007_iio_configure(ts);
> > +}
> > +
> > +static int tsc2007_remove(struct i2c_client *client)
> > +{
> > +	struct tsc2007 *ts = i2c_get_clientdata(client);
> > +
> > +	tsc2007_iio_unconfigure(ts);
> >  	return 0;
> >  }
> >  
> > @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
> >  	},
> >  	.id_table	= tsc2007_idtable,
> >  	.probe		= tsc2007_probe,
> > +	.remove		= tsc2007_remove,
> >  };
> >  
> >  module_i2c_driver(tsc2007_driver);
> > diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
> > new file mode 100644
> > index 0000000..ed79944
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/tsc2007_iio.c
> > @@ -0,0 +1,150 @@
> > +/*
> > + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
> > + *	Nikolaus Schaller <hns@goldelico.com>
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License version 2 as
> > + *  published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/i2c.h>
> > +#include <linux/iio/iio.h>
> > +#include "tsc2007.h"
> > +
> > +struct tsc2007_iio {
> > +	struct tsc2007 *ts;
> > +};
> > +
> > +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
> > +{ \
> > +	.datasheet_name = _name, \
> > +	.type = _type, \
> > +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
> > +			BIT(_chan_info), \
> > +	.indexed = 1, \
> > +	.channel = _chan, \
> > +}
> > +
> > +static const struct iio_chan_spec tsc2007_iio_channel[] = {
> > +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
> > +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
> > +};
> > +
> > +static int tsc2007_read_raw(struct iio_dev *indio_dev,
> > +	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
> > +{
> > +	struct tsc2007_iio *iio = iio_priv(indio_dev);
> > +	struct tsc2007 *tsc = iio->ts;
> > +	int adc_chan = chan->channel;
> > +	int ret = 0;
> > +
> > +	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
> > +		return -EINVAL;
> > +
> > +	if (mask != IIO_CHAN_INFO_RAW)
> > +		return -EINVAL;
> > +
> > +	mutex_lock(&tsc->mlock);
> > +
> > +	switch (chan->channel) {
> > +	case 0:
> > +		*val = tsc2007_xfer(tsc, READ_X);
> > +		break;
> > +	case 1:
> > +		*val = tsc2007_xfer(tsc, READ_Y);
> > +		break;
> > +	case 2:
> > +		*val = tsc2007_xfer(tsc, READ_Z1);
> > +		break;
> > +	case 3:
> > +		*val = tsc2007_xfer(tsc, READ_Z2);
> > +		break;
> > +	case 4:
> > +		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
> > +		break;
> > +	case 5: {
> > +		struct ts_event tc;
> > +
> > +		tc.x = tsc2007_xfer(tsc, READ_X);
> > +		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
> > +		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
> > +		*val = tsc2007_calculate_resistance(tsc, &tc);
> > +		break;
> > +	}
> > +	case 6:
> > +		*val = tsc2007_is_pen_down(tsc);
> > +		break;
> > +	case 7:
> > +		*val = tsc2007_xfer(tsc,
> > +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
> > +		break;
> > +	case 8:
> > +		*val = tsc2007_xfer(tsc,
> > +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
> > +		break;
> > +	}
> > +
> > +	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
> > +	tsc2007_xfer(tsc, PWRDOWN);
> > +
> > +	mutex_unlock(&tsc->mlock);
> > +
> > +	ret = IIO_VAL_INT;
> > +
> > +	return ret;
> > +}
> > +
> > +static const struct iio_info tsc2007_iio_info = {
> > +	.read_raw = tsc2007_read_raw,
> > +	.driver_module = THIS_MODULE,
> > +};
> > +
> > +int tsc2007_iio_configure(struct tsc2007 *ts)
> > +{
> > +	int err;
> > +	struct iio_dev *indio_dev;
> > +	struct tsc2007_iio *iio;
> > +
> > +	indio_dev = devm_iio_device_alloc(&ts->client->dev,
> > +		sizeof(struct tsc2007_iio));
> > +	if (!indio_dev) {
> > +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	iio = iio_priv(indio_dev);
> > +	iio->ts = ts;
> > +	ts->iio_dev = (void *) indio_dev;
> > +
> > +	indio_dev->name = "tsc2007";
> > +	indio_dev->dev.parent = &ts->client->dev;
> > +	indio_dev->info = &tsc2007_iio_info;
> > +	indio_dev->modes = INDIO_DIRECT_MODE;
> > +	indio_dev->channels = tsc2007_iio_channel;
> > +	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
> > +
> > +	err = iio_device_register(indio_dev);

Changed this to devm.

> > +	if (err < 0) {
> > +		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
> > +			err);
> > +		return err;
> > +	}
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(tsc2007_iio_configure);

This is not a separate module, there is no need to export this symbol.

> > +
> > +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> > +{
> > +	struct iio_dev *indio_dev = ts->iio_dev;
> > +
> > +	iio_device_unregister(indio_dev);
> > +}
> > +EXPORT_SYMBOL(tsc2007_iio_unconfigure);

Dropped this as not needed with devm.

-- 
Dmitry

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[Dmitry Torokhov]

On Fri, Dec 30, 2016 at 08:36:30PM +0000, Jonathan Cameron wrote:
> On 28/12/16 14:53, H. Nikolaus Schaller wrote:
> > The tsc2007 chip not only has a resistive touch screen controller but
> > also an external AUX adc imput which can be used for an ambient
> > light sensor, battery voltage monitoring or any general purpose.
> > 
> > Additionally it can measure the chip temperature.
> > 
> > This extension provides an iio interface for these adc channels.
> > 
> > Since it is not wasting much resources and is very straightforward,
> > we simply provide all other adc channels as optional iio interfaces
> > as weel. This can be used for debugging or special applications.
> > 
> > This patch also splits the tsc2007 driver in several source files:
> > tsc2007.h -- constants, structs and stubs
> > tsc2007_core.c -- functional parts of the original driver
> > tsc2007_iio.c -- the optional iio stuff
> > 
> > Makefile magic allows to conditionally link the iio stuff
> > if CONFIG_IIO=y or =m in a way that it works with
> > CONFIG_TOUCHSCREEN_TSC2007=m.
> > 
> > Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> > Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Just for the record, I'm happy with the few changes from earlier versions.

I untangled this from the rest of the patches (as it turned out to be
the least controversial ;) ) and applied with some minor changes (see
below). Please take a look at my tsc2007 branch on kernel.org to see if
I missed anything.

Thanks.

> 
> Jonathan
> > ---
> >  drivers/input/touchscreen/Kconfig                  |  10 ++
> >  drivers/input/touchscreen/Makefile                 |   2 +
> >  drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
> >  .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
> >  drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
> >  5 files changed, 299 insertions(+), 74 deletions(-)
> >  create mode 100644 drivers/input/touchscreen/tsc2007.h
> >  rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
> >  create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> > index efca013..1616a8d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
> >  	  To compile this driver as a module, choose M here: the
> >  	  module will be called tsc2007.
> >  
> > +config TOUCHSCREEN_TSC2007_IIO
> > +	bool "IIO interface for external ADC input and temperature"
> > +	depends on TOUCHSCREEN_TSC2007
> > +	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
> > +	help
> > +	  Saying Y here adds an iio interface to the tsc2007 which
> > +	  provides values for the AUX input (used for e.g. battery
> > +	  or ambient light monitoring), temperature and raw input
> > +	  values.
> > +
> >  config TOUCHSCREEN_W90X900
> >  	tristate "W90P910 touchscreen driver"
> >  	depends on ARCH_W90X900
> > diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> > index 81b8645..05d1cc8 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
> > +tsc2007-y := tsc2007_core.o
> > +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
> >  obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
> >  obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
> > diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
> > new file mode 100644
> > index 0000000..16efb60
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/tsc2007.h
> > @@ -0,0 +1,116 @@
> > +/*
> > + * Copyright (c) 2008 MtekVision Co., Ltd.
> > + *	Kwangwoo Lee <kwlee-ec7hoAtq5SbSUeElwK9/Pw@public.gmane.org>
> > + *
> > + * Using code from:
> > + *  - ads7846.c
> > + *	Copyright (c) 2005 David Brownell
> > + *	Copyright (c) 2006 Nokia Corporation
> > + *  - corgi_ts.c
> > + *	Copyright (C) 2004-2005 Richard Purdie
> > + *  - omap_ts.[hc], ads7846.h, ts_osk.c
> > + *	Copyright (C) 2002 MontaVista Software
> > + *	Copyright (C) 2004 Texas Instruments
> > + *	Copyright (C) 2005 Dirk Behme
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License version 2 as
> > + *  published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/input/touchscreen.h>
> > +
> > +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> > +#define TSC2007_MEASURE_AUX		(0x2 << 4)
> > +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> > +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> > +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> > +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> > +#define TSC2007_SETUP			(0xb << 4)
> > +#define TSC2007_MEASURE_X		(0xc << 4)
> > +#define TSC2007_MEASURE_Y		(0xd << 4)
> > +#define TSC2007_MEASURE_Z1		(0xe << 4)
> > +#define TSC2007_MEASURE_Z2		(0xf << 4)
> > +
> > +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> > +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> > +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> > +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> > +
> > +#define TSC2007_12BIT			(0x0 << 1)
> > +#define TSC2007_8BIT			(0x1 << 1)
> > +
> > +#define	MAX_12BIT			((1 << 12) - 1)
> > +
> > +#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> > +
> > +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> > +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> > +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> > +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> > +#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> > +
> > +struct ts_event {
> > +	u16	x;
> > +	u16	y;
> > +	u16	z1, z2;
> > +};
> > +
> > +struct tsc2007 {
> > +	struct input_dev	*input;
> > +	char			phys[32];
> > +
> > +	struct i2c_client	*client;
> > +
> > +	u16			model;
> > +	u16			x_plate_ohms;
> > +
> > +	struct touchscreen_properties prop;
> > +
> > +	bool			report_resistance;
> > +	u16			min_x;
> > +	u16			min_y;
> > +	u16			max_x;
> > +	u16			max_y;
> > +	u16			max_rt;
> > +	unsigned long		poll_period; /* in jiffies */
> > +	int			fuzzx;
> > +	int			fuzzy;
> > +	int			fuzzz;
> > +
> > +	unsigned int		gpio;
> > +	int			irq;
> > +
> > +	wait_queue_head_t	wait;
> > +	bool			stopped;
> > +	bool			pendown;
> > +
> > +	int			(*get_pendown_state)(struct device *);
> > +	void			(*clear_penirq)(void);
> > +
> > +	struct mutex		mlock;
> > +	struct iio_dev		*iio_dev;	/* optional */
> > +};
> > +
> > +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
> > +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> > +					struct ts_event *tc);
> > +bool tsc2007_is_pen_down(struct tsc2007 *ts);
> > +
> > +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
> > +
> > +/* defined in tsc2007_iio.c */
> > +int tsc2007_iio_configure(struct tsc2007 *ts);
> > +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
> > +
> > +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> > +
> > +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
> > +{
> > +	return 0;
> > +}
> > +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> > +{
> > +}
> > +
> > +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
> > diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
> > similarity index 86%
> > rename from drivers/input/touchscreen/tsc2007.c
> > rename to drivers/input/touchscreen/tsc2007_core.c
> > index 76b462b..812ded8 100644
> > --- a/drivers/input/touchscreen/tsc2007.c
> > +++ b/drivers/input/touchscreen/tsc2007_core.c
> > @@ -27,79 +27,11 @@
> >  #include <linux/i2c.h>
> >  #include <linux/i2c/tsc2007.h>
> >  #include <linux/of_device.h>
> > -#include <linux/of.h>
> >  #include <linux/of_gpio.h>
> > -#include <linux/input/touchscreen.h>
> > -
> > -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
> > -#define TSC2007_MEASURE_AUX		(0x2 << 4)
> > -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
> > -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
> > -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
> > -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
> > -#define TSC2007_SETUP			(0xb << 4)
> > -#define TSC2007_MEASURE_X		(0xc << 4)
> > -#define TSC2007_MEASURE_Y		(0xd << 4)
> > -#define TSC2007_MEASURE_Z1		(0xe << 4)
> > -#define TSC2007_MEASURE_Z2		(0xf << 4)
> > -
> > -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
> > -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
> > -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
> > -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
> > -
> > -#define TSC2007_12BIT			(0x0 << 1)
> > -#define TSC2007_8BIT			(0x1 << 1)
> > -
> > -#define	MAX_12BIT			((1 << 12) - 1)
> > -
> > -#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
> > -
> > -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
> > -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
> > -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
> > -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
> > -#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
> > -
> > -struct ts_event {
> > -	u16	x;
> > -	u16	y;
> > -	u16	z1, z2;
> > -};
> > -
> > -struct tsc2007 {
> > -	struct input_dev	*input;
> > -	char			phys[32];
> > -
> > -	struct i2c_client	*client;
> > -
> > -	u16			model;
> > -	u16			x_plate_ohms;
> > -
> > -	struct touchscreen_properties prop;
> > -
> > -	bool			report_resistance;
> > -	u16			min_x;
> > -	u16			min_y;
> > -	u16			max_x;
> > -	u16			max_y;
> > -	u16			max_rt;
> > -	unsigned long		poll_period; /* in jiffies */
> > -	int			fuzzx;
> > -	int			fuzzy;
> > -	int			fuzzz;
> > -
> > -	unsigned		gpio;
> > -	int			irq;
> > -
> > -	wait_queue_head_t	wait;
> > -	bool			stopped;
> > +#include "tsc2007.h"
> >  
> > -	int			(*get_pendown_state)(struct device *);
> > -	void			(*clear_penirq)(void);
> > -};
> >  
> > -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
> > +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
> >  {
> >  	s32 data;
> >  	u16 val;
> > @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
> >  	tsc2007_xfer(tsc, PWRDOWN);
> >  }
> >  
> > -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,

Kept as tsc2007_calculate_resistance for now.

> > +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> >  					struct ts_event *tc)
> >  {
> >  	u32 rt = 0;
> > @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> >  	return rt;
> >  }
> >  
> > -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
> > +bool tsc2007_is_pen_down(struct tsc2007 *ts)
> >  {
> >  	/*
> >  	 * NOTE: We can't rely on the pressure to determine the pen down
> > @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
> >  	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
> >  
> >  		/* pen is down, continue with the measurement */
> > +
> > +		mutex_lock(&ts->mlock);
> >  		tsc2007_read_values(ts, &tc);
> > +		mutex_unlock(&ts->mlock);
> >  
> >  		rt = tsc2007_calculate_resistance(ts, &tc);
> >  
> > @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
> >  static int tsc2007_probe(struct i2c_client *client,
> >  			 const struct i2c_device_id *id)
> >  {
> > -	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
> > +	const struct tsc2007_platform_data *pdata =
> > +		dev_get_platdata(&client->dev);
> >  	struct tsc2007 *ts;
> >  	struct input_dev *input_dev;
> >  	int err;
> > @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
> >  	ts->client = client;
> >  	ts->irq = client->irq;
> >  	ts->input = input_dev;
> > +
> >  	init_waitqueue_head(&ts->wait);
> > +	mutex_init(&ts->mlock);
> >  
> >  	snprintf(ts->phys, sizeof(ts->phys),
> >  		 "%s/input0", dev_name(&client->dev));
> > @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
> >  	if (err < 0) {
> >  		dev_err(&client->dev,
> >  			"Failed to setup chip: %d\n", err);
> > -		return err;	/* usually, chip does not respond */
> > +		return err;	/* chip does not respond */
> >  	}
> >  
> >  	err = input_register_device(input_dev);
> > @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
> >  		return err;
> >  	}
> >  
> > +	return tsc2007_iio_configure(ts);
> > +}
> > +
> > +static int tsc2007_remove(struct i2c_client *client)
> > +{
> > +	struct tsc2007 *ts = i2c_get_clientdata(client);
> > +
> > +	tsc2007_iio_unconfigure(ts);
> >  	return 0;
> >  }
> >  
> > @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
> >  	},
> >  	.id_table	= tsc2007_idtable,
> >  	.probe		= tsc2007_probe,
> > +	.remove		= tsc2007_remove,
> >  };
> >  
> >  module_i2c_driver(tsc2007_driver);
> > diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
> > new file mode 100644
> > index 0000000..ed79944
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/tsc2007_iio.c
> > @@ -0,0 +1,150 @@
> > +/*
> > + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
> > + *	Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License version 2 as
> > + *  published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/i2c.h>
> > +#include <linux/iio/iio.h>
> > +#include "tsc2007.h"
> > +
> > +struct tsc2007_iio {
> > +	struct tsc2007 *ts;
> > +};
> > +
> > +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
> > +{ \
> > +	.datasheet_name = _name, \
> > +	.type = _type, \
> > +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
> > +			BIT(_chan_info), \
> > +	.indexed = 1, \
> > +	.channel = _chan, \
> > +}
> > +
> > +static const struct iio_chan_spec tsc2007_iio_channel[] = {
> > +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
> > +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
> > +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
> > +};
> > +
> > +static int tsc2007_read_raw(struct iio_dev *indio_dev,
> > +	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
> > +{
> > +	struct tsc2007_iio *iio = iio_priv(indio_dev);
> > +	struct tsc2007 *tsc = iio->ts;
> > +	int adc_chan = chan->channel;
> > +	int ret = 0;
> > +
> > +	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
> > +		return -EINVAL;
> > +
> > +	if (mask != IIO_CHAN_INFO_RAW)
> > +		return -EINVAL;
> > +
> > +	mutex_lock(&tsc->mlock);
> > +
> > +	switch (chan->channel) {
> > +	case 0:
> > +		*val = tsc2007_xfer(tsc, READ_X);
> > +		break;
> > +	case 1:
> > +		*val = tsc2007_xfer(tsc, READ_Y);
> > +		break;
> > +	case 2:
> > +		*val = tsc2007_xfer(tsc, READ_Z1);
> > +		break;
> > +	case 3:
> > +		*val = tsc2007_xfer(tsc, READ_Z2);
> > +		break;
> > +	case 4:
> > +		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
> > +		break;
> > +	case 5: {
> > +		struct ts_event tc;
> > +
> > +		tc.x = tsc2007_xfer(tsc, READ_X);
> > +		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
> > +		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
> > +		*val = tsc2007_calculate_resistance(tsc, &tc);
> > +		break;
> > +	}
> > +	case 6:
> > +		*val = tsc2007_is_pen_down(tsc);
> > +		break;
> > +	case 7:
> > +		*val = tsc2007_xfer(tsc,
> > +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
> > +		break;
> > +	case 8:
> > +		*val = tsc2007_xfer(tsc,
> > +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
> > +		break;
> > +	}
> > +
> > +	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
> > +	tsc2007_xfer(tsc, PWRDOWN);
> > +
> > +	mutex_unlock(&tsc->mlock);
> > +
> > +	ret = IIO_VAL_INT;
> > +
> > +	return ret;
> > +}
> > +
> > +static const struct iio_info tsc2007_iio_info = {
> > +	.read_raw = tsc2007_read_raw,
> > +	.driver_module = THIS_MODULE,
> > +};
> > +
> > +int tsc2007_iio_configure(struct tsc2007 *ts)
> > +{
> > +	int err;
> > +	struct iio_dev *indio_dev;
> > +	struct tsc2007_iio *iio;
> > +
> > +	indio_dev = devm_iio_device_alloc(&ts->client->dev,
> > +		sizeof(struct tsc2007_iio));
> > +	if (!indio_dev) {
> > +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	iio = iio_priv(indio_dev);
> > +	iio->ts = ts;
> > +	ts->iio_dev = (void *) indio_dev;
> > +
> > +	indio_dev->name = "tsc2007";
> > +	indio_dev->dev.parent = &ts->client->dev;
> > +	indio_dev->info = &tsc2007_iio_info;
> > +	indio_dev->modes = INDIO_DIRECT_MODE;
> > +	indio_dev->channels = tsc2007_iio_channel;
> > +	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
> > +
> > +	err = iio_device_register(indio_dev);

Changed this to devm.

> > +	if (err < 0) {
> > +		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
> > +			err);
> > +		return err;
> > +	}
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(tsc2007_iio_configure);

This is not a separate module, there is no need to export this symbol.

> > +
> > +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
> > +{
> > +	struct iio_dev *indio_dev = ts->iio_dev;
> > +
> > +	iio_device_unregister(indio_dev);
> > +}
> > +EXPORT_SYMBOL(tsc2007_iio_unconfigure);

Dropped this as not needed with devm.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

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

Hi,

On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> > AFAIK there is no mainline board using the DT except ours (and the upcoming
> > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> > compatibility property. We don't need it for our devices.

$ cd linux.git/arch
$ git grep -l tsc2004
arm/boot/dts/imx6qdl-nit6xlite.dtsi
arm/boot/dts/imx7d-nitrogen7.dts
arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
arm/boot/dts/omap4-var-som-om44.dtsi
$ git grep -l tsc2005
arm/boot/dts/omap3-n900.dts
$ git grep -l tsc2007
arm/boot/dts/imx28-tx28.dts
arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
arm/boot/dts/imx53-tx53-x03x.dts
arm/boot/dts/imx6qdl-tx6.dtsi
arm/boot/dts/imx6ul-tx6ul.dtsi
arm/boot/dts/omap3-gta04.dtsi
sh/boards/mach-ecovec24/setup.c

> You seem to be treating DT data as something very fluid, which is wrong.
> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.
> 
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
> 
>  
> > That the function name is wrong is a second issue and this double negation might
> > confuse a litte.
> > 
> > Please test on a real device if the patched driver reports pressure now (unless
> > ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.
> So all my observations are from code and data sheets.
> 
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

As far as I can see all calculate Rtouch and ADS7846 reports
(Rmax - Rtouch), which looks sensible.

> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

I think tsc200x works, since usually userspace is Xorg and I think
it only cares for x/y coordinates + boolean pressure. Since
no-pressure is correctly reported as 0, everything works as
expected. I currently don't have X running on my N900 due some
omapdrm bug, so I can't test this, sorry.

I suggest to put the resistance vs pressure thing in its own patch,
that also fixes tsc200x-core and merge it to linux-next after the
merge window.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

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

Hi,

On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> > AFAIK there is no mainline board using the DT except ours (and the upcoming
> > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> > compatibility property. We don't need it for our devices.

$ cd linux.git/arch
$ git grep -l tsc2004
arm/boot/dts/imx6qdl-nit6xlite.dtsi
arm/boot/dts/imx7d-nitrogen7.dts
arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
arm/boot/dts/omap4-var-som-om44.dtsi
$ git grep -l tsc2005
arm/boot/dts/omap3-n900.dts
$ git grep -l tsc2007
arm/boot/dts/imx28-tx28.dts
arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
arm/boot/dts/imx53-tx53-x03x.dts
arm/boot/dts/imx6qdl-tx6.dtsi
arm/boot/dts/imx6ul-tx6ul.dtsi
arm/boot/dts/omap3-gta04.dtsi
sh/boards/mach-ecovec24/setup.c

> You seem to be treating DT data as something very fluid, which is wrong.
> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.
> 
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
> 
>  
> > That the function name is wrong is a second issue and this double negation might
> > confuse a litte.
> > 
> > Please test on a real device if the patched driver reports pressure now (unless
> > ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.
> So all my observations are from code and data sheets.
> 
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

As far as I can see all calculate Rtouch and ADS7846 reports
(Rmax - Rtouch), which looks sensible.

> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

I think tsc200x works, since usually userspace is Xorg and I think
it only cares for x/y coordinates + boolean pressure. Since
no-pressure is correctly reported as 0, everything works as
expected. I currently don't have X running on my N900 due some
omapdrm bug, so I can't test this, sorry.

I suggest to put the resistance vs pressure thing in its own patch,
that also fixes tsc200x-core and merge it to linux-next after the
merge window.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Andreas Kemnade]

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

Hi Dmitry,

On Fri, 17 Feb 2017 12:40:41 -0800
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

[...] 
> > Let me cite myself:
> > 
> > >> This makes it possible to pre-calibrate the touch so that is
> > >> (almost)
> 
> Yes, it allows you to pre-calibrate, I get it. But you still do
> properly calibrate later, right? So you are doing double work here,
> once in kernel, and second time in userspace.
> 
I as a daily user of that tsc2007 patch series say that I had never the
wish to calibrate it later in a better way. I am doing console work
with a virtual keyboard on it. So it is rarely double work here.

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Andreas Kemnade]

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

Hi Dmitry,

On Fri, 17 Feb 2017 12:40:41 -0800
Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

[...] 
> > Let me cite myself:
> > 
> > >> This makes it possible to pre-calibrate the touch so that is
> > >> (almost)
> 
> Yes, it allows you to pre-calibrate, I get it. But you still do
> properly calibrate later, right? So you are doing double work here,
> once in kernel, and second time in userspace.
> 
I as a daily user of that tsc2007 patch series say that I had never the
wish to calibrate it later in a better way. I am doing console work
with a virtual keyboard on it. So it is rarely double work here.

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > Well, there is some historic confusion wether this driver reports resistance
> > or pressure.
> > 
> > The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> > the fly (because a separate patch is much more complex than doing it right
> > immediately).
> > 
> > This ti,report-resistance property is a means to get the old (wrong) meaning back
> > in case someone urgently needs it and can't fix the user-space workaround which
> > he must be using.
> >
> > 
> > AFAIK there is no mainline board using the DT except ours (and the upcoming
> > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> > compatibility property. We don't need it for our devices.

N900 is mainline and uses DT.

> > That the function name is wrong is a second issue and this double negation might
> > confuse a litte.
> > 
> > Please test on a real device if the patched driver reports pressure now (unless
> > ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.
> So all my observations are from code and data sheets.
> 
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.
> 
> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

X work ok on N900. Nikolaus wrote rather long email, but I'm not what
the meaning is and what is supposed to be broken there.

I do this on X startup:

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
xinput --set-prop --type=int "TSC200X touchscreen" "Evdev Axis Inversion" 0 1
xinput --set-prop --type=float "TSC2005 touchscreen" "Coordinate Transformation Matrix"  1\
.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
xinput --set-prop --type=int "TSC2005 touchscreen" "Evdev Axis Inversion" 0 1

And I agree that kernel should _not_ attempt rescaling itself, as it
would lose precision. Providing default calibration info is ok.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > Well, there is some historic confusion wether this driver reports resistance
> > or pressure.
> > 
> > The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> > the fly (because a separate patch is much more complex than doing it right
> > immediately).
> > 
> > This ti,report-resistance property is a means to get the old (wrong) meaning back
> > in case someone urgently needs it and can't fix the user-space workaround which
> > he must be using.
> >
> > 
> > AFAIK there is no mainline board using the DT except ours (and the upcoming
> > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> > compatibility property. We don't need it for our devices.

N900 is mainline and uses DT.

> > That the function name is wrong is a second issue and this double negation might
> > confuse a litte.
> > 
> > Please test on a real device if the patched driver reports pressure now (unless
> > ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.
> So all my observations are from code and data sheets.
> 
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.
> 
> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

X work ok on N900. Nikolaus wrote rather long email, but I'm not what
the meaning is and what is supposed to be broken there.

I do this on X startup:

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
xinput --set-prop --type=int "TSC200X touchscreen" "Evdev Axis Inversion" 0 1
xinput --set-prop --type=float "TSC2005 touchscreen" "Coordinate Transformation Matrix"  1\
.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
xinput --set-prop --type=int "TSC2005 touchscreen" "Evdev Axis Inversion" 0 1

And I agree that kernel should _not_ attempt rescaling itself, as it
would lose precision. Providing default calibration info is ok.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 17.02.2017 um 21:43 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>> 
>>> Hi Dmitry,
>>> 
>>>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> Hi Dmitry,
>>>> there have been no further comments/complaints about this patch series in the last month.
>>>> And it appears as if only your action is needed.
>>>> 
>>>> What is missing for this patch series to be finally accepted?
>>> 
>>> Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
>>> 
>>> Is there anything open which prohibits inclusion to (and further testing within) linux/next?
>> 
>> May I ask a question for my fundamental understanding of the Linux integration process.
>> Maybe, I have a wrong expectation which you can clarify.
>> 
>> My question is how it does come that patches like
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14
>> 
>> appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
>> and there have been no further comments from the community for weeks?
> 
> Simpler patches are easy to apply, patches that have some contention
> tend to get unapplied longer, as they require more consideration.

Fine. Now I have better understanding.

> 
>> 
>> What is still missing what we can do or provide as information?
> 
> I just replied to the other email from you.

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 17.02.2017 um 21:43 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>> 
>>> Hi Dmitry,
>>> 
>>>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>>> 
>>>> Hi Dmitry,
>>>> there have been no further comments/complaints about this patch series in the last month.
>>>> And it appears as if only your action is needed.
>>>> 
>>>> What is missing for this patch series to be finally accepted?
>>> 
>>> Did you find time to look into my comment on patch 1/9 and make a decision on patch 6/8?
>>> 
>>> Is there anything open which prohibits inclusion to (and further testing within) linux/next?
>> 
>> May I ask a question for my fundamental understanding of the Linux integration process.
>> Maybe, I have a wrong expectation which you can clarify.
>> 
>> My question is how it does come that patches like
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14
>> 
>> appear within 2 days in linux-next, but our patch series had months of review (we are at v9)
>> and there have been no further comments from the community for weeks?
> 
> Simpler patches are easy to apply, patches that have some contention
> tend to get unapplied longer, as they require more consideration.

Fine. Now I have better understanding.

> 
>> 
>> What is still missing what we can do or provide as information?
> 
> I just replied to the other email from you.

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 17.02.2017 um 21:43 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>=20
>>> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>>>=20
>>> Hi Dmitry,
>>>=20
>>>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>>>>=20
>>>> Hi Dmitry,
>>>> there have been no further comments/complaints about this patch =
series in the last month.
>>>> And it appears as if only your action is needed.
>>>>=20
>>>> What is missing for this patch series to be finally accepted?
>>>=20
>>> Did you find time to look into my comment on patch 1/9 and make a =
decision on patch 6/8?
>>>=20
>>> Is there anything open which prohibits inclusion to (and further =
testing within) linux/next?
>>=20
>> May I ask a question for my fundamental understanding of the Linux =
integration process.
>> Maybe, I have a wrong expectation which you can clarify.
>>=20
>> My question is how it does come that patches like
>>=20
>> =
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?i=
d=3D449aa83e69ff10d77fe088eadacafe1e97937c14
>>=20
>> appear within 2 days in linux-next, but our patch series had months =
of review (we are at v9)
>> and there have been no further comments from the community for weeks?
>=20
> Simpler patches are easy to apply, patches that have some contention
> tend to get unapplied longer, as they require more consideration.

Fine. Now I have better understanding.

>=20
>>=20
>> What is still missing what we can do or provide as information?
>=20
> I just replied to the other email from you.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> Hi Nikolaus,
> 
> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>>> parse the DT.
>>>> 
>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> added another helper for parsing axis inversion and swapping
>>>> and applying them to x and y coordinates.
>>>> 
>>>> Both helpers have been integrated to accommodate any orientation of the
>>>> touch panel in relation to the LCD.
>>>> 
>>>> A new feature is to introduce scaling the min/max ADC values to the screen
>>>> size.
>>>> 
>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>>>> well enough operate the touch before a user space calibration step can
>>>> improve the precision.
>>> 
>>> I question whether doing scaling in kernel is really right solution.
>> 
>> Since lower left corner does not exactly report [0 0] and upper right corner
>> does not report [4095 4095] from the ADC we need offset and steepness correction
>> of the ADC values.
>> 
>> This steepness is the scaling that must happen in kernel and I don't understand
>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>> 
>> Let me iterate what we want to achieve:
>> * use new common bindings
>> * offset and steepness calibration of the ADC (called pre-calibration).
>>  This makes a real device much more reliable to operate with factory installed
>>  scaling factors.
>> * flipping and rotation
>> 
>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
> 
> That was explicitly called out in the patch:
> 
> "A new feature is to introduce scaling the min/max ADC values to the
> screen size."

Because it is a feature that was not planned nor required, but is there. So it came
into the description of what can be done. If this is the key problem I am happy with
removing it from the commit messages.

Anyways, scaling to screen coordinates is not my invention. It is based on

	http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which defines the size to be in pixels. Well, a resistive touch screen does not have pixels.
It might have a resolution/precision given by the ADC conversion steps but I assume
this is not meant here.

So this scaling to screen size was also stimulated by this DT bindings.

> 
>> 
>> Now to achieve the ADC pre-calibration we must calculate
>> 
>> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
>> 
>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>> 
>> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>> 
>> How do you want to avoid this scaling to take place? It happens automatically.
>> It is not even an additional line of code. And is necessary for compensating ADC
>> offsets and steepness.
>> 
>> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
>> compensation which is essential for a device which has no means to properly
>> calibrate before operating the device through touch.
>> 
>> The other option would be to avoid common bindings and set
>> 
>> 	touchscreen-size-x = (ti,max-x-ti,min-x)
>> 
>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>> 
>>> 
>>> Why do you want this?
>> 
>> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
>> and LCD pixels and have designed code to achieve exactly that.
>> 
>> This is not the case. It is just a byproduct that you can do it.
>> 
>> And since it is easier to understand we have made the examples this way.
>> 
>>> If your touch resolution is lower than your screen
>>> then it might be useful, but if it is lower then you are losing data
>>> that can be very helpful for gesture recognition, and I hope you design
>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>> well. And even with "bad" there are a lot of tricks that can be done to
>>> get "better" touch position in userspace.
>> 
>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>> This of course reduces the touch precision to full LCD pixels. For finger-
>> touch operated devices, subpixel precision is rarely needed.
>> 
>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>> such an 1:1 mapping and they will be perfectly happy about this. 
>> 
>> But, if you can modify your user-space easily, you can also choose a different
>> factor.
>> 
>> You can for example define touchscreen-size-x=<4096> and then you get almost
>> the highest precision of the ADC and won't loose any bits. Or even define a
>> bigger range and get steps >1 bit.
>> 
>> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
>> 
>> So effectively we get for LCD pixels when the touch sets a mouse pointer:
>> 
>> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
>> 
>> The most simple setup would then be but others are possible:
>> 
>> 	user-space-scale = 1
>> 	touchscreen-size-x = LCD-size-x
>> 
>> Let me cite myself:
>> 
>>>> This makes it possible to pre-calibrate the touch so that is (almost)
> 
> Yes, it allows you to pre-calibrate, I get it. But you still do properly
> calibrate later, right?

No. We want to get rid of this step unless we need to improve the precision by
some tiny %.

Why do we want to get rid of it?

This needs a longer explanation.

First of all we are working on the Letux distribution which aims at supporting
multiple devices in the same way and with a single SD card image that contains
one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
and DTB files for each supported device.

One of the ideas is to allow users to swap the SD card from one device to the
other. This means that the touch screen calibration must magically be carried
along - or we enforce to recalibrate every time the sd card is swapped back or
forth.

The same is true for prebuilt SD-images. To have a single (no longer device specific)
download requires to have a well defined default calibration. Especially on
devices where you have no keyboard where you can ask the user to manually fine-tune
something.

Our challenge is to make it work well without asking for explicit calibration.
This is where pre-calibration comes into the game.

It turns out to be related to the touch screen properties and how it is glued onto
the specific LCD panel, i.e. hardware and its description.

So the natural location of defining this relation is the DTB for each device
and not the user-space. And it happens that we already have one per device
(touch screen, lcd, tsc variant) on the SD card.

> So you are doing double work here, once in
> kernel, and second time in userspace.

This is no longer required, as long as we can use the default 1:1 coordinate mapping
of e.g. framebuffer or X11 based GUI toolkits.

If we don't have the 1:1 mapping of touch screen input event coordinates
to LCD pixels we have a mess of different scaling factors back in user-space
again. And the problem is setting them up properly in an installable .tbz
or .dd image.

Recently, you have raised another topic I had indeed not thought abut, which is
the potential subpixel precision of a resistive touch. You get approx. 12
bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
bit. So scaling the input event coordinates to pixels throws away 3 bits.

But there are two things to consider.

One is that we could set the pre-calibration to keep as much resolution as
possible, ca. 12 pixels and make the user-space scale down to screen coordinates.

Unfortunately that differs between devices and hence we need not only
different DTBs (which we already have) but different scale factors in user-space.

Next, one could argue that subpixel coordinates should not be handled by
scaling input event coordinates up and then down again in user-space. The
correct solution would be that input events could report fixed or floating
point coordinates, but this is probably beyond what we all want to do.

The other thing is noise. No resistive touch screen I have seen in the wild with
the tsc2007 or tsc2046 controller has the precision to really report subpixels.
Rather we have to set the fuzz between 3 or 10 or so. Which means that those
bits we cut off by scaling to screen coordinates are already lost in noise.

> 
> I'd be more open to allowing setting the "min-axis" values to allow
> reporting typical range for given device, and let userspace scale as it
> sees fit.

The problem is: what is "typical range"? It turns out to be a completely
arbitrary definition.

I see a choice between:
a) full theoretical ADC range
b) millimeters
c) pixels of the LCD the touch is glued to

For me, the most natural and practical "typical range" still seems to be the
pixels of the lcd panel the touch is glued onto.

The reason why I see it as superior to the others is that only this leads to
a stable 1:1 mapping in user-space avoiding to adjust any factors there.

And this 1:1 saves a lot of configuration hassle if you swap GUI systems
(X, Wayland, Android, DirectFB, fb based Qt, ...).

> 
>> 
>>> 
>>>> 
>>>> Please note that the old ti,fuzz properties have been removed since they
>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>> 
>>>> Finally, calculate_pressure has been renamed to calculate_resistance
>>>> because that is what it is doing.
>>> 
>>> That is not what your patch does though. In the presence of
>>> "ti,report-resistance" parameter you start reporting resistance through
>>> ABS_PRESSURE
>> 
>> Well, there is some historic confusion wether this driver reports resistance
>> or pressure.
>> 
>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>> the fly (because a separate patch is much more complex than doing it right
>> immediately).
>> 
>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>> in case someone urgently needs it and can't fix the user-space workaround which
>> he must be using.
>> 
>> 
>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>> compatibility property. We don't need it for our devices.
>> 
> 
> You seem to be treating DT data as something very fluid, which is wrong.

No,only sometimes.

Of course it should be done right once. Of course there is long discussion about
what is right...

> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.

Well, it happens to me as maintainer of a 99.5% mainline device every
now and then. Of course this should not be an argument to do it equally bad here.

One more thought: for some devices it is easier to modify the DTB "firmware"
than the user space (e.g. if you have no access to it because it is maintained
by somebody else).

> 
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
> 
> 
>> That the function name is wrong is a second issue and this double negation might
>> confuse a litte.
>> 
>> Please test on a real device if the patched driver reports pressure now (unless
>> ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.

Ah, ok. This is indeed a road block.

Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?

> So all my observations are from code and data sheets.

> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?

> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
pressing more firmly. This is not "pressure". The other drivers (I have tested
the OpenPandora with tsc2046) are doing it in a monotonic curve.

Hence I suggested to fix it for the tsc2007 (any perhaps others showing the same bug).
And allow a mechanism for those people who can more easily touch the DTB file than
the user space to turn it back to the old but wrong situation by setting a DT
property (maybe even in their boot.scr).

> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

Fine!

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> Hi Nikolaus,
> 
> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>>> parse the DT.
>>>> 
>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> added another helper for parsing axis inversion and swapping
>>>> and applying them to x and y coordinates.
>>>> 
>>>> Both helpers have been integrated to accommodate any orientation of the
>>>> touch panel in relation to the LCD.
>>>> 
>>>> A new feature is to introduce scaling the min/max ADC values to the screen
>>>> size.
>>>> 
>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>>>> well enough operate the touch before a user space calibration step can
>>>> improve the precision.
>>> 
>>> I question whether doing scaling in kernel is really right solution.
>> 
>> Since lower left corner does not exactly report [0 0] and upper right corner
>> does not report [4095 4095] from the ADC we need offset and steepness correction
>> of the ADC values.
>> 
>> This steepness is the scaling that must happen in kernel and I don't understand
>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>> 
>> Let me iterate what we want to achieve:
>> * use new common bindings
>> * offset and steepness calibration of the ADC (called pre-calibration).
>>  This makes a real device much more reliable to operate with factory installed
>>  scaling factors.
>> * flipping and rotation
>> 
>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
> 
> That was explicitly called out in the patch:
> 
> "A new feature is to introduce scaling the min/max ADC values to the
> screen size."

Because it is a feature that was not planned nor required, but is there. So it came
into the description of what can be done. If this is the key problem I am happy with
removing it from the commit messages.

Anyways, scaling to screen coordinates is not my invention. It is based on

	http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which defines the size to be in pixels. Well, a resistive touch screen does not have pixels.
It might have a resolution/precision given by the ADC conversion steps but I assume
this is not meant here.

So this scaling to screen size was also stimulated by this DT bindings.

> 
>> 
>> Now to achieve the ADC pre-calibration we must calculate
>> 
>> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
>> 
>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>> 
>> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>> 
>> How do you want to avoid this scaling to take place? It happens automatically.
>> It is not even an additional line of code. And is necessary for compensating ADC
>> offsets and steepness.
>> 
>> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
>> compensation which is essential for a device which has no means to properly
>> calibrate before operating the device through touch.
>> 
>> The other option would be to avoid common bindings and set
>> 
>> 	touchscreen-size-x = (ti,max-x-ti,min-x)
>> 
>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>> 
>>> 
>>> Why do you want this?
>> 
>> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
>> and LCD pixels and have designed code to achieve exactly that.
>> 
>> This is not the case. It is just a byproduct that you can do it.
>> 
>> And since it is easier to understand we have made the examples this way.
>> 
>>> If your touch resolution is lower than your screen
>>> then it might be useful, but if it is lower then you are losing data
>>> that can be very helpful for gesture recognition, and I hope you design
>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>> well. And even with "bad" there are a lot of tricks that can be done to
>>> get "better" touch position in userspace.
>> 
>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>> This of course reduces the touch precision to full LCD pixels. For finger-
>> touch operated devices, subpixel precision is rarely needed.
>> 
>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>> such an 1:1 mapping and they will be perfectly happy about this. 
>> 
>> But, if you can modify your user-space easily, you can also choose a different
>> factor.
>> 
>> You can for example define touchscreen-size-x=<4096> and then you get almost
>> the highest precision of the ADC and won't loose any bits. Or even define a
>> bigger range and get steps >1 bit.
>> 
>> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
>> 
>> So effectively we get for LCD pixels when the touch sets a mouse pointer:
>> 
>> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
>> 
>> The most simple setup would then be but others are possible:
>> 
>> 	user-space-scale = 1
>> 	touchscreen-size-x = LCD-size-x
>> 
>> Let me cite myself:
>> 
>>>> This makes it possible to pre-calibrate the touch so that is (almost)
> 
> Yes, it allows you to pre-calibrate, I get it. But you still do properly
> calibrate later, right?

No. We want to get rid of this step unless we need to improve the precision by
some tiny %.

Why do we want to get rid of it?

This needs a longer explanation.

First of all we are working on the Letux distribution which aims at supporting
multiple devices in the same way and with a single SD card image that contains
one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
and DTB files for each supported device.

One of the ideas is to allow users to swap the SD card from one device to the
other. This means that the touch screen calibration must magically be carried
along - or we enforce to recalibrate every time the sd card is swapped back or
forth.

The same is true for prebuilt SD-images. To have a single (no longer device specific)
download requires to have a well defined default calibration. Especially on
devices where you have no keyboard where you can ask the user to manually fine-tune
something.

Our challenge is to make it work well without asking for explicit calibration.
This is where pre-calibration comes into the game.

It turns out to be related to the touch screen properties and how it is glued onto
the specific LCD panel, i.e. hardware and its description.

So the natural location of defining this relation is the DTB for each device
and not the user-space. And it happens that we already have one per device
(touch screen, lcd, tsc variant) on the SD card.

> So you are doing double work here, once in
> kernel, and second time in userspace.

This is no longer required, as long as we can use the default 1:1 coordinate mapping
of e.g. framebuffer or X11 based GUI toolkits.

If we don't have the 1:1 mapping of touch screen input event coordinates
to LCD pixels we have a mess of different scaling factors back in user-space
again. And the problem is setting them up properly in an installable .tbz
or .dd image.

Recently, you have raised another topic I had indeed not thought abut, which is
the potential subpixel precision of a resistive touch. You get approx. 12
bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
bit. So scaling the input event coordinates to pixels throws away 3 bits.

But there are two things to consider.

One is that we could set the pre-calibration to keep as much resolution as
possible, ca. 12 pixels and make the user-space scale down to screen coordinates.

Unfortunately that differs between devices and hence we need not only
different DTBs (which we already have) but different scale factors in user-space.

Next, one could argue that subpixel coordinates should not be handled by
scaling input event coordinates up and then down again in user-space. The
correct solution would be that input events could report fixed or floating
point coordinates, but this is probably beyond what we all want to do.

The other thing is noise. No resistive touch screen I have seen in the wild with
the tsc2007 or tsc2046 controller has the precision to really report subpixels.
Rather we have to set the fuzz between 3 or 10 or so. Which means that those
bits we cut off by scaling to screen coordinates are already lost in noise.

> 
> I'd be more open to allowing setting the "min-axis" values to allow
> reporting typical range for given device, and let userspace scale as it
> sees fit.

The problem is: what is "typical range"? It turns out to be a completely
arbitrary definition.

I see a choice between:
a) full theoretical ADC range
b) millimeters
c) pixels of the LCD the touch is glued to

For me, the most natural and practical "typical range" still seems to be the
pixels of the lcd panel the touch is glued onto.

The reason why I see it as superior to the others is that only this leads to
a stable 1:1 mapping in user-space avoiding to adjust any factors there.

And this 1:1 saves a lot of configuration hassle if you swap GUI systems
(X, Wayland, Android, DirectFB, fb based Qt, ...).

> 
>> 
>>> 
>>>> 
>>>> Please note that the old ti,fuzz properties have been removed since they
>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>> 
>>>> Finally, calculate_pressure has been renamed to calculate_resistance
>>>> because that is what it is doing.
>>> 
>>> That is not what your patch does though. In the presence of
>>> "ti,report-resistance" parameter you start reporting resistance through
>>> ABS_PRESSURE
>> 
>> Well, there is some historic confusion wether this driver reports resistance
>> or pressure.
>> 
>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>> the fly (because a separate patch is much more complex than doing it right
>> immediately).
>> 
>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>> in case someone urgently needs it and can't fix the user-space workaround which
>> he must be using.
>> 
>> 
>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>> compatibility property. We don't need it for our devices.
>> 
> 
> You seem to be treating DT data as something very fluid, which is wrong.

No,only sometimes.

Of course it should be done right once. Of course there is long discussion about
what is right...

> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.

Well, it happens to me as maintainer of a 99.5% mainline device every
now and then. Of course this should not be an argument to do it equally bad here.

One more thought: for some devices it is easier to modify the DTB "firmware"
than the user space (e.g. if you have no access to it because it is maintained
by somebody else).

> 
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
> 
> 
>> That the function name is wrong is a second issue and this double negation might
>> confuse a litte.
>> 
>> Please test on a real device if the patched driver reports pressure now (unless
>> ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.

Ah, ok. This is indeed a road block.

Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?

> So all my observations are from code and data sheets.

> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?

> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
pressing more firmly. This is not "pressure". The other drivers (I have tested
the OpenPandora with tsc2046) are doing it in a monotonic curve.

Hence I suggested to fix it for the tsc2007 (any perhaps others showing the same bug).
And allow a mechanism for those people who can more easily touch the DTB file than
the user space to turn it back to the old but wrong situation by setting a DT
property (maybe even in their boot.scr).

> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

Fine!

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> Hi Nikolaus,
>=20
> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>=20
>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>=20
>>> Hi Nikolaus,
>>>=20
>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller =
wrote:
>>>> commit b98abe52fa8e ("Input: add common DT binding for =
touchscreens")
>>>> introduced common DT bindings for touchscreens [1] and a helper =
function to
>>>> parse the DT.
>>>>=20
>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for =
inverted / swapped axes")
>>>> added another helper for parsing axis inversion and swapping
>>>> and applying them to x and y coordinates.
>>>>=20
>>>> Both helpers have been integrated to accommodate any orientation of =
the
>>>> touch panel in relation to the LCD.
>>>>=20
>>>> A new feature is to introduce scaling the min/max ADC values to the =
screen
>>>> size.
>>>>=20
>>>> This makes it possible to pre-calibrate the touch so that is =
(almost)
>>>> exactly matches the LCD pixel coordinates it is glued onto. This =
allows to
>>>> well enough operate the touch before a user space calibration step =
can
>>>> improve the precision.
>>>=20
>>> I question whether doing scaling in kernel is really right solution.
>>=20
>> Since lower left corner does not exactly report [0 0] and upper right =
corner
>> does not report [4095 4095] from the ADC we need offset and steepness =
correction
>> of the ADC values.
>>=20
>> This steepness is the scaling that must happen in kernel and I don't =
understand
>> why you want to propagate this ADC errors to user-space by avoiding =
scaling.
>>=20
>> Let me iterate what we want to achieve:
>> * use new common bindings
>> * offset and steepness calibration of the ADC (called =
pre-calibration).
>>  This makes a real device much more reliable to operate with factory =
installed
>>  scaling factors.
>> * flipping and rotation
>>=20
>> (note that touch pixel to LCD pixel scaling is not explicitly on this =
list!)
>=20
> That was explicitly called out in the patch:
>=20
> "A new feature is to introduce scaling the min/max ADC values to the
> screen size."

Because it is a feature that was not planned nor required, but is there. =
So it came
into the description of what can be done. If this is the key problem I =
am happy with
removing it from the commit messages.

Anyways, scaling to screen coordinates is not my invention. It is based =
on

	=
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/inp=
ut/touchscreen/touchscreen.txt

which defines the size to be in pixels. Well, a resistive touch screen =
does not have pixels.
It might have a resolution/precision given by the ADC conversion steps =
but I assume
this is not meant here.

So this scaling to screen size was also stimulated by this DT bindings.

>=20
>>=20
>> Now to achieve the ADC pre-calibration we must calculate
>>=20
>> 	x' =3D (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from =
0.0 ... 1.0
>>=20
>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>=20
>> 	x' =3D (touchscreen-size-x * (x - ti,min-x)) / =
(ti,max-x-ti,min-x)
>>=20
>> How do you want to avoid this scaling to take place? It happens =
automatically.
>> It is not even an additional line of code. And is necessary for =
compensating ADC
>> offsets and steepness.
>>=20
>> So the only way to avoid the scaling option is to eliminate the =
precalibration/ADC
>> compensation which is essential for a device which has no means to =
properly
>> calibrate before operating the device through touch.
>>=20
>> The other option would be to avoid common bindings and set
>>=20
>> 	touchscreen-size-x =3D (ti,max-x-ti,min-x)
>>=20
>> This is heavily dependent on specific ADC offsets forwarded to =
user-space.
>> IMHO the worst we can do (and the current tsc2007 driver does it that =
way!).
>>=20
>>>=20
>>> Why do you want this?
>>=20
>> It seems that you assume that we want to enforce 1:1 scaling between =
touch pixels
>> and LCD pixels and have designed code to achieve exactly that.
>>=20
>> This is not the case. It is just a byproduct that you can do it.
>>=20
>> And since it is easier to understand we have made the examples this =
way.
>>=20
>>> If your touch resolution is lower than your screen
>>> then it might be useful, but if it is lower then you are losing data
>>> that can be very helpful for gesture recognition, and I hope you =
design
>>> your userspace so it can handle not only "bad" hardware, but "good" =
as
>>> well. And even with "bad" there are a lot of tricks that can be done =
to
>>> get "better" touch position in userspace.
>>=20
>> You can just *choose* DT parameters touchscreen-size-x to match the =
LCD size.
>> This of course reduces the touch precision to full LCD pixels. For =
finger-
>> touch operated devices, subpixel precision is rarely needed.
>>=20
>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that =
there is
>> such an 1:1 mapping and they will be perfectly happy about this.=20
>>=20
>> But, if you can modify your user-space easily, you can also choose a =
different
>> factor.
>>=20
>> You can for example define touchscreen-size-x=3D<4096> and then you =
get almost
>> the highest precision of the ADC and won't loose any bits. Or even =
define a
>> bigger range and get steps >1 bit.
>>=20
>> LCD driver (e.g. X11 calibration matrix) can scale it down again to =
LCD pixels.
>>=20
>> So effectively we get for LCD pixels when the touch sets a mouse =
pointer:
>>=20
>> 	x'' =3D user-space-scale * <<input-event<< ((touchscreen-size-x =
* (x - ti,min-x)) / (ti,max-x-ti,min-x))
>>=20
>> The most simple setup would then be but others are possible:
>>=20
>> 	user-space-scale =3D 1
>> 	touchscreen-size-x =3D LCD-size-x
>>=20
>> Let me cite myself:
>>=20
>>>> This makes it possible to pre-calibrate the touch so that is =
(almost)
>=20
> Yes, it allows you to pre-calibrate, I get it. But you still do =
properly
> calibrate later, right?

No. We want to get rid of this step unless we need to improve the =
precision by
some tiny %.

Why do we want to get rid of it?

This needs a longer explanation.

First of all we are working on the Letux distribution which aims at =
supporting
multiple devices in the same way and with a single SD card image that =
contains
one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel =
uImage
and DTB files for each supported device.

One of the ideas is to allow users to swap the SD card from one device =
to the
other. This means that the touch screen calibration must magically be =
carried
along - or we enforce to recalibrate every time the sd card is swapped =
back or
forth.

The same is true for prebuilt SD-images. To have a single (no longer =
device specific)
download requires to have a well defined default calibration. Especially =
on
devices where you have no keyboard where you can ask the user to =
manually fine-tune
something.

Our challenge is to make it work well without asking for explicit =
calibration.
This is where pre-calibration comes into the game.

It turns out to be related to the touch screen properties and how it is =
glued onto
the specific LCD panel, i.e. hardware and its description.

So the natural location of defining this relation is the DTB for each =
device
and not the user-space. And it happens that we already have one per =
device
(touch screen, lcd, tsc variant) on the SD card.

> So you are doing double work here, once in
> kernel, and second time in userspace.

This is no longer required, as long as we can use the default 1:1 =
coordinate mapping
of e.g. framebuffer or X11 based GUI toolkits.

If we don't have the 1:1 mapping of touch screen input event coordinates
to LCD pixels we have a mess of different scaling factors back in =
user-space
again. And the problem is setting them up properly in an installable =
.tbz
or .dd image.

Recently, you have raised another topic I had indeed not thought abut, =
which is
the potential subpixel precision of a resistive touch. You get approx. =
12
bit from the ADC but the x coordinate of the 480 pixel wide screen is =
just 9
bit. So scaling the input event coordinates to pixels throws away 3 =
bits.

But there are two things to consider.

One is that we could set the pre-calibration to keep as much resolution =
as
possible, ca. 12 pixels and make the user-space scale down to screen =
coordinates.

Unfortunately that differs between devices and hence we need not only
different DTBs (which we already have) but different scale factors in =
user-space.

Next, one could argue that subpixel coordinates should not be handled by
scaling input event coordinates up and then down again in user-space. =
The
correct solution would be that input events could report fixed or =
floating
point coordinates, but this is probably beyond what we all want to do.

The other thing is noise. No resistive touch screen I have seen in the =
wild with
the tsc2007 or tsc2046 controller has the precision to really report =
subpixels.
Rather we have to set the fuzz between 3 or 10 or so. Which means that =
those
bits we cut off by scaling to screen coordinates are already lost in =
noise.

>=20
> I'd be more open to allowing setting the "min-axis" values to allow
> reporting typical range for given device, and let userspace scale as =
it
> sees fit.

The problem is: what is "typical range"? It turns out to be a completely
arbitrary definition.

I see a choice between:
a) full theoretical ADC range
b) millimeters
c) pixels of the LCD the touch is glued to

For me, the most natural and practical "typical range" still seems to be =
the
pixels of the lcd panel the touch is glued onto.

The reason why I see it as superior to the others is that only this =
leads to
a stable 1:1 mapping in user-space avoiding to adjust any factors there.

And this 1:1 saves a lot of configuration hassle if you swap GUI systems
(X, Wayland, Android, DirectFB, fb based Qt, ...).

>=20
>>=20
>>>=20
>>>>=20
>>>> Please note that the old ti,fuzz properties have been removed since =
they
>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>>=20
>>>> Finally, calculate_pressure has been renamed to =
calculate_resistance
>>>> because that is what it is doing.
>>>=20
>>> That is not what your patch does though. In the presence of
>>> "ti,report-resistance" parameter you start reporting resistance =
through
>>> ABS_PRESSURE
>>=20
>> Well, there is some historic confusion wether this driver reports =
resistance
>> or pressure.
>>=20
>> The unpatched tsc2007 driver does it wrong (please test!) and we fix =
it on
>> the fly (because a separate patch is much more complex than doing it =
right
>> immediately).
>>=20
>> This ti,report-resistance property is a means to get the old (wrong) =
meaning back
>> in case someone urgently needs it and can't fix the user-space =
workaround which
>> he must be using.
>>=20
>>=20
>> AFAIK there is no mainline board using the DT except ours (and the =
upcoming
>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can =
remove this
>> compatibility property. We don't need it for our devices.
>>=20
>=20
> You seem to be treating DT data as something very fluid, which is =
wrong.

No,only sometimes.

Of course it should be done right once. Of course there is long =
discussion about
what is right...

> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.

Well, it happens to me as maintainer of a 99.5% mainline device every
now and then. Of course this should not be an argument to do it equally =
bad here.

One more thought: for some devices it is easier to modify the DTB =
"firmware"
than the user space (e.g. if you have no access to it because it is =
maintained
by somebody else).

>=20
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
>=20
>=20
>> That the function name is wrong is a second issue and this double =
negation might
>> confuse a litte.
>>=20
>> Please test on a real device if the patched driver reports pressure =
now (unless
>> ti,report-resistance is specified).
>=20
> I unfortunately can not test this driver as I do not have the =
hardware.

Ah, ok. This is indeed a road block.

Maybe someone else with a real tsc2007 hardware is reading this =
discussion and can comment?

> So all my observations are from code and data sheets.

> That said, what is the values emitted as ABS_PRESSURE when finger is =
not
> touching the device, barely touching the device, or pressing firmly?

> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

Indeed. The original tsc2007 jumps from 0 to a maximum value and goes =
down when
pressing more firmly. This is not "pressure". The other drivers (I have =
tested
the OpenPandora with tsc2046) are doing it in a monotonic curve.

Hence I suggested to fix it for the tsc2007 (any perhaps others showing =
the same bug).
And allow a mechanism for those people who can more easily touch the DTB =
file than
the user space to turn it back to the old but wrong situation by setting =
a DT
property (maybe even in their boot.scr).

> I am adding a few more folks to the CC so we can try and soft this =
out.
> Sebastian, Pali, Pavel, any input here?

Fine!

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Sebastian,

> Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre@kernel.org>:
> 
> Hi,
> 
> On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>> compatibility property. We don't need it for our devices.
> 
> $ cd linux.git/arch
> $ git grep -l tsc2004
> arm/boot/dts/imx6qdl-nit6xlite.dtsi
> arm/boot/dts/imx7d-nitrogen7.dts
> arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> arm/boot/dts/omap4-var-som-om44.dtsi
> $ git grep -l tsc2005
> arm/boot/dts/omap3-n900.dts

Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't
share code. Hence the N900 is not influenced by this patch series.

If it has a similar issue, it should be fixed of course.

> $ git grep -l tsc2007
> arm/boot/dts/imx28-tx28.dts
> arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
> arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
> arm/boot/dts/imx53-tx53-x03x.dts
> arm/boot/dts/imx6qdl-tx6.dtsi
> arm/boot/dts/imx6ul-tx6ul.dtsi
> arm/boot/dts/omap3-gta04.dtsi
> sh/boards/mach-ecovec24/setup.c

Sorry, I was a little imprecise here, because I looked for the min/max properties.
Of course, the imx devices use the tsc2007 as well.

Maybe we should edit all these DTS and set the "ti,report-resistance" property
by default. Then, no user should notice a difference.

Is any user/maintainer of these devices following this discussion and can comment?

> 
>> You seem to be treating DT data as something very fluid, which is wrong.
>> You need to treat it as a firmware, unlikely to change once device is
>> shipped. Unlike legacy platform data, the fact that DTS files are not
>> present in mainline does not mean that we can ignore such users and
>> change behavior at will.
>> 
>> That said, if driver behavior is out of line from the subsystem
>> expectations, we need to fix it.
>> 
>> 
>>> That the function name is wrong is a second issue and this double negation might
>>> confuse a litte.
>>> 
>>> Please test on a real device if the patched driver reports pressure now (unless
>>> ti,report-resistance is specified).
>> 
>> I unfortunately can not test this driver as I do not have the hardware.
>> So all my observations are from code and data sheets.
>> 
>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>> touching the device, barely touching the device, or pressing firmly?
>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>> confusion as to what is being reported.
> 
> As far as I can see all calculate Rtouch and ADS7846 reports
> (Rmax - Rtouch), which looks sensible.

I don't see where this subtraction from Rmax takes place for the tsc2007:

http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131

> 
>> I am adding a few more folks to the CC so we can try and soft this out.
>> Sebastian, Pali, Pavel, any input here?
> 
> I think tsc200x works, since usually userspace is Xorg and I think
> it only cares for x/y coordinates + boolean pressure. Since
> no-pressure is correctly reported as 0, everything works as
> expected.

No pressure is usually treated as a special case in these drivers,
so reduction to "boolean" in user-space works well by accident and
might still hide a bug.

> I currently don't have X running on my N900 due some
> omapdrm bug, so I can't test this, sorry.

I usually look with evtest if ABS_PRESSURE is monotonic.

> 
> I suggest to put the resistance vs pressure thing in its own patch,
> that also fixes tsc200x-core and merge it to linux-next after the
> merge window.
> 
> -- Sebastian

BR and thanks,
Nikolaus



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Sebastian,

> Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> 
> Hi,
> 
> On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>> compatibility property. We don't need it for our devices.
> 
> $ cd linux.git/arch
> $ git grep -l tsc2004
> arm/boot/dts/imx6qdl-nit6xlite.dtsi
> arm/boot/dts/imx7d-nitrogen7.dts
> arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> arm/boot/dts/omap4-var-som-om44.dtsi
> $ git grep -l tsc2005
> arm/boot/dts/omap3-n900.dts

Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't
share code. Hence the N900 is not influenced by this patch series.

If it has a similar issue, it should be fixed of course.

> $ git grep -l tsc2007
> arm/boot/dts/imx28-tx28.dts
> arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
> arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
> arm/boot/dts/imx53-tx53-x03x.dts
> arm/boot/dts/imx6qdl-tx6.dtsi
> arm/boot/dts/imx6ul-tx6ul.dtsi
> arm/boot/dts/omap3-gta04.dtsi
> sh/boards/mach-ecovec24/setup.c

Sorry, I was a little imprecise here, because I looked for the min/max properties.
Of course, the imx devices use the tsc2007 as well.

Maybe we should edit all these DTS and set the "ti,report-resistance" property
by default. Then, no user should notice a difference.

Is any user/maintainer of these devices following this discussion and can comment?

> 
>> You seem to be treating DT data as something very fluid, which is wrong.
>> You need to treat it as a firmware, unlikely to change once device is
>> shipped. Unlike legacy platform data, the fact that DTS files are not
>> present in mainline does not mean that we can ignore such users and
>> change behavior at will.
>> 
>> That said, if driver behavior is out of line from the subsystem
>> expectations, we need to fix it.
>> 
>> 
>>> That the function name is wrong is a second issue and this double negation might
>>> confuse a litte.
>>> 
>>> Please test on a real device if the patched driver reports pressure now (unless
>>> ti,report-resistance is specified).
>> 
>> I unfortunately can not test this driver as I do not have the hardware.
>> So all my observations are from code and data sheets.
>> 
>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>> touching the device, barely touching the device, or pressing firmly?
>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>> confusion as to what is being reported.
> 
> As far as I can see all calculate Rtouch and ADS7846 reports
> (Rmax - Rtouch), which looks sensible.

I don't see where this subtraction from Rmax takes place for the tsc2007:

http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131

> 
>> I am adding a few more folks to the CC so we can try and soft this out.
>> Sebastian, Pali, Pavel, any input here?
> 
> I think tsc200x works, since usually userspace is Xorg and I think
> it only cares for x/y coordinates + boolean pressure. Since
> no-pressure is correctly reported as 0, everything works as
> expected.

No pressure is usually treated as a special case in these drivers,
so reduction to "boolean" in user-space works well by accident and
might still hide a bug.

> I currently don't have X running on my N900 due some
> omapdrm bug, so I can't test this, sorry.

I usually look with evtest if ABS_PRESSURE is monotonic.

> 
> I suggest to put the resistance vs pressure thing in its own patch,
> that also fixes tsc200x-core and merge it to linux-next after the
> merge window.
> 
> -- Sebastian

BR and thanks,
Nikolaus



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 18.02.2017 um 10:15 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> Well, there is some historic confusion wether this driver reports resistance
>>> or pressure.
>>> 
>>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>>> the fly (because a separate patch is much more complex than doing it right
>>> immediately).
>>> 
>>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>>> in case someone urgently needs it and can't fix the user-space workaround which
>>> he must be using.
>>> 
>>> 
>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>> compatibility property. We don't need it for our devices.
> 
> N900 is mainline and uses DT.

Yes, but it does not use the tsc2007 and will not be influenced at all by this patch.

> 
>>> That the function name is wrong is a second issue and this double negation might
>>> confuse a litte.
>>> 
>>> Please test on a real device if the patched driver reports pressure now (unless
>>> ti,report-resistance is specified).
>> 
>> I unfortunately can not test this driver as I do not have the hardware.
>> So all my observations are from code and data sheets.
>> 
>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>> touching the device, barely touching the device, or pressing firmly?
>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>> confusion as to what is being reported.
>> 
>> I am adding a few more folks to the CC so we can try and soft this out.
>> Sebastian, Pali, Pavel, any input here?
> 
> X work ok on N900. Nikolaus wrote rather long email, but I'm not what
> the meaning is and what is supposed to be broken there.

IMHO it is broken that you have to do a subtle calibration step in user-space
and repeat it for different GUI toolkits.

> 
> I do this on X startup:
> 
> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
> xinput --set-prop --type=int "TSC200X touchscreen" "Evdev Axis Inversion" 0 1
> xinput --set-prop --type=float "TSC2005 touchscreen" "Coordinate Transformation Matrix"  1\
> .10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
> xinput --set-prop --type=int "TSC2005 touchscreen" "Evdev Axis Inversion" 0 1

Wouldn't  it be nice to get rid of this completely, because the DT/kernel knows these
factors? Especially since they are well defined by the hardware?

> 
> And I agree that kernel should _not_ attempt rescaling itself, as it
> would lose precision.

With an almost 1:1 mapping you won't loose precision.

> Providing default calibration info is ok.

IMHO it is missing one step of automation.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 18.02.2017 um 10:15 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> Well, there is some historic confusion wether this driver reports resistance
>>> or pressure.
>>> 
>>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>>> the fly (because a separate patch is much more complex than doing it right
>>> immediately).
>>> 
>>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>>> in case someone urgently needs it and can't fix the user-space workaround which
>>> he must be using.
>>> 
>>> 
>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>> compatibility property. We don't need it for our devices.
> 
> N900 is mainline and uses DT.

Yes, but it does not use the tsc2007 and will not be influenced at all by this patch.

> 
>>> That the function name is wrong is a second issue and this double negation might
>>> confuse a litte.
>>> 
>>> Please test on a real device if the patched driver reports pressure now (unless
>>> ti,report-resistance is specified).
>> 
>> I unfortunately can not test this driver as I do not have the hardware.
>> So all my observations are from code and data sheets.
>> 
>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>> touching the device, barely touching the device, or pressing firmly?
>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>> confusion as to what is being reported.
>> 
>> I am adding a few more folks to the CC so we can try and soft this out.
>> Sebastian, Pali, Pavel, any input here?
> 
> X work ok on N900. Nikolaus wrote rather long email, but I'm not what
> the meaning is and what is supposed to be broken there.

IMHO it is broken that you have to do a subtle calibration step in user-space
and repeat it for different GUI toolkits.

> 
> I do this on X startup:
> 
> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
> xinput --set-prop --type=int "TSC200X touchscreen" "Evdev Axis Inversion" 0 1
> xinput --set-prop --type=float "TSC2005 touchscreen" "Coordinate Transformation Matrix"  1\
> .10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00
> xinput --set-prop --type=int "TSC2005 touchscreen" "Evdev Axis Inversion" 0 1

Wouldn't  it be nice to get rid of this completely, because the DT/kernel knows these
factors? Especially since they are well defined by the hardware?

> 
> And I agree that kernel should _not_ attempt rescaling itself, as it
> would lose precision.

With an almost 1:1 mapping you won't loose precision.

> Providing default calibration info is ok.

IMHO it is missing one step of automation.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

> Am 17.02.2017 um 22:27 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Fri, Dec 30, 2016 at 08:36:30PM +0000, Jonathan Cameron wrote:
>> On 28/12/16 14:53, H. Nikolaus Schaller wrote:
>>> The tsc2007 chip not only has a resistive touch screen controller but
>>> also an external AUX adc imput which can be used for an ambient
>>> light sensor, battery voltage monitoring or any general purpose.
>>> 
>>> Additionally it can measure the chip temperature.
>>> 
>>> This extension provides an iio interface for these adc channels.
>>> 
>>> Since it is not wasting much resources and is very straightforward,
>>> we simply provide all other adc channels as optional iio interfaces
>>> as weel. This can be used for debugging or special applications.
>>> 
>>> This patch also splits the tsc2007 driver in several source files:
>>> tsc2007.h -- constants, structs and stubs
>>> tsc2007_core.c -- functional parts of the original driver
>>> tsc2007_iio.c -- the optional iio stuff
>>> 
>>> Makefile magic allows to conditionally link the iio stuff
>>> if CONFIG_IIO=y or =m in a way that it works with
>>> CONFIG_TOUCHSCREEN_TSC2007=m.
>>> 
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> Reviewed-by: Jonathan Cameron <jic23@kernel.org>
>> Just for the record, I'm happy with the few changes from earlier versions.
> 
> I untangled this from the rest of the patches (as it turned out to be
> the least controversial ;) ) and applied with some minor changes (see
> below). Please take a look at my tsc2007 branch on kernel.org to see if
> I missed anything.

Looks good!

BR and thanks,
Nikolaus

> 
> Thanks.
> 
>> 
>> Jonathan
>>> ---
>>> drivers/input/touchscreen/Kconfig                  |  10 ++
>>> drivers/input/touchscreen/Makefile                 |   2 +
>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
>>> 5 files changed, 299 insertions(+), 74 deletions(-)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>> 
>>> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>>> index efca013..1616a8d 100644
>>> --- a/drivers/input/touchscreen/Kconfig
>>> +++ b/drivers/input/touchscreen/Kconfig
>>> @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
>>> 	  To compile this driver as a module, choose M here: the
>>> 	  module will be called tsc2007.
>>> 
>>> +config TOUCHSCREEN_TSC2007_IIO
>>> +	bool "IIO interface for external ADC input and temperature"
>>> +	depends on TOUCHSCREEN_TSC2007
>>> +	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
>>> +	help
>>> +	  Saying Y here adds an iio interface to the tsc2007 which
>>> +	  provides values for the AUX input (used for e.g. battery
>>> +	  or ambient light monitoring), temperature and raw input
>>> +	  values.
>>> +
>>> config TOUCHSCREEN_W90X900
>>> 	tristate "W90P910 touchscreen driver"
>>> 	depends on ARCH_W90X900
>>> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
>>> index 81b8645..05d1cc8 100644
>>> --- a/drivers/input/touchscreen/Makefile
>>> +++ b/drivers/input/touchscreen/Makefile
>>> @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
>>> +tsc2007-y := tsc2007_core.o
>>> +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
>>> obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
>>> obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
>>> diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
>>> new file mode 100644
>>> index 0000000..16efb60
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007.h
>>> @@ -0,0 +1,116 @@
>>> +/*
>>> + * Copyright (c) 2008 MtekVision Co., Ltd.
>>> + *	Kwangwoo Lee <kwlee@mtekvision.com>
>>> + *
>>> + * Using code from:
>>> + *  - ads7846.c
>>> + *	Copyright (c) 2005 David Brownell
>>> + *	Copyright (c) 2006 Nokia Corporation
>>> + *  - corgi_ts.c
>>> + *	Copyright (C) 2004-2005 Richard Purdie
>>> + *  - omap_ts.[hc], ads7846.h, ts_osk.c
>>> + *	Copyright (C) 2002 MontaVista Software
>>> + *	Copyright (C) 2004 Texas Instruments
>>> + *	Copyright (C) 2005 Dirk Behme
>>> + *
>>> + *  This program is free software; you can redistribute it and/or modify
>>> + *  it under the terms of the GNU General Public License version 2 as
>>> + *  published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/input/touchscreen.h>
>>> +
>>> +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>>> +#define TSC2007_MEASURE_AUX		(0x2 << 4)
>>> +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
>>> +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
>>> +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
>>> +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
>>> +#define TSC2007_SETUP			(0xb << 4)
>>> +#define TSC2007_MEASURE_X		(0xc << 4)
>>> +#define TSC2007_MEASURE_Y		(0xd << 4)
>>> +#define TSC2007_MEASURE_Z1		(0xe << 4)
>>> +#define TSC2007_MEASURE_Z2		(0xf << 4)
>>> +
>>> +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
>>> +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
>>> +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
>>> +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
>>> +
>>> +#define TSC2007_12BIT			(0x0 << 1)
>>> +#define TSC2007_8BIT			(0x1 << 1)
>>> +
>>> +#define	MAX_12BIT			((1 << 12) - 1)
>>> +
>>> +#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
>>> +
>>> +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
>>> +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
>>> +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
>>> +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
>>> +#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
>>> +
>>> +struct ts_event {
>>> +	u16	x;
>>> +	u16	y;
>>> +	u16	z1, z2;
>>> +};
>>> +
>>> +struct tsc2007 {
>>> +	struct input_dev	*input;
>>> +	char			phys[32];
>>> +
>>> +	struct i2c_client	*client;
>>> +
>>> +	u16			model;
>>> +	u16			x_plate_ohms;
>>> +
>>> +	struct touchscreen_properties prop;
>>> +
>>> +	bool			report_resistance;
>>> +	u16			min_x;
>>> +	u16			min_y;
>>> +	u16			max_x;
>>> +	u16			max_y;
>>> +	u16			max_rt;
>>> +	unsigned long		poll_period; /* in jiffies */
>>> +	int			fuzzx;
>>> +	int			fuzzy;
>>> +	int			fuzzz;
>>> +
>>> +	unsigned int		gpio;
>>> +	int			irq;
>>> +
>>> +	wait_queue_head_t	wait;
>>> +	bool			stopped;
>>> +	bool			pendown;
>>> +
>>> +	int			(*get_pendown_state)(struct device *);
>>> +	void			(*clear_penirq)(void);
>>> +
>>> +	struct mutex		mlock;
>>> +	struct iio_dev		*iio_dev;	/* optional */
>>> +};
>>> +
>>> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
>>> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> +					struct ts_event *tc);
>>> +bool tsc2007_is_pen_down(struct tsc2007 *ts);
>>> +
>>> +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
>>> +
>>> +/* defined in tsc2007_iio.c */
>>> +int tsc2007_iio_configure(struct tsc2007 *ts);
>>> +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
>>> +
>>> +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
>>> +
>>> +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
>>> +{
>>> +	return 0;
>>> +}
>>> +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
>>> +{
>>> +}
>>> +
>>> +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
>>> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
>>> similarity index 86%
>>> rename from drivers/input/touchscreen/tsc2007.c
>>> rename to drivers/input/touchscreen/tsc2007_core.c
>>> index 76b462b..812ded8 100644
>>> --- a/drivers/input/touchscreen/tsc2007.c
>>> +++ b/drivers/input/touchscreen/tsc2007_core.c
>>> @@ -27,79 +27,11 @@
>>> #include <linux/i2c.h>
>>> #include <linux/i2c/tsc2007.h>
>>> #include <linux/of_device.h>
>>> -#include <linux/of.h>
>>> #include <linux/of_gpio.h>
>>> -#include <linux/input/touchscreen.h>
>>> -
>>> -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>>> -#define TSC2007_MEASURE_AUX		(0x2 << 4)
>>> -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
>>> -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
>>> -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
>>> -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
>>> -#define TSC2007_SETUP			(0xb << 4)
>>> -#define TSC2007_MEASURE_X		(0xc << 4)
>>> -#define TSC2007_MEASURE_Y		(0xd << 4)
>>> -#define TSC2007_MEASURE_Z1		(0xe << 4)
>>> -#define TSC2007_MEASURE_Z2		(0xf << 4)
>>> -
>>> -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
>>> -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
>>> -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
>>> -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
>>> -
>>> -#define TSC2007_12BIT			(0x0 << 1)
>>> -#define TSC2007_8BIT			(0x1 << 1)
>>> -
>>> -#define	MAX_12BIT			((1 << 12) - 1)
>>> -
>>> -#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
>>> -
>>> -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
>>> -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
>>> -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
>>> -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
>>> -#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
>>> -
>>> -struct ts_event {
>>> -	u16	x;
>>> -	u16	y;
>>> -	u16	z1, z2;
>>> -};
>>> -
>>> -struct tsc2007 {
>>> -	struct input_dev	*input;
>>> -	char			phys[32];
>>> -
>>> -	struct i2c_client	*client;
>>> -
>>> -	u16			model;
>>> -	u16			x_plate_ohms;
>>> -
>>> -	struct touchscreen_properties prop;
>>> -
>>> -	bool			report_resistance;
>>> -	u16			min_x;
>>> -	u16			min_y;
>>> -	u16			max_x;
>>> -	u16			max_y;
>>> -	u16			max_rt;
>>> -	unsigned long		poll_period; /* in jiffies */
>>> -	int			fuzzx;
>>> -	int			fuzzy;
>>> -	int			fuzzz;
>>> -
>>> -	unsigned		gpio;
>>> -	int			irq;
>>> -
>>> -	wait_queue_head_t	wait;
>>> -	bool			stopped;
>>> +#include "tsc2007.h"
>>> 
>>> -	int			(*get_pendown_state)(struct device *);
>>> -	void			(*clear_penirq)(void);
>>> -};
>>> 
>>> -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>>> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>>> {
>>> 	s32 data;
>>> 	u16 val;
>>> @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
>>> 	tsc2007_xfer(tsc, PWRDOWN);
>>> }
>>> 
>>> -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> 
> Kept as tsc2007_calculate_resistance for now.
> 
>>> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> 					struct ts_event *tc)
>>> {
>>> 	u32 rt = 0;
>>> @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> 	return rt;
>>> }
>>> 
>>> -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
>>> +bool tsc2007_is_pen_down(struct tsc2007 *ts)
>>> {
>>> 	/*
>>> 	 * NOTE: We can't rely on the pressure to determine the pen down
>>> @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
>>> 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
>>> 
>>> 		/* pen is down, continue with the measurement */
>>> +
>>> +		mutex_lock(&ts->mlock);
>>> 		tsc2007_read_values(ts, &tc);
>>> +		mutex_unlock(&ts->mlock);
>>> 
>>> 		rt = tsc2007_calculate_resistance(ts, &tc);
>>> 
>>> @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
>>> static int tsc2007_probe(struct i2c_client *client,
>>> 			 const struct i2c_device_id *id)
>>> {
>>> -	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
>>> +	const struct tsc2007_platform_data *pdata =
>>> +		dev_get_platdata(&client->dev);
>>> 	struct tsc2007 *ts;
>>> 	struct input_dev *input_dev;
>>> 	int err;
>>> @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
>>> 	ts->client = client;
>>> 	ts->irq = client->irq;
>>> 	ts->input = input_dev;
>>> +
>>> 	init_waitqueue_head(&ts->wait);
>>> +	mutex_init(&ts->mlock);
>>> 
>>> 	snprintf(ts->phys, sizeof(ts->phys),
>>> 		 "%s/input0", dev_name(&client->dev));
>>> @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
>>> 	if (err < 0) {
>>> 		dev_err(&client->dev,
>>> 			"Failed to setup chip: %d\n", err);
>>> -		return err;	/* usually, chip does not respond */
>>> +		return err;	/* chip does not respond */
>>> 	}
>>> 
>>> 	err = input_register_device(input_dev);
>>> @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
>>> 		return err;
>>> 	}
>>> 
>>> +	return tsc2007_iio_configure(ts);
>>> +}
>>> +
>>> +static int tsc2007_remove(struct i2c_client *client)
>>> +{
>>> +	struct tsc2007 *ts = i2c_get_clientdata(client);
>>> +
>>> +	tsc2007_iio_unconfigure(ts);
>>> 	return 0;
>>> }
>>> 
>>> @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
>>> 	},
>>> 	.id_table	= tsc2007_idtable,
>>> 	.probe		= tsc2007_probe,
>>> +	.remove		= tsc2007_remove,
>>> };
>>> 
>>> module_i2c_driver(tsc2007_driver);
>>> diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
>>> new file mode 100644
>>> index 0000000..ed79944
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007_iio.c
>>> @@ -0,0 +1,150 @@
>>> +/*
>>> + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
>>> + *	Nikolaus Schaller <hns@goldelico.com>
>>> + *
>>> + *  This program is free software; you can redistribute it and/or modify
>>> + *  it under the terms of the GNU General Public License version 2 as
>>> + *  published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/i2c.h>
>>> +#include <linux/iio/iio.h>
>>> +#include "tsc2007.h"
>>> +
>>> +struct tsc2007_iio {
>>> +	struct tsc2007 *ts;
>>> +};
>>> +
>>> +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
>>> +{ \
>>> +	.datasheet_name = _name, \
>>> +	.type = _type, \
>>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
>>> +			BIT(_chan_info), \
>>> +	.indexed = 1, \
>>> +	.channel = _chan, \
>>> +}
>>> +
>>> +static const struct iio_chan_spec tsc2007_iio_channel[] = {
>>> +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
>>> +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
>>> +};
>>> +
>>> +static int tsc2007_read_raw(struct iio_dev *indio_dev,
>>> +	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
>>> +{
>>> +	struct tsc2007_iio *iio = iio_priv(indio_dev);
>>> +	struct tsc2007 *tsc = iio->ts;
>>> +	int adc_chan = chan->channel;
>>> +	int ret = 0;
>>> +
>>> +	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
>>> +		return -EINVAL;
>>> +
>>> +	if (mask != IIO_CHAN_INFO_RAW)
>>> +		return -EINVAL;
>>> +
>>> +	mutex_lock(&tsc->mlock);
>>> +
>>> +	switch (chan->channel) {
>>> +	case 0:
>>> +		*val = tsc2007_xfer(tsc, READ_X);
>>> +		break;
>>> +	case 1:
>>> +		*val = tsc2007_xfer(tsc, READ_Y);
>>> +		break;
>>> +	case 2:
>>> +		*val = tsc2007_xfer(tsc, READ_Z1);
>>> +		break;
>>> +	case 3:
>>> +		*val = tsc2007_xfer(tsc, READ_Z2);
>>> +		break;
>>> +	case 4:
>>> +		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
>>> +		break;
>>> +	case 5: {
>>> +		struct ts_event tc;
>>> +
>>> +		tc.x = tsc2007_xfer(tsc, READ_X);
>>> +		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
>>> +		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
>>> +		*val = tsc2007_calculate_resistance(tsc, &tc);
>>> +		break;
>>> +	}
>>> +	case 6:
>>> +		*val = tsc2007_is_pen_down(tsc);
>>> +		break;
>>> +	case 7:
>>> +		*val = tsc2007_xfer(tsc,
>>> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
>>> +		break;
>>> +	case 8:
>>> +		*val = tsc2007_xfer(tsc,
>>> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
>>> +		break;
>>> +	}
>>> +
>>> +	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
>>> +	tsc2007_xfer(tsc, PWRDOWN);
>>> +
>>> +	mutex_unlock(&tsc->mlock);
>>> +
>>> +	ret = IIO_VAL_INT;
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +static const struct iio_info tsc2007_iio_info = {
>>> +	.read_raw = tsc2007_read_raw,
>>> +	.driver_module = THIS_MODULE,
>>> +};
>>> +
>>> +int tsc2007_iio_configure(struct tsc2007 *ts)
>>> +{
>>> +	int err;
>>> +	struct iio_dev *indio_dev;
>>> +	struct tsc2007_iio *iio;
>>> +
>>> +	indio_dev = devm_iio_device_alloc(&ts->client->dev,
>>> +		sizeof(struct tsc2007_iio));
>>> +	if (!indio_dev) {
>>> +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	iio = iio_priv(indio_dev);
>>> +	iio->ts = ts;
>>> +	ts->iio_dev = (void *) indio_dev;
>>> +
>>> +	indio_dev->name = "tsc2007";
>>> +	indio_dev->dev.parent = &ts->client->dev;
>>> +	indio_dev->info = &tsc2007_iio_info;
>>> +	indio_dev->modes = INDIO_DIRECT_MODE;
>>> +	indio_dev->channels = tsc2007_iio_channel;
>>> +	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
>>> +
>>> +	err = iio_device_register(indio_dev);
> 
> Changed this to devm.
> 
>>> +	if (err < 0) {
>>> +		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
>>> +			err);
>>> +		return err;
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL(tsc2007_iio_configure);
> 
> This is not a separate module, there is no need to export this symbol.
> 
>>> +
>>> +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
>>> +{
>>> +	struct iio_dev *indio_dev = ts->iio_dev;
>>> +
>>> +	iio_device_unregister(indio_dev);
>>> +}
>>> +EXPORT_SYMBOL(tsc2007_iio_unconfigure);
> 
> Dropped this as not needed with devm.
> 
> -- 
> Dmitry

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

> Am 17.02.2017 um 22:27 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> On Fri, Dec 30, 2016 at 08:36:30PM +0000, Jonathan Cameron wrote:
>> On 28/12/16 14:53, H. Nikolaus Schaller wrote:
>>> The tsc2007 chip not only has a resistive touch screen controller but
>>> also an external AUX adc imput which can be used for an ambient
>>> light sensor, battery voltage monitoring or any general purpose.
>>> 
>>> Additionally it can measure the chip temperature.
>>> 
>>> This extension provides an iio interface for these adc channels.
>>> 
>>> Since it is not wasting much resources and is very straightforward,
>>> we simply provide all other adc channels as optional iio interfaces
>>> as weel. This can be used for debugging or special applications.
>>> 
>>> This patch also splits the tsc2007 driver in several source files:
>>> tsc2007.h -- constants, structs and stubs
>>> tsc2007_core.c -- functional parts of the original driver
>>> tsc2007_iio.c -- the optional iio stuff
>>> 
>>> Makefile magic allows to conditionally link the iio stuff
>>> if CONFIG_IIO=y or =m in a way that it works with
>>> CONFIG_TOUCHSCREEN_TSC2007=m.
>>> 
>>> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
>>> Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Just for the record, I'm happy with the few changes from earlier versions.
> 
> I untangled this from the rest of the patches (as it turned out to be
> the least controversial ;) ) and applied with some minor changes (see
> below). Please take a look at my tsc2007 branch on kernel.org to see if
> I missed anything.

Looks good!

BR and thanks,
Nikolaus

> 
> Thanks.
> 
>> 
>> Jonathan
>>> ---
>>> drivers/input/touchscreen/Kconfig                  |  10 ++
>>> drivers/input/touchscreen/Makefile                 |   2 +
>>> drivers/input/touchscreen/tsc2007.h                | 116 ++++++++++++++++
>>> .../touchscreen/{tsc2007.c => tsc2007_core.c}      |  95 +++----------
>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 +++++++++++++++++++++
>>> 5 files changed, 299 insertions(+), 74 deletions(-)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>> 
>>> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>>> index efca013..1616a8d 100644
>>> --- a/drivers/input/touchscreen/Kconfig
>>> +++ b/drivers/input/touchscreen/Kconfig
>>> @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
>>> 	  To compile this driver as a module, choose M here: the
>>> 	  module will be called tsc2007.
>>> 
>>> +config TOUCHSCREEN_TSC2007_IIO
>>> +	bool "IIO interface for external ADC input and temperature"
>>> +	depends on TOUCHSCREEN_TSC2007
>>> +	depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
>>> +	help
>>> +	  Saying Y here adds an iio interface to the tsc2007 which
>>> +	  provides values for the AUX input (used for e.g. battery
>>> +	  or ambient light monitoring), temperature and raw input
>>> +	  values.
>>> +
>>> config TOUCHSCREEN_W90X900
>>> 	tristate "W90P910 touchscreen driver"
>>> 	depends on ARCH_W90X900
>>> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
>>> index 81b8645..05d1cc8 100644
>>> --- a/drivers/input/touchscreen/Makefile
>>> +++ b/drivers/input/touchscreen/Makefile
>>> @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+= tsc40.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+= tsc200x-core.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+= tsc2004.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+= tsc2005.o
>>> +tsc2007-y := tsc2007_core.o
>>> +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+= tsc2007_iio.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+= tsc2007.o
>>> obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+= ucb1400_ts.o
>>> obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+= wacom_w8001.o
>>> diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
>>> new file mode 100644
>>> index 0000000..16efb60
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007.h
>>> @@ -0,0 +1,116 @@
>>> +/*
>>> + * Copyright (c) 2008 MtekVision Co., Ltd.
>>> + *	Kwangwoo Lee <kwlee-ec7hoAtq5SbSUeElwK9/Pw@public.gmane.org>
>>> + *
>>> + * Using code from:
>>> + *  - ads7846.c
>>> + *	Copyright (c) 2005 David Brownell
>>> + *	Copyright (c) 2006 Nokia Corporation
>>> + *  - corgi_ts.c
>>> + *	Copyright (C) 2004-2005 Richard Purdie
>>> + *  - omap_ts.[hc], ads7846.h, ts_osk.c
>>> + *	Copyright (C) 2002 MontaVista Software
>>> + *	Copyright (C) 2004 Texas Instruments
>>> + *	Copyright (C) 2005 Dirk Behme
>>> + *
>>> + *  This program is free software; you can redistribute it and/or modify
>>> + *  it under the terms of the GNU General Public License version 2 as
>>> + *  published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/input/touchscreen.h>
>>> +
>>> +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>>> +#define TSC2007_MEASURE_AUX		(0x2 << 4)
>>> +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
>>> +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
>>> +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
>>> +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
>>> +#define TSC2007_SETUP			(0xb << 4)
>>> +#define TSC2007_MEASURE_X		(0xc << 4)
>>> +#define TSC2007_MEASURE_Y		(0xd << 4)
>>> +#define TSC2007_MEASURE_Z1		(0xe << 4)
>>> +#define TSC2007_MEASURE_Z2		(0xf << 4)
>>> +
>>> +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
>>> +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
>>> +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
>>> +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
>>> +
>>> +#define TSC2007_12BIT			(0x0 << 1)
>>> +#define TSC2007_8BIT			(0x1 << 1)
>>> +
>>> +#define	MAX_12BIT			((1 << 12) - 1)
>>> +
>>> +#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
>>> +
>>> +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
>>> +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
>>> +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
>>> +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
>>> +#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
>>> +
>>> +struct ts_event {
>>> +	u16	x;
>>> +	u16	y;
>>> +	u16	z1, z2;
>>> +};
>>> +
>>> +struct tsc2007 {
>>> +	struct input_dev	*input;
>>> +	char			phys[32];
>>> +
>>> +	struct i2c_client	*client;
>>> +
>>> +	u16			model;
>>> +	u16			x_plate_ohms;
>>> +
>>> +	struct touchscreen_properties prop;
>>> +
>>> +	bool			report_resistance;
>>> +	u16			min_x;
>>> +	u16			min_y;
>>> +	u16			max_x;
>>> +	u16			max_y;
>>> +	u16			max_rt;
>>> +	unsigned long		poll_period; /* in jiffies */
>>> +	int			fuzzx;
>>> +	int			fuzzy;
>>> +	int			fuzzz;
>>> +
>>> +	unsigned int		gpio;
>>> +	int			irq;
>>> +
>>> +	wait_queue_head_t	wait;
>>> +	bool			stopped;
>>> +	bool			pendown;
>>> +
>>> +	int			(*get_pendown_state)(struct device *);
>>> +	void			(*clear_penirq)(void);
>>> +
>>> +	struct mutex		mlock;
>>> +	struct iio_dev		*iio_dev;	/* optional */
>>> +};
>>> +
>>> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
>>> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> +					struct ts_event *tc);
>>> +bool tsc2007_is_pen_down(struct tsc2007 *ts);
>>> +
>>> +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
>>> +
>>> +/* defined in tsc2007_iio.c */
>>> +int tsc2007_iio_configure(struct tsc2007 *ts);
>>> +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
>>> +
>>> +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
>>> +
>>> +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
>>> +{
>>> +	return 0;
>>> +}
>>> +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
>>> +{
>>> +}
>>> +
>>> +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
>>> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
>>> similarity index 86%
>>> rename from drivers/input/touchscreen/tsc2007.c
>>> rename to drivers/input/touchscreen/tsc2007_core.c
>>> index 76b462b..812ded8 100644
>>> --- a/drivers/input/touchscreen/tsc2007.c
>>> +++ b/drivers/input/touchscreen/tsc2007_core.c
>>> @@ -27,79 +27,11 @@
>>> #include <linux/i2c.h>
>>> #include <linux/i2c/tsc2007.h>
>>> #include <linux/of_device.h>
>>> -#include <linux/of.h>
>>> #include <linux/of_gpio.h>
>>> -#include <linux/input/touchscreen.h>
>>> -
>>> -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>>> -#define TSC2007_MEASURE_AUX		(0x2 << 4)
>>> -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
>>> -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
>>> -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
>>> -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
>>> -#define TSC2007_SETUP			(0xb << 4)
>>> -#define TSC2007_MEASURE_X		(0xc << 4)
>>> -#define TSC2007_MEASURE_Y		(0xd << 4)
>>> -#define TSC2007_MEASURE_Z1		(0xe << 4)
>>> -#define TSC2007_MEASURE_Z2		(0xf << 4)
>>> -
>>> -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
>>> -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
>>> -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
>>> -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
>>> -
>>> -#define TSC2007_12BIT			(0x0 << 1)
>>> -#define TSC2007_8BIT			(0x1 << 1)
>>> -
>>> -#define	MAX_12BIT			((1 << 12) - 1)
>>> -
>>> -#define ADC_ON_12BIT	(TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
>>> -
>>> -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
>>> -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
>>> -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
>>> -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
>>> -#define PWRDOWN		(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
>>> -
>>> -struct ts_event {
>>> -	u16	x;
>>> -	u16	y;
>>> -	u16	z1, z2;
>>> -};
>>> -
>>> -struct tsc2007 {
>>> -	struct input_dev	*input;
>>> -	char			phys[32];
>>> -
>>> -	struct i2c_client	*client;
>>> -
>>> -	u16			model;
>>> -	u16			x_plate_ohms;
>>> -
>>> -	struct touchscreen_properties prop;
>>> -
>>> -	bool			report_resistance;
>>> -	u16			min_x;
>>> -	u16			min_y;
>>> -	u16			max_x;
>>> -	u16			max_y;
>>> -	u16			max_rt;
>>> -	unsigned long		poll_period; /* in jiffies */
>>> -	int			fuzzx;
>>> -	int			fuzzy;
>>> -	int			fuzzz;
>>> -
>>> -	unsigned		gpio;
>>> -	int			irq;
>>> -
>>> -	wait_queue_head_t	wait;
>>> -	bool			stopped;
>>> +#include "tsc2007.h"
>>> 
>>> -	int			(*get_pendown_state)(struct device *);
>>> -	void			(*clear_penirq)(void);
>>> -};
>>> 
>>> -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>>> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>>> {
>>> 	s32 data;
>>> 	u16 val;
>>> @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
>>> 	tsc2007_xfer(tsc, PWRDOWN);
>>> }
>>> 
>>> -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
> 
> Kept as tsc2007_calculate_resistance for now.
> 
>>> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> 					struct ts_event *tc)
>>> {
>>> 	u32 rt = 0;
>>> @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> 	return rt;
>>> }
>>> 
>>> -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
>>> +bool tsc2007_is_pen_down(struct tsc2007 *ts)
>>> {
>>> 	/*
>>> 	 * NOTE: We can't rely on the pressure to determine the pen down
>>> @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
>>> 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
>>> 
>>> 		/* pen is down, continue with the measurement */
>>> +
>>> +		mutex_lock(&ts->mlock);
>>> 		tsc2007_read_values(ts, &tc);
>>> +		mutex_unlock(&ts->mlock);
>>> 
>>> 		rt = tsc2007_calculate_resistance(ts, &tc);
>>> 
>>> @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
>>> static int tsc2007_probe(struct i2c_client *client,
>>> 			 const struct i2c_device_id *id)
>>> {
>>> -	const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
>>> +	const struct tsc2007_platform_data *pdata =
>>> +		dev_get_platdata(&client->dev);
>>> 	struct tsc2007 *ts;
>>> 	struct input_dev *input_dev;
>>> 	int err;
>>> @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client *client,
>>> 	ts->client = client;
>>> 	ts->irq = client->irq;
>>> 	ts->input = input_dev;
>>> +
>>> 	init_waitqueue_head(&ts->wait);
>>> +	mutex_init(&ts->mlock);
>>> 
>>> 	snprintf(ts->phys, sizeof(ts->phys),
>>> 		 "%s/input0", dev_name(&client->dev));
>>> @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client *client,
>>> 	if (err < 0) {
>>> 		dev_err(&client->dev,
>>> 			"Failed to setup chip: %d\n", err);
>>> -		return err;	/* usually, chip does not respond */
>>> +		return err;	/* chip does not respond */
>>> 	}
>>> 
>>> 	err = input_register_device(input_dev);
>>> @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client *client,
>>> 		return err;
>>> 	}
>>> 
>>> +	return tsc2007_iio_configure(ts);
>>> +}
>>> +
>>> +static int tsc2007_remove(struct i2c_client *client)
>>> +{
>>> +	struct tsc2007 *ts = i2c_get_clientdata(client);
>>> +
>>> +	tsc2007_iio_unconfigure(ts);
>>> 	return 0;
>>> }
>>> 
>>> @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver = {
>>> 	},
>>> 	.id_table	= tsc2007_idtable,
>>> 	.probe		= tsc2007_probe,
>>> +	.remove		= tsc2007_remove,
>>> };
>>> 
>>> module_i2c_driver(tsc2007_driver);
>>> diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
>>> new file mode 100644
>>> index 0000000..ed79944
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007_iio.c
>>> @@ -0,0 +1,150 @@
>>> +/*
>>> + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
>>> + *	Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
>>> + *
>>> + *  This program is free software; you can redistribute it and/or modify
>>> + *  it under the terms of the GNU General Public License version 2 as
>>> + *  published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/i2c.h>
>>> +#include <linux/iio/iio.h>
>>> +#include "tsc2007.h"
>>> +
>>> +struct tsc2007_iio {
>>> +	struct tsc2007 *ts;
>>> +};
>>> +
>>> +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
>>> +{ \
>>> +	.datasheet_name = _name, \
>>> +	.type = _type, \
>>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |	\
>>> +			BIT(_chan_info), \
>>> +	.indexed = 1, \
>>> +	.channel = _chan, \
>>> +}
>>> +
>>> +static const struct iio_chan_spec tsc2007_iio_channel[] = {
>>> +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
>>> +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
>>> +};
>>> +
>>> +static int tsc2007_read_raw(struct iio_dev *indio_dev,
>>> +	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
>>> +{
>>> +	struct tsc2007_iio *iio = iio_priv(indio_dev);
>>> +	struct tsc2007 *tsc = iio->ts;
>>> +	int adc_chan = chan->channel;
>>> +	int ret = 0;
>>> +
>>> +	if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
>>> +		return -EINVAL;
>>> +
>>> +	if (mask != IIO_CHAN_INFO_RAW)
>>> +		return -EINVAL;
>>> +
>>> +	mutex_lock(&tsc->mlock);
>>> +
>>> +	switch (chan->channel) {
>>> +	case 0:
>>> +		*val = tsc2007_xfer(tsc, READ_X);
>>> +		break;
>>> +	case 1:
>>> +		*val = tsc2007_xfer(tsc, READ_Y);
>>> +		break;
>>> +	case 2:
>>> +		*val = tsc2007_xfer(tsc, READ_Z1);
>>> +		break;
>>> +	case 3:
>>> +		*val = tsc2007_xfer(tsc, READ_Z2);
>>> +		break;
>>> +	case 4:
>>> +		*val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
>>> +		break;
>>> +	case 5: {
>>> +		struct ts_event tc;
>>> +
>>> +		tc.x = tsc2007_xfer(tsc, READ_X);
>>> +		tc.z1 = tsc2007_xfer(tsc, READ_Z1);
>>> +		tc.z2 = tsc2007_xfer(tsc, READ_Z2);
>>> +		*val = tsc2007_calculate_resistance(tsc, &tc);
>>> +		break;
>>> +	}
>>> +	case 6:
>>> +		*val = tsc2007_is_pen_down(tsc);
>>> +		break;
>>> +	case 7:
>>> +		*val = tsc2007_xfer(tsc,
>>> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
>>> +		break;
>>> +	case 8:
>>> +		*val = tsc2007_xfer(tsc,
>>> +				    (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
>>> +		break;
>>> +	}
>>> +
>>> +	/* Prepare for next touch reading - power down ADC, enable PENIRQ */
>>> +	tsc2007_xfer(tsc, PWRDOWN);
>>> +
>>> +	mutex_unlock(&tsc->mlock);
>>> +
>>> +	ret = IIO_VAL_INT;
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +static const struct iio_info tsc2007_iio_info = {
>>> +	.read_raw = tsc2007_read_raw,
>>> +	.driver_module = THIS_MODULE,
>>> +};
>>> +
>>> +int tsc2007_iio_configure(struct tsc2007 *ts)
>>> +{
>>> +	int err;
>>> +	struct iio_dev *indio_dev;
>>> +	struct tsc2007_iio *iio;
>>> +
>>> +	indio_dev = devm_iio_device_alloc(&ts->client->dev,
>>> +		sizeof(struct tsc2007_iio));
>>> +	if (!indio_dev) {
>>> +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	iio = iio_priv(indio_dev);
>>> +	iio->ts = ts;
>>> +	ts->iio_dev = (void *) indio_dev;
>>> +
>>> +	indio_dev->name = "tsc2007";
>>> +	indio_dev->dev.parent = &ts->client->dev;
>>> +	indio_dev->info = &tsc2007_iio_info;
>>> +	indio_dev->modes = INDIO_DIRECT_MODE;
>>> +	indio_dev->channels = tsc2007_iio_channel;
>>> +	indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
>>> +
>>> +	err = iio_device_register(indio_dev);
> 
> Changed this to devm.
> 
>>> +	if (err < 0) {
>>> +		dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
>>> +			err);
>>> +		return err;
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL(tsc2007_iio_configure);
> 
> This is not a separate module, there is no need to export this symbol.
> 
>>> +
>>> +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
>>> +{
>>> +	struct iio_dev *indio_dev = ts->iio_dev;
>>> +
>>> +	iio_device_unregister(indio_dev);
>>> +}
>>> +EXPORT_SYMBOL(tsc2007_iio_unconfigure);
> 
> Dropped this as not needed with devm.
> 
> -- 
> Dmitry

Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

> Am 17.02.2017 um 22:27 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> On Fri, Dec 30, 2016 at 08:36:30PM +0000, Jonathan Cameron wrote:
>> On 28/12/16 14:53, H. Nikolaus Schaller wrote:
>>> The tsc2007 chip not only has a resistive touch screen controller =
but
>>> also an external AUX adc imput which can be used for an ambient
>>> light sensor, battery voltage monitoring or any general purpose.
>>>=20
>>> Additionally it can measure the chip temperature.
>>>=20
>>> This extension provides an iio interface for these adc channels.
>>>=20
>>> Since it is not wasting much resources and is very straightforward,
>>> we simply provide all other adc channels as optional iio interfaces
>>> as weel. This can be used for debugging or special applications.
>>>=20
>>> This patch also splits the tsc2007 driver in several source files:
>>> tsc2007.h -- constants, structs and stubs
>>> tsc2007_core.c -- functional parts of the original driver
>>> tsc2007_iio.c -- the optional iio stuff
>>>=20
>>> Makefile magic allows to conditionally link the iio stuff
>>> if CONFIG_IIO=3Dy or =3Dm in a way that it works with
>>> CONFIG_TOUCHSCREEN_TSC2007=3Dm.
>>>=20
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> Reviewed-by: Jonathan Cameron <jic23@kernel.org>
>> Just for the record, I'm happy with the few changes from earlier =
versions.
>=20
> I untangled this from the rest of the patches (as it turned out to be
> the least controversial ;) ) and applied with some minor changes (see
> below). Please take a look at my tsc2007 branch on kernel.org to see =
if
> I missed anything.

Looks good!

BR and thanks,
Nikolaus

>=20
> Thanks.
>=20
>>=20
>> Jonathan
>>> ---
>>> drivers/input/touchscreen/Kconfig                  |  10 ++
>>> drivers/input/touchscreen/Makefile                 |   2 +
>>> drivers/input/touchscreen/tsc2007.h                | 116 =
++++++++++++++++
>>> .../touchscreen/{tsc2007.c =3D> tsc2007_core.c}      |  95 =
+++----------
>>> drivers/input/touchscreen/tsc2007_iio.c            | 150 =
+++++++++++++++++++++
>>> 5 files changed, 299 insertions(+), 74 deletions(-)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c =3D> tsc2007_core.c} =
(86%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>=20
>>> diff --git a/drivers/input/touchscreen/Kconfig =
b/drivers/input/touchscreen/Kconfig
>>> index efca013..1616a8d 100644
>>> --- a/drivers/input/touchscreen/Kconfig
>>> +++ b/drivers/input/touchscreen/Kconfig
>>> @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
>>> 	  To compile this driver as a module, choose M here: the
>>> 	  module will be called tsc2007.
>>>=20
>>> +config TOUCHSCREEN_TSC2007_IIO
>>> +	bool "IIO interface for external ADC input and temperature"
>>> +	depends on TOUCHSCREEN_TSC2007
>>> +	depends on IIO=3Dy || IIO=3DTOUCHSCREEN_TSC2007
>>> +	help
>>> +	  Saying Y here adds an iio interface to the tsc2007 which
>>> +	  provides values for the AUX input (used for e.g. battery
>>> +	  or ambient light monitoring), temperature and raw input
>>> +	  values.
>>> +
>>> config TOUCHSCREEN_W90X900
>>> 	tristate "W90P910 touchscreen driver"
>>> 	depends on ARCH_W90X900
>>> diff --git a/drivers/input/touchscreen/Makefile =
b/drivers/input/touchscreen/Makefile
>>> index 81b8645..05d1cc8 100644
>>> --- a/drivers/input/touchscreen/Makefile
>>> +++ b/drivers/input/touchscreen/Makefile
>>> @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)	+=3D =
tsc40.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE)	+=3D tsc200x-core.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2004)	+=3D tsc2004.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2005)	+=3D tsc2005.o
>>> +tsc2007-y :=3D tsc2007_core.o
>>> +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO)	+=3D tsc2007_iio.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2007)	+=3D tsc2007.o
>>> obj-$(CONFIG_TOUCHSCREEN_UCB1400)	+=3D ucb1400_ts.o
>>> obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)	+=3D wacom_w8001.o
>>> diff --git a/drivers/input/touchscreen/tsc2007.h =
b/drivers/input/touchscreen/tsc2007.h
>>> new file mode 100644
>>> index 0000000..16efb60
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007.h
>>> @@ -0,0 +1,116 @@
>>> +/*
>>> + * Copyright (c) 2008 MtekVision Co., Ltd.
>>> + *	Kwangwoo Lee <kwlee@mtekvision.com>
>>> + *
>>> + * Using code from:
>>> + *  - ads7846.c
>>> + *	Copyright (c) 2005 David Brownell
>>> + *	Copyright (c) 2006 Nokia Corporation
>>> + *  - corgi_ts.c
>>> + *	Copyright (C) 2004-2005 Richard Purdie
>>> + *  - omap_ts.[hc], ads7846.h, ts_osk.c
>>> + *	Copyright (C) 2002 MontaVista Software
>>> + *	Copyright (C) 2004 Texas Instruments
>>> + *	Copyright (C) 2005 Dirk Behme
>>> + *
>>> + *  This program is free software; you can redistribute it and/or =
modify
>>> + *  it under the terms of the GNU General Public License version 2 =
as
>>> + *  published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/input/touchscreen.h>
>>> +
>>> +#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>>> +#define TSC2007_MEASURE_AUX		(0x2 << 4)
>>> +#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
>>> +#define TSC2007_ACTIVATE_XN		(0x8 << 4)
>>> +#define TSC2007_ACTIVATE_YN		(0x9 << 4)
>>> +#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
>>> +#define TSC2007_SETUP			(0xb << 4)
>>> +#define TSC2007_MEASURE_X		(0xc << 4)
>>> +#define TSC2007_MEASURE_Y		(0xd << 4)
>>> +#define TSC2007_MEASURE_Z1		(0xe << 4)
>>> +#define TSC2007_MEASURE_Z2		(0xf << 4)
>>> +
>>> +#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
>>> +#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
>>> +#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
>>> +#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
>>> +
>>> +#define TSC2007_12BIT			(0x0 << 1)
>>> +#define TSC2007_8BIT			(0x1 << 1)
>>> +
>>> +#define	MAX_12BIT			((1 << 12) - 1)
>>> +
>>> +#define ADC_ON_12BIT	(TSC2007_12BIT | =
TSC2007_ADC_ON_IRQ_DIS0)
>>> +
>>> +#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
>>> +#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
>>> +#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
>>> +#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
>>> +#define PWRDOWN		(TSC2007_12BIT | =
TSC2007_POWER_OFF_IRQ_EN)
>>> +
>>> +struct ts_event {
>>> +	u16	x;
>>> +	u16	y;
>>> +	u16	z1, z2;
>>> +};
>>> +
>>> +struct tsc2007 {
>>> +	struct input_dev	*input;
>>> +	char			phys[32];
>>> +
>>> +	struct i2c_client	*client;
>>> +
>>> +	u16			model;
>>> +	u16			x_plate_ohms;
>>> +
>>> +	struct touchscreen_properties prop;
>>> +
>>> +	bool			report_resistance;
>>> +	u16			min_x;
>>> +	u16			min_y;
>>> +	u16			max_x;
>>> +	u16			max_y;
>>> +	u16			max_rt;
>>> +	unsigned long		poll_period; /* in jiffies */
>>> +	int			fuzzx;
>>> +	int			fuzzy;
>>> +	int			fuzzz;
>>> +
>>> +	unsigned int		gpio;
>>> +	int			irq;
>>> +
>>> +	wait_queue_head_t	wait;
>>> +	bool			stopped;
>>> +	bool			pendown;
>>> +
>>> +	int			(*get_pendown_state)(struct device *);
>>> +	void			(*clear_penirq)(void);
>>> +
>>> +	struct mutex		mlock;
>>> +	struct iio_dev		*iio_dev;	/* optional */
>>> +};
>>> +
>>> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
>>> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> +					struct ts_event *tc);
>>> +bool tsc2007_is_pen_down(struct tsc2007 *ts);
>>> +
>>> +#if IS_ENABLED(CONFIG_TOUCHSCREEN_TSC2007_IIO)
>>> +
>>> +/* defined in tsc2007_iio.c */
>>> +int tsc2007_iio_configure(struct tsc2007 *ts);
>>> +void tsc2007_iio_unconfigure(struct tsc2007 *ts);
>>> +
>>> +#else /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
>>> +
>>> +static inline int tsc2007_iio_configure(struct tsc2007 *ts)
>>> +{
>>> +	return 0;
>>> +}
>>> +static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
>>> +{
>>> +}
>>> +
>>> +#endif /* CONFIG_TOUCHSCREEN_TSC2007_IIO */
>>> diff --git a/drivers/input/touchscreen/tsc2007.c =
b/drivers/input/touchscreen/tsc2007_core.c
>>> similarity index 86%
>>> rename from drivers/input/touchscreen/tsc2007.c
>>> rename to drivers/input/touchscreen/tsc2007_core.c
>>> index 76b462b..812ded8 100644
>>> --- a/drivers/input/touchscreen/tsc2007.c
>>> +++ b/drivers/input/touchscreen/tsc2007_core.c
>>> @@ -27,79 +27,11 @@
>>> #include <linux/i2c.h>
>>> #include <linux/i2c/tsc2007.h>
>>> #include <linux/of_device.h>
>>> -#include <linux/of.h>
>>> #include <linux/of_gpio.h>
>>> -#include <linux/input/touchscreen.h>
>>> -
>>> -#define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>>> -#define TSC2007_MEASURE_AUX		(0x2 << 4)
>>> -#define TSC2007_MEASURE_TEMP1		(0x4 << 4)
>>> -#define TSC2007_ACTIVATE_XN		(0x8 << 4)
>>> -#define TSC2007_ACTIVATE_YN		(0x9 << 4)
>>> -#define TSC2007_ACTIVATE_YP_XN		(0xa << 4)
>>> -#define TSC2007_SETUP			(0xb << 4)
>>> -#define TSC2007_MEASURE_X		(0xc << 4)
>>> -#define TSC2007_MEASURE_Y		(0xd << 4)
>>> -#define TSC2007_MEASURE_Z1		(0xe << 4)
>>> -#define TSC2007_MEASURE_Z2		(0xf << 4)
>>> -
>>> -#define TSC2007_POWER_OFF_IRQ_EN	(0x0 << 2)
>>> -#define TSC2007_ADC_ON_IRQ_DIS0		(0x1 << 2)
>>> -#define TSC2007_ADC_OFF_IRQ_EN		(0x2 << 2)
>>> -#define TSC2007_ADC_ON_IRQ_DIS1		(0x3 << 2)
>>> -
>>> -#define TSC2007_12BIT			(0x0 << 1)
>>> -#define TSC2007_8BIT			(0x1 << 1)
>>> -
>>> -#define	MAX_12BIT			((1 << 12) - 1)
>>> -
>>> -#define ADC_ON_12BIT	(TSC2007_12BIT | =
TSC2007_ADC_ON_IRQ_DIS0)
>>> -
>>> -#define READ_Y		(ADC_ON_12BIT | TSC2007_MEASURE_Y)
>>> -#define READ_Z1		(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
>>> -#define READ_Z2		(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
>>> -#define READ_X		(ADC_ON_12BIT | TSC2007_MEASURE_X)
>>> -#define PWRDOWN		(TSC2007_12BIT | =
TSC2007_POWER_OFF_IRQ_EN)
>>> -
>>> -struct ts_event {
>>> -	u16	x;
>>> -	u16	y;
>>> -	u16	z1, z2;
>>> -};
>>> -
>>> -struct tsc2007 {
>>> -	struct input_dev	*input;
>>> -	char			phys[32];
>>> -
>>> -	struct i2c_client	*client;
>>> -
>>> -	u16			model;
>>> -	u16			x_plate_ohms;
>>> -
>>> -	struct touchscreen_properties prop;
>>> -
>>> -	bool			report_resistance;
>>> -	u16			min_x;
>>> -	u16			min_y;
>>> -	u16			max_x;
>>> -	u16			max_y;
>>> -	u16			max_rt;
>>> -	unsigned long		poll_period; /* in jiffies */
>>> -	int			fuzzx;
>>> -	int			fuzzy;
>>> -	int			fuzzz;
>>> -
>>> -	unsigned		gpio;
>>> -	int			irq;
>>> -
>>> -	wait_queue_head_t	wait;
>>> -	bool			stopped;
>>> +#include "tsc2007.h"
>>>=20
>>> -	int			(*get_pendown_state)(struct device *);
>>> -	void			(*clear_penirq)(void);
>>> -};
>>>=20
>>> -static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>>> +int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>>> {
>>> 	s32 data;
>>> 	u16 val;
>>> @@ -137,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 =
*tsc, struct ts_event *tc)
>>> 	tsc2007_xfer(tsc, PWRDOWN);
>>> }
>>>=20
>>> -static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>=20
> Kept as tsc2007_calculate_resistance for now.
>=20
>>> +u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
>>> 					struct ts_event *tc)
>>> {
>>> 	u32 rt =3D 0;
>>> @@ -158,7 +90,7 @@ static u32 tsc2007_calculate_resistance(struct =
tsc2007 *tsc,
>>> 	return rt;
>>> }
>>>=20
>>> -static bool tsc2007_is_pen_down(struct tsc2007 *ts)
>>> +bool tsc2007_is_pen_down(struct tsc2007 *ts)
>>> {
>>> 	/*
>>> 	 * NOTE: We can't rely on the pressure to determine the pen down
>>> @@ -191,7 +123,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, =
void *handle)
>>> 	while (!ts->stopped && tsc2007_is_pen_down(ts)) {
>>>=20
>>> 		/* pen is down, continue with the measurement */
>>> +
>>> +		mutex_lock(&ts->mlock);
>>> 		tsc2007_read_values(ts, &tc);
>>> +		mutex_unlock(&ts->mlock);
>>>=20
>>> 		rt =3D tsc2007_calculate_resistance(ts, &tc);
>>>=20
>>> @@ -441,7 +376,8 @@ static void tsc2007_call_exit_platform_hw(void =
*data)
>>> static int tsc2007_probe(struct i2c_client *client,
>>> 			 const struct i2c_device_id *id)
>>> {
>>> -	const struct tsc2007_platform_data *pdata =3D =
dev_get_platdata(&client->dev);
>>> +	const struct tsc2007_platform_data *pdata =3D
>>> +		dev_get_platdata(&client->dev);
>>> 	struct tsc2007 *ts;
>>> 	struct input_dev *input_dev;
>>> 	int err;
>>> @@ -463,7 +399,9 @@ static int tsc2007_probe(struct i2c_client =
*client,
>>> 	ts->client =3D client;
>>> 	ts->irq =3D client->irq;
>>> 	ts->input =3D input_dev;
>>> +
>>> 	init_waitqueue_head(&ts->wait);
>>> +	mutex_init(&ts->mlock);
>>>=20
>>> 	snprintf(ts->phys, sizeof(ts->phys),
>>> 		 "%s/input0", dev_name(&client->dev));
>>> @@ -534,7 +472,7 @@ static int tsc2007_probe(struct i2c_client =
*client,
>>> 	if (err < 0) {
>>> 		dev_err(&client->dev,
>>> 			"Failed to setup chip: %d\n", err);
>>> -		return err;	/* usually, chip does not respond */
>>> +		return err;	/* chip does not respond */
>>> 	}
>>>=20
>>> 	err =3D input_register_device(input_dev);
>>> @@ -544,6 +482,14 @@ static int tsc2007_probe(struct i2c_client =
*client,
>>> 		return err;
>>> 	}
>>>=20
>>> +	return tsc2007_iio_configure(ts);
>>> +}
>>> +
>>> +static int tsc2007_remove(struct i2c_client *client)
>>> +{
>>> +	struct tsc2007 *ts =3D i2c_get_clientdata(client);
>>> +
>>> +	tsc2007_iio_unconfigure(ts);
>>> 	return 0;
>>> }
>>>=20
>>> @@ -569,6 +515,7 @@ static struct i2c_driver tsc2007_driver =3D {
>>> 	},
>>> 	.id_table	=3D tsc2007_idtable,
>>> 	.probe		=3D tsc2007_probe,
>>> +	.remove		=3D tsc2007_remove,
>>> };
>>>=20
>>> module_i2c_driver(tsc2007_driver);
>>> diff --git a/drivers/input/touchscreen/tsc2007_iio.c =
b/drivers/input/touchscreen/tsc2007_iio.c
>>> new file mode 100644
>>> index 0000000..ed79944
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007_iio.c
>>> @@ -0,0 +1,150 @@
>>> +/*
>>> + * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
>>> + *	Nikolaus Schaller <hns@goldelico.com>
>>> + *
>>> + *  This program is free software; you can redistribute it and/or =
modify
>>> + *  it under the terms of the GNU General Public License version 2 =
as
>>> + *  published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/i2c.h>
>>> +#include <linux/iio/iio.h>
>>> +#include "tsc2007.h"
>>> +
>>> +struct tsc2007_iio {
>>> +	struct tsc2007 *ts;
>>> +};
>>> +
>>> +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
>>> +{ \
>>> +	.datasheet_name =3D _name, \
>>> +	.type =3D _type, \
>>> +	.info_mask_separate =3D BIT(IIO_CHAN_INFO_RAW) |	\
>>> +			BIT(_chan_info), \
>>> +	.indexed =3D 1, \
>>> +	.channel =3D _chan, \
>>> +}
>>> +
>>> +static const struct iio_chan_spec tsc2007_iio_channel[] =3D {
>>> +	TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* =
Ohms? */
>>> +	TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
>>> +	TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
>>> +};
>>> +
>>> +static int tsc2007_read_raw(struct iio_dev *indio_dev,
>>> +	struct iio_chan_spec const *chan, int *val, int *val2, long =
mask)
>>> +{
>>> +	struct tsc2007_iio *iio =3D iio_priv(indio_dev);
>>> +	struct tsc2007 *tsc =3D iio->ts;
>>> +	int adc_chan =3D chan->channel;
>>> +	int ret =3D 0;
>>> +
>>> +	if (adc_chan >=3D ARRAY_SIZE(tsc2007_iio_channel))
>>> +		return -EINVAL;
>>> +
>>> +	if (mask !=3D IIO_CHAN_INFO_RAW)
>>> +		return -EINVAL;
>>> +
>>> +	mutex_lock(&tsc->mlock);
>>> +
>>> +	switch (chan->channel) {
>>> +	case 0:
>>> +		*val =3D tsc2007_xfer(tsc, READ_X);
>>> +		break;
>>> +	case 1:
>>> +		*val =3D tsc2007_xfer(tsc, READ_Y);
>>> +		break;
>>> +	case 2:
>>> +		*val =3D tsc2007_xfer(tsc, READ_Z1);
>>> +		break;
>>> +	case 3:
>>> +		*val =3D tsc2007_xfer(tsc, READ_Z2);
>>> +		break;
>>> +	case 4:
>>> +		*val =3D tsc2007_xfer(tsc, (ADC_ON_12BIT | =
TSC2007_MEASURE_AUX));
>>> +		break;
>>> +	case 5: {
>>> +		struct ts_event tc;
>>> +
>>> +		tc.x =3D tsc2007_xfer(tsc, READ_X);
>>> +		tc.z1 =3D tsc2007_xfer(tsc, READ_Z1);
>>> +		tc.z2 =3D tsc2007_xfer(tsc, READ_Z2);
>>> +		*val =3D tsc2007_calculate_resistance(tsc, &tc);
>>> +		break;
>>> +	}
>>> +	case 6:
>>> +		*val =3D tsc2007_is_pen_down(tsc);
>>> +		break;
>>> +	case 7:
>>> +		*val =3D tsc2007_xfer(tsc,
>>> +				    (ADC_ON_12BIT | =
TSC2007_MEASURE_TEMP0));
>>> +		break;
>>> +	case 8:
>>> +		*val =3D tsc2007_xfer(tsc,
>>> +				    (ADC_ON_12BIT | =
TSC2007_MEASURE_TEMP1));
>>> +		break;
>>> +	}
>>> +
>>> +	/* Prepare for next touch reading - power down ADC, enable =
PENIRQ */
>>> +	tsc2007_xfer(tsc, PWRDOWN);
>>> +
>>> +	mutex_unlock(&tsc->mlock);
>>> +
>>> +	ret =3D IIO_VAL_INT;
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +static const struct iio_info tsc2007_iio_info =3D {
>>> +	.read_raw =3D tsc2007_read_raw,
>>> +	.driver_module =3D THIS_MODULE,
>>> +};
>>> +
>>> +int tsc2007_iio_configure(struct tsc2007 *ts)
>>> +{
>>> +	int err;
>>> +	struct iio_dev *indio_dev;
>>> +	struct tsc2007_iio *iio;
>>> +
>>> +	indio_dev =3D devm_iio_device_alloc(&ts->client->dev,
>>> +		sizeof(struct tsc2007_iio));
>>> +	if (!indio_dev) {
>>> +		dev_err(&ts->client->dev, "iio_device_alloc failed\n");
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	iio =3D iio_priv(indio_dev);
>>> +	iio->ts =3D ts;
>>> +	ts->iio_dev =3D (void *) indio_dev;
>>> +
>>> +	indio_dev->name =3D "tsc2007";
>>> +	indio_dev->dev.parent =3D &ts->client->dev;
>>> +	indio_dev->info =3D &tsc2007_iio_info;
>>> +	indio_dev->modes =3D INDIO_DIRECT_MODE;
>>> +	indio_dev->channels =3D tsc2007_iio_channel;
>>> +	indio_dev->num_channels =3D ARRAY_SIZE(tsc2007_iio_channel);
>>> +
>>> +	err =3D iio_device_register(indio_dev);
>=20
> Changed this to devm.
>=20
>>> +	if (err < 0) {
>>> +		dev_err(&ts->client->dev, "iio_device_register() failed: =
%d\n",
>>> +			err);
>>> +		return err;
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL(tsc2007_iio_configure);
>=20
> This is not a separate module, there is no need to export this symbol.
>=20
>>> +
>>> +void tsc2007_iio_unconfigure(struct tsc2007 *ts)
>>> +{
>>> +	struct iio_dev *indio_dev =3D ts->iio_dev;
>>> +
>>> +	iio_device_unregister(indio_dev);
>>> +}
>>> +EXPORT_SYMBOL(tsc2007_iio_unconfigure);
>=20
> Dropped this as not needed with devm.
>=20
> --=20
> Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

> > And I agree that kernel should _not_ attempt rescaling itself, as it
> > would lose precision.
> 
> With an almost 1:1 mapping you won't loose precision.

How do you propose to do that?
									Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

> > And I agree that kernel should _not_ attempt rescaling itself, as it
> > would lose precision.
> 
> With an almost 1:1 mapping you won't loose precision.

How do you propose to do that?
									Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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


> Am 18.02.2017 um 19:08 schrieb Pavel Machek <pavel@ucw.cz>:
> 
>>> And I agree that kernel should _not_ attempt rescaling itself, as it
>>> would lose precision.
>> 
>> With an almost 1:1 mapping you won't loose precision.
> 
> How do you propose to do that?

something like

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00

but I think it is the default of X11 if you use no coordinate transformation at all.
And having the kernel to properly scale from ADC values to screen coordinates.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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


> Am 18.02.2017 um 19:08 schrieb Pavel Machek <pavel@ucw.cz>:
> 
>>> And I agree that kernel should _not_ attempt rescaling itself, as it
>>> would lose precision.
>> 
>> With an almost 1:1 mapping you won't loose precision.
> 
> How do you propose to do that?

something like

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00

but I think it is the default of X11 if you use no coordinate transformation at all.
And having the kernel to properly scale from ADC values to screen coordinates.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

On Sat 2017-02-18 20:17:09, H. Nikolaus Schaller wrote:
> 
> > Am 18.02.2017 um 19:08 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> >>> And I agree that kernel should _not_ attempt rescaling itself, as it
> >>> would lose precision.
> >> 
> >> With an almost 1:1 mapping you won't loose precision.
> > 
> > How do you propose to do that?
> 
> something like
> 
> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00
> 
> but I think it is the default of X11 if you use no coordinate transformation at all.
> And having the kernel to properly scale from ADC values to screen coordinates.
> 

No. How do you propose doing rescaling in the kernel without loosing
precision?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

On Sat 2017-02-18 20:17:09, H. Nikolaus Schaller wrote:
> 
> > Am 18.02.2017 um 19:08 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> >>> And I agree that kernel should _not_ attempt rescaling itself, as it
> >>> would lose precision.
> >> 
> >> With an almost 1:1 mapping you won't loose precision.
> > 
> > How do you propose to do that?
> 
> something like
> 
> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00
> 
> but I think it is the default of X11 if you use no coordinate transformation at all.
> And having the kernel to properly scale from ADC values to screen coordinates.
> 

No. How do you propose doing rescaling in the kernel without loosing
precision?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

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

Hi,

On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
> Hi Sebastian,
> 
> > Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre@kernel.org>:
> > 
> > Hi,
> > 
> > On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> >>> AFAIK there is no mainline board using the DT except ours (and the upcoming
> >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> >>> compatibility property. We don't need it for our devices.
> > 
> > $ cd linux.git/arch
> > $ git grep -l tsc2004
> > arm/boot/dts/imx6qdl-nit6xlite.dtsi
> > arm/boot/dts/imx7d-nitrogen7.dts
> > arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> > arm/boot/dts/omap4-var-som-om44.dtsi
> > $ git grep -l tsc2005
> > arm/boot/dts/omap3-n900.dts
> 
> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't
> share code.

Yes, I'm aware.

> Hence the N900 is not influenced by this patch series.
> If it has a similar issue, it should be fixed of course.

Right. I added them to see every board affect by the patch suggested
by me in my last paragraph.

> > $ git grep -l tsc2007
> > arm/boot/dts/imx28-tx28.dts
> > arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
> > arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
> > arm/boot/dts/imx53-tx53-x03x.dts
> > arm/boot/dts/imx6qdl-tx6.dtsi
> > arm/boot/dts/imx6ul-tx6ul.dtsi
> > arm/boot/dts/omap3-gta04.dtsi
> > sh/boards/mach-ecovec24/setup.c
> 
> Sorry, I was a little imprecise here, because I looked for the min/max properties.
> Of course, the imx devices use the tsc2007 as well.
>
> Maybe we should edit all these DTS and set the "ti,report-resistance" property
> by default. Then, no user should notice a difference.

I suggest to create a patch without the report-reistance stuff and
add it early after the merge window and see what happens. If no
users notices anything the change is not an ABI break from kernel's
PoV.

> Is any user/maintainer of these devices following this discussion and can comment?
>
> > 
> >> You seem to be treating DT data as something very fluid, which is wrong.
> >> You need to treat it as a firmware, unlikely to change once device is
> >> shipped. Unlike legacy platform data, the fact that DTS files are not
> >> present in mainline does not mean that we can ignore such users and
> >> change behavior at will.
> >> 
> >> That said, if driver behavior is out of line from the subsystem
> >> expectations, we need to fix it.
> >> 
> >> 
> >>> That the function name is wrong is a second issue and this double negation might
> >>> confuse a litte.
> >>> 
> >>> Please test on a real device if the patched driver reports pressure now (unless
> >>> ti,report-resistance is specified).
> >> 
> >> I unfortunately can not test this driver as I do not have the hardware.
> >> So all my observations are from code and data sheets.
> >> 
> >> That said, what is the values emitted as ABS_PRESSURE when finger is not
> >> touching the device, barely touching the device, or pressing firmly?
> >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> >> confusion as to what is being reported.
> > 
> > As far as I can see all calculate Rtouch and ADS7846 reports
> > (Rmax - Rtouch), which looks sensible.
> 
> I don't see where this subtraction from Rmax takes place for the tsc2007:
> 
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131

sorry if I wrote this ambiguous, let me split my sentence

1. tsc200x & ads7846 calculate Rtouch
2. ads7846 reports Rmax - Rtouch
(3. tsc200x does not, it reports Rtouch instead)
4. ads7846 behaviour looks sensible to me

> >> I am adding a few more folks to the CC so we can try and soft this out.
> >> Sebastian, Pali, Pavel, any input here?
> > 
> > I think tsc200x works, since usually userspace is Xorg and I think
> > it only cares for x/y coordinates + boolean pressure. Since
> > no-pressure is correctly reported as 0, everything works as
> > expected.
> 
> No pressure is usually treated as a special case in these drivers,
> so reduction to "boolean" in user-space works well by accident and
> might still hide a bug.

That's what I assumed.

Btw. how did you notice that tsc2007 sends "inverted" pressure values?
Just in evtest or in some non-development application? (Just asking because
the behavour obviously changes at least for that usecase)

> > I currently don't have X running on my N900 due some
> > omapdrm bug, so I can't test this, sorry.
> 
> I usually look with evtest if ABS_PRESSURE is monotonic.

That would not have helped to check if X handles the touchscreen in
a boolean way. I can provide some N900 evtest data, though (tomorrow,
I don't have my dev N900 with me at the moment).

> > I suggest to put the resistance vs pressure thing in its own patch,
> > that also fixes tsc200x-core and merge it to linux-next after the
> > merge window.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

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

Hi,

On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
> Hi Sebastian,
> 
> > Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> > 
> > Hi,
> > 
> > On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> >>> AFAIK there is no mainline board using the DT except ours (and the upcoming
> >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> >>> compatibility property. We don't need it for our devices.
> > 
> > $ cd linux.git/arch
> > $ git grep -l tsc2004
> > arm/boot/dts/imx6qdl-nit6xlite.dtsi
> > arm/boot/dts/imx7d-nitrogen7.dts
> > arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> > arm/boot/dts/omap4-var-som-om44.dtsi
> > $ git grep -l tsc2005
> > arm/boot/dts/omap3-n900.dts
> 
> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't
> share code.

Yes, I'm aware.

> Hence the N900 is not influenced by this patch series.
> If it has a similar issue, it should be fixed of course.

Right. I added them to see every board affect by the patch suggested
by me in my last paragraph.

> > $ git grep -l tsc2007
> > arm/boot/dts/imx28-tx28.dts
> > arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
> > arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
> > arm/boot/dts/imx53-tx53-x03x.dts
> > arm/boot/dts/imx6qdl-tx6.dtsi
> > arm/boot/dts/imx6ul-tx6ul.dtsi
> > arm/boot/dts/omap3-gta04.dtsi
> > sh/boards/mach-ecovec24/setup.c
> 
> Sorry, I was a little imprecise here, because I looked for the min/max properties.
> Of course, the imx devices use the tsc2007 as well.
>
> Maybe we should edit all these DTS and set the "ti,report-resistance" property
> by default. Then, no user should notice a difference.

I suggest to create a patch without the report-reistance stuff and
add it early after the merge window and see what happens. If no
users notices anything the change is not an ABI break from kernel's
PoV.

> Is any user/maintainer of these devices following this discussion and can comment?
>
> > 
> >> You seem to be treating DT data as something very fluid, which is wrong.
> >> You need to treat it as a firmware, unlikely to change once device is
> >> shipped. Unlike legacy platform data, the fact that DTS files are not
> >> present in mainline does not mean that we can ignore such users and
> >> change behavior at will.
> >> 
> >> That said, if driver behavior is out of line from the subsystem
> >> expectations, we need to fix it.
> >> 
> >> 
> >>> That the function name is wrong is a second issue and this double negation might
> >>> confuse a litte.
> >>> 
> >>> Please test on a real device if the patched driver reports pressure now (unless
> >>> ti,report-resistance is specified).
> >> 
> >> I unfortunately can not test this driver as I do not have the hardware.
> >> So all my observations are from code and data sheets.
> >> 
> >> That said, what is the values emitted as ABS_PRESSURE when finger is not
> >> touching the device, barely touching the device, or pressing firmly?
> >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> >> confusion as to what is being reported.
> > 
> > As far as I can see all calculate Rtouch and ADS7846 reports
> > (Rmax - Rtouch), which looks sensible.
> 
> I don't see where this subtraction from Rmax takes place for the tsc2007:
> 
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131

sorry if I wrote this ambiguous, let me split my sentence

1. tsc200x & ads7846 calculate Rtouch
2. ads7846 reports Rmax - Rtouch
(3. tsc200x does not, it reports Rtouch instead)
4. ads7846 behaviour looks sensible to me

> >> I am adding a few more folks to the CC so we can try and soft this out.
> >> Sebastian, Pali, Pavel, any input here?
> > 
> > I think tsc200x works, since usually userspace is Xorg and I think
> > it only cares for x/y coordinates + boolean pressure. Since
> > no-pressure is correctly reported as 0, everything works as
> > expected.
> 
> No pressure is usually treated as a special case in these drivers,
> so reduction to "boolean" in user-space works well by accident and
> might still hide a bug.

That's what I assumed.

Btw. how did you notice that tsc2007 sends "inverted" pressure values?
Just in evtest or in some non-development application? (Just asking because
the behavour obviously changes at least for that usecase)

> > I currently don't have X running on my N900 due some
> > omapdrm bug, so I can't test this, sorry.
> 
> I usually look with evtest if ABS_PRESSURE is monotonic.

That would not have helped to check if X handles the touchscreen in
a boolean way. I can provide some N900 evtest data, though (tomorrow,
I don't have my dev N900 with me at the moment).

> > I suggest to put the resistance vs pressure thing in its own patch,
> > that also fixes tsc200x-core and merge it to linux-next after the
> > merge window.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 18.02.2017 um 23:54 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Sat 2017-02-18 20:17:09, H. Nikolaus Schaller wrote:
>> 
>>> Am 18.02.2017 um 19:08 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>>>> And I agree that kernel should _not_ attempt rescaling itself, as it
>>>>> would lose precision.
>>>> 
>>>> With an almost 1:1 mapping you won't loose precision.
>>> 
>>> How do you propose to do that?
>> 
>> something like
>> 
>> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00
>> 
>> but I think it is the default of X11 if you use no coordinate transformation at all.
>> And having the kernel to properly scale from ADC values to screen coordinates.
>> 
> 
> No. How do you propose doing rescaling in the kernel without loosing
> precision?

I wonder how it works with your setting

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00

This obviously also assumes that the input events report pixel coordinates or you would have factors not close to 0.00 and 1.00.
It just aligns the touch with the screen, i.e. calibrates. Or your example was incomplete.

About loosing precision: there is already noise (jitter) in real-world devices so that you can't achieve subpixel precision anyways (unless your panel has a very low resolution). Please see my answer to Dmitry some mails ago.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 18.02.2017 um 23:54 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> On Sat 2017-02-18 20:17:09, H. Nikolaus Schaller wrote:
>> 
>>> Am 18.02.2017 um 19:08 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
>>> 
>>>>> And I agree that kernel should _not_ attempt rescaling itself, as it
>>>>> would lose precision.
>>>> 
>>>> With an almost 1:1 mapping you won't loose precision.
>>> 
>>> How do you propose to do that?
>> 
>> something like
>> 
>> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00
>> 
>> but I think it is the default of X11 if you use no coordinate transformation at all.
>> And having the kernel to properly scale from ADC values to screen coordinates.
>> 
> 
> No. How do you propose doing rescaling in the kernel without loosing
> precision?

I wonder how it works with your setting

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00

This obviously also assumes that the input events report pixel coordinates or you would have factors not close to 0.00 and 1.00.
It just aligns the touch with the screen, i.e. calibrates. Or your example was incomplete.

About loosing precision: there is already noise (jitter) in real-world devices so that you can't achieve subpixel precision anyways (unless your panel has a very low resolution). Please see my answer to Dmitry some mails ago.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Sebastian,

> Am 19.02.2017 um 00:44 schrieb Sebastian Reichel <sre@kernel.org>:
> 
> Hi,
> 
> On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
>> Hi Sebastian,
>> 
>>> Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre@kernel.org>:
>>> 
>>> Hi,
>>> 
>>> On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
>>>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>>>> compatibility property. We don't need it for our devices.
>>> 
>>> $ cd linux.git/arch
>>> $ git grep -l tsc2004
>>> arm/boot/dts/imx6qdl-nit6xlite.dtsi
>>> arm/boot/dts/imx7d-nitrogen7.dts
>>> arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
>>> arm/boot/dts/omap4-var-som-om44.dtsi
>>> $ git grep -l tsc2005
>>> arm/boot/dts/omap3-n900.dts
>> 
>> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't
>> share code.
> 
> Yes, I'm aware.
> 
>> Hence the N900 is not influenced by this patch series.
>> If it has a similar issue, it should be fixed of course.
> 
> Right. I added them to see every board affect by the patch suggested
> by me in my last paragraph.

Ok!

> 
>>> $ git grep -l tsc2007
>>> arm/boot/dts/imx28-tx28.dts
>>> arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
>>> arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
>>> arm/boot/dts/imx53-tx53-x03x.dts
>>> arm/boot/dts/imx6qdl-tx6.dtsi
>>> arm/boot/dts/imx6ul-tx6ul.dtsi
>>> arm/boot/dts/omap3-gta04.dtsi
>>> sh/boards/mach-ecovec24/setup.c
>> 
>> Sorry, I was a little imprecise here, because I looked for the min/max properties.
>> Of course, the imx devices use the tsc2007 as well.
>> 
>> Maybe we should edit all these DTS and set the "ti,report-resistance" property
>> by default. Then, no user should notice a difference.
> 
> I suggest to create a patch without the report-reistance stuff and
> add it early after the merge window and see what happens. If no
> users notices anything the change is not an ABI break from kernel's
> PoV.

That looks like a good strategy.

> 
>> Is any user/maintainer of these devices following this discussion and can comment?
>> 
>>> 
>>>> You seem to be treating DT data as something very fluid, which is wrong.
>>>> You need to treat it as a firmware, unlikely to change once device is
>>>> shipped. Unlike legacy platform data, the fact that DTS files are not
>>>> present in mainline does not mean that we can ignore such users and
>>>> change behavior at will.
>>>> 
>>>> That said, if driver behavior is out of line from the subsystem
>>>> expectations, we need to fix it.
>>>> 
>>>> 
>>>>> That the function name is wrong is a second issue and this double negation might
>>>>> confuse a litte.
>>>>> 
>>>>> Please test on a real device if the patched driver reports pressure now (unless
>>>>> ti,report-resistance is specified).
>>>> 
>>>> I unfortunately can not test this driver as I do not have the hardware.
>>>> So all my observations are from code and data sheets.
>>>> 
>>>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>>>> touching the device, barely touching the device, or pressing firmly?
>>>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>>>> confusion as to what is being reported.
>>> 
>>> As far as I can see all calculate Rtouch and ADS7846 reports
>>> (Rmax - Rtouch), which looks sensible.
>> 
>> I don't see where this subtraction from Rmax takes place for the tsc2007:
>> 
>> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131
> 
> sorry if I wrote this ambiguous, let me split my sentence
> 
> 1. tsc200x & ads7846 calculate Rtouch
> 2. ads7846 reports Rmax - Rtouch
> (3. tsc200x does not, it reports Rtouch instead)
> 4. ads7846 behaviour looks sensible to me

agreed.

> 
>>>> I am adding a few more folks to the CC so we can try and soft this out.
>>>> Sebastian, Pali, Pavel, any input here?
>>> 
>>> I think tsc200x works, since usually userspace is Xorg and I think
>>> it only cares for x/y coordinates + boolean pressure. Since
>>> no-pressure is correctly reported as 0, everything works as
>>> expected.
>> 
>> No pressure is usually treated as a special case in these drivers,
>> so reduction to "boolean" in user-space works well by accident and
>> might still hide a bug.
> 
> That's what I assumed.
> 
> Btw. how did you notice that tsc2007 sends "inverted" pressure values?
> Just in evtest or in some non-development application? (Just asking because
> the behavour obviously changes at least for that usecase)

I don't really remember when we noticed it first. Maybe it was back in tslib times
some years ago where setting the sensitivity threshold made problems. We then
carried along our patch for a long time in our local repo (and modified it
several times) and only started upstreaming some months ago. So it was included
but we never thought about it being something as important as the pre-calibration
which is really a benefit for setup and immediate useability of the whole system.
Hence we buried it a little in this pre-calibration, flipping and rotation patch.

> 
>>> I currently don't have X running on my N900 due some
>>> omapdrm bug, so I can't test this, sorry.
>> 
>> I usually look with evtest if ABS_PRESSURE is monotonic.
> 
> That would not have helped to check if X handles the touchscreen in
> a boolean way. I can provide some N900 evtest data, though (tomorrow,
> I don't have my dev N900 with me at the moment).

AFAIK, GIMP and for example https://sourceforge.net/projects/xournal/ appear
to be able to handle X pressure, but I haven't running and tested either one
on our devices. Pressure is used in such drawing tools to simulate that some
physical pens make wider strokes on higher pressure.

This seems to indicate that X can handle pressure in a non-boolean way, but rarely does.
Especially I think the usual menu, click, drag, scroll gestures are only based
on BTN_TOUCH status and not on ABS_PRESSURE. So it is rarely noticed to make
a difference.

> 
>>> I suggest to put the resistance vs pressure thing in its own patch,
>>> that also fixes tsc200x-core and merge it to linux-next after the
>>> merge window.

Ok. I will propose a patch.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Sebastian,

> Am 19.02.2017 um 00:44 schrieb Sebastian Reichel <sre@kernel.org>:
> 
> Hi,
> 
> On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
>> Hi Sebastian,
>> 
>>> Am 18.02.2017 um 04:22 schrieb Sebastian Reichel <sre@kernel.org>:
>>> 
>>> Hi,
>>> 
>>> On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
>>>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>>>> compatibility property. We don't need it for our devices.
>>> 
>>> $ cd linux.git/arch
>>> $ git grep -l tsc2004
>>> arm/boot/dts/imx6qdl-nit6xlite.dtsi
>>> arm/boot/dts/imx7d-nitrogen7.dts
>>> arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
>>> arm/boot/dts/omap4-var-som-om44.dtsi
>>> $ git grep -l tsc2005
>>> arm/boot/dts/omap3-n900.dts
>> 
>> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't
>> share code.
> 
> Yes, I'm aware.
> 
>> Hence the N900 is not influenced by this patch series.
>> If it has a similar issue, it should be fixed of course.
> 
> Right. I added them to see every board affect by the patch suggested
> by me in my last paragraph.

Ok!

> 
>>> $ git grep -l tsc2007
>>> arm/boot/dts/imx28-tx28.dts
>>> arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
>>> arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
>>> arm/boot/dts/imx53-tx53-x03x.dts
>>> arm/boot/dts/imx6qdl-tx6.dtsi
>>> arm/boot/dts/imx6ul-tx6ul.dtsi
>>> arm/boot/dts/omap3-gta04.dtsi
>>> sh/boards/mach-ecovec24/setup.c
>> 
>> Sorry, I was a little imprecise here, because I looked for the min/max properties.
>> Of course, the imx devices use the tsc2007 as well.
>> 
>> Maybe we should edit all these DTS and set the "ti,report-resistance" property
>> by default. Then, no user should notice a difference.
> 
> I suggest to create a patch without the report-reistance stuff and
> add it early after the merge window and see what happens. If no
> users notices anything the change is not an ABI break from kernel's
> PoV.

That looks like a good strategy.

> 
>> Is any user/maintainer of these devices following this discussion and can comment?
>> 
>>> 
>>>> You seem to be treating DT data as something very fluid, which is wrong.
>>>> You need to treat it as a firmware, unlikely to change once device is
>>>> shipped. Unlike legacy platform data, the fact that DTS files are not
>>>> present in mainline does not mean that we can ignore such users and
>>>> change behavior at will.
>>>> 
>>>> That said, if driver behavior is out of line from the subsystem
>>>> expectations, we need to fix it.
>>>> 
>>>> 
>>>>> That the function name is wrong is a second issue and this double negation might
>>>>> confuse a litte.
>>>>> 
>>>>> Please test on a real device if the patched driver reports pressure now (unless
>>>>> ti,report-resistance is specified).
>>>> 
>>>> I unfortunately can not test this driver as I do not have the hardware.
>>>> So all my observations are from code and data sheets.
>>>> 
>>>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>>>> touching the device, barely touching the device, or pressing firmly?
>>>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>>>> confusion as to what is being reported.
>>> 
>>> As far as I can see all calculate Rtouch and ADS7846 reports
>>> (Rmax - Rtouch), which looks sensible.
>> 
>> I don't see where this subtraction from Rmax takes place for the tsc2007:
>> 
>> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131
> 
> sorry if I wrote this ambiguous, let me split my sentence
> 
> 1. tsc200x & ads7846 calculate Rtouch
> 2. ads7846 reports Rmax - Rtouch
> (3. tsc200x does not, it reports Rtouch instead)
> 4. ads7846 behaviour looks sensible to me

agreed.

> 
>>>> I am adding a few more folks to the CC so we can try and soft this out.
>>>> Sebastian, Pali, Pavel, any input here?
>>> 
>>> I think tsc200x works, since usually userspace is Xorg and I think
>>> it only cares for x/y coordinates + boolean pressure. Since
>>> no-pressure is correctly reported as 0, everything works as
>>> expected.
>> 
>> No pressure is usually treated as a special case in these drivers,
>> so reduction to "boolean" in user-space works well by accident and
>> might still hide a bug.
> 
> That's what I assumed.
> 
> Btw. how did you notice that tsc2007 sends "inverted" pressure values?
> Just in evtest or in some non-development application? (Just asking because
> the behavour obviously changes at least for that usecase)

I don't really remember when we noticed it first. Maybe it was back in tslib times
some years ago where setting the sensitivity threshold made problems. We then
carried along our patch for a long time in our local repo (and modified it
several times) and only started upstreaming some months ago. So it was included
but we never thought about it being something as important as the pre-calibration
which is really a benefit for setup and immediate useability of the whole system.
Hence we buried it a little in this pre-calibration, flipping and rotation patch.

> 
>>> I currently don't have X running on my N900 due some
>>> omapdrm bug, so I can't test this, sorry.
>> 
>> I usually look with evtest if ABS_PRESSURE is monotonic.
> 
> That would not have helped to check if X handles the touchscreen in
> a boolean way. I can provide some N900 evtest data, though (tomorrow,
> I don't have my dev N900 with me at the moment).

AFAIK, GIMP and for example https://sourceforge.net/projects/xournal/ appear
to be able to handle X pressure, but I haven't running and tested either one
on our devices. Pressure is used in such drawing tools to simulate that some
physical pens make wider strokes on higher pressure.

This seems to indicate that X can handle pressure in a non-boolean way, but rarely does.
Especially I think the usual menu, click, drag, scroll gestures are only based
on BTN_TOUCH status and not on ABS_PRESSURE. So it is rarely noticed to make
a difference.

> 
>>> I suggest to put the resistance vs pressure thing in its own patch,
>>> that also fixes tsc200x-core and merge it to linux-next after the
>>> merge window.

Ok. I will propose a patch.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> About loosing precision: there is already noise (jitter) in
> real-world devices so that you can't achieve subpixel precision
> anyways (unless your panel has a very low resolution). Please see my
> answer to Dmitry some mails ago.

Maybe you can achieve better precision with averaging.

Anyway "input is already noisy" does not mean "so it is okay to
degrade it more". Solve it properly. That means passing calibration
data from kernel to userland.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> About loosing precision: there is already noise (jitter) in
> real-world devices so that you can't achieve subpixel precision
> anyways (unless your panel has a very low resolution). Please see my
> answer to Dmitry some mails ago.

Maybe you can achieve better precision with averaging.

Anyway "input is already noisy" does not mean "so it is okay to
degrade it more". Solve it properly. That means passing calibration
data from kernel to userland.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

HI Pavel,

> Am 19.02.2017 um 15:17 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>> About loosing precision: there is already noise (jitter) in
>> real-world devices so that you can't achieve subpixel precision
>> anyways (unless your panel has a very low resolution). Please see my
>> answer to Dmitry some mails ago.
> 
> Maybe you can achieve better precision with averaging.

Can you? What do you want to average here? Multiple sequential measurements?
This makes the touch slower and hence imprecise and unuseable in another way.
Anyways, the tsc2007 chip can already do such averaging.

> 
> Anyway "input is already noisy" does not mean "so it is okay to
> degrade it more".

You have not yet said how you think it is degraded *more* than in your
example.

> Solve it properly. That means passing calibration
> data from kernel to userland.

As written before, the really proper solution would be to provide floating
or fixed point subpixel input events. Not arbitrarily scaling up in kernel
and leaving downscaling to user space (where everybody can make it worse).

But I don't think it is worth implementing subpixel touch events for real
world devices due to the jitter I mentioned.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

HI Pavel,

> Am 19.02.2017 um 15:17 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> Hi!
> 
>> About loosing precision: there is already noise (jitter) in
>> real-world devices so that you can't achieve subpixel precision
>> anyways (unless your panel has a very low resolution). Please see my
>> answer to Dmitry some mails ago.
> 
> Maybe you can achieve better precision with averaging.

Can you? What do you want to average here? Multiple sequential measurements?
This makes the touch slower and hence imprecise and unuseable in another way.
Anyways, the tsc2007 chip can already do such averaging.

> 
> Anyway "input is already noisy" does not mean "so it is okay to
> degrade it more".

You have not yet said how you think it is degraded *more* than in your
example.

> Solve it properly. That means passing calibration
> data from kernel to userland.

As written before, the really proper solution would be to provide floating
or fixed point subpixel input events. Not arbitrarily scaling up in kernel
and leaving downscaling to user space (where everybody can make it worse).

But I don't think it is worth implementing subpixel touch events for real
world devices due to the jitter I mentioned.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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


> > Solve it properly. That means passing calibration
> > data from kernel to userland.
> 
> As written before, the really proper solution would be to provide floating
> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
> and leaving downscaling to user space (where everybody can make it
> worse).

That has no advantages, and floating point in kernel is hard. Also
you'd either have to invent new interface, or you'd break touchscreen
for people that already have their touchscreens calibrated. Just
pass calibration data to userland.

> But I don't think it is worth implementing subpixel touch events for real
> world devices due to the jitter I mentioned.

Yes, that's not really proper solution, that just overengineered. Not
worth implementing. Pass calibration data to userland.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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


> > Solve it properly. That means passing calibration
> > data from kernel to userland.
> 
> As written before, the really proper solution would be to provide floating
> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
> and leaving downscaling to user space (where everybody can make it
> worse).

That has no advantages, and floating point in kernel is hard. Also
you'd either have to invent new interface, or you'd break touchscreen
for people that already have their touchscreens calibrated. Just
pass calibration data to userland.

> But I don't think it is worth implementing subpixel touch events for real
> world devices due to the jitter I mentioned.

Yes, that's not really proper solution, that just overengineered. Not
worth implementing. Pass calibration data to userland.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,
I love discussions with you :)

> Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> 
>>> Solve it properly. That means passing calibration
>>> data from kernel to userland.
>> 
>> As written before, the really proper solution would be to provide floating
>> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
>> and leaving downscaling to user space (where everybody can make it
>> worse).
> 
> That has no advantages,

It has the advantage of providing you with the full precision of raw data (but
properly scaled) so that you don't loose any bit of information. This is what
you just asked for - one or two mails before.

And it provides me (and my users) with properly scaled touch coordinates, which
is what I (and they - compare e.g. comment by Andreas Kemnade) ask for.

So it would be a solution that fulfills both requirements. And fulfilling
requirements of two groups of people is advantageous to making only one happy.
Isn't it?

> and floating point in kernel is hard. Also
> you'd either have to invent new interface, or you'd break touchscreen
> for people that already have their touchscreens calibrated.

No, I don't break calibration for people using a different chip.

And since we just upstream a solution for devices (GTA04) which already use this
mechanism for years, we also won't break their calibration, because they are happy
with the non-calibration it provides.

We break it only for those, who use the same chip *and* upgrade to a kernel which
includes this patch. And even then, only if they update their device tree to use
it (the default without DT modifications is to provide raw data as before). If
they stay with an older kernel or older DT there is no change and action required.

So there are ca. 5 pre-conditions that others will notice a change at all.

Do you think user-space recalibration is such a difficult task compared to
upgrading a kernel that it must therefore be avoided? Compared to other
kernel-userland synchronization problems it has the good side that you
even will notice it immediately and will know what to do (recalibrate once
and it is done forever).

> Just
> pass calibration data to userland.

What is this good for if kernel can already do the calibration for userland?
If the kernel does it, it don't even waste efforts to pass calibration data
to userland.

And don't forget: if you need calibration data in userland, there are much
better mechanisms. The simplest one is a file (e.g. xorg.conf) which is
something the kernel and X11 already supports.

I.e. adding a new mechanism to pass calibration data from the kernel to
user-space doesn't make any sense, IMHO.

If the kernel knows about calibration it should use it directly and process it.
Like in iio where you can get raw and processed data, although processing could
also be done completely in user-space. So there seem to be good reasons to do
it in kernel...

And, citing your argument from above: "Also you'd either have to invent
new interface, or you'd break touchscreen for people that already have their
touchscreens calibrated."

> 
>> But I don't think it is worth implementing subpixel touch events for real
>> world devices due to the jitter I mentioned.
> 
> Yes, that's not really proper solution, that just overengineered. Not
> worth implementing. Pass calibration data to userland.

You seem to repeat yourself and just say which solution you prefer,
but I am missing the arguments why your solution (Pass calibration data
to userland) is right and the best one. Which problems does it solve?
Which one does it solve better than others? How can you implement it in
a stable and portable way? How can you make sure that all user-space GUI
systems can and will make use of this calibration data?

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,
I love discussions with you :)

> Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> 
>>> Solve it properly. That means passing calibration
>>> data from kernel to userland.
>> 
>> As written before, the really proper solution would be to provide floating
>> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
>> and leaving downscaling to user space (where everybody can make it
>> worse).
> 
> That has no advantages,

It has the advantage of providing you with the full precision of raw data (but
properly scaled) so that you don't loose any bit of information. This is what
you just asked for - one or two mails before.

And it provides me (and my users) with properly scaled touch coordinates, which
is what I (and they - compare e.g. comment by Andreas Kemnade) ask for.

So it would be a solution that fulfills both requirements. And fulfilling
requirements of two groups of people is advantageous to making only one happy.
Isn't it?

> and floating point in kernel is hard. Also
> you'd either have to invent new interface, or you'd break touchscreen
> for people that already have their touchscreens calibrated.

No, I don't break calibration for people using a different chip.

And since we just upstream a solution for devices (GTA04) which already use this
mechanism for years, we also won't break their calibration, because they are happy
with the non-calibration it provides.

We break it only for those, who use the same chip *and* upgrade to a kernel which
includes this patch. And even then, only if they update their device tree to use
it (the default without DT modifications is to provide raw data as before). If
they stay with an older kernel or older DT there is no change and action required.

So there are ca. 5 pre-conditions that others will notice a change at all.

Do you think user-space recalibration is such a difficult task compared to
upgrading a kernel that it must therefore be avoided? Compared to other
kernel-userland synchronization problems it has the good side that you
even will notice it immediately and will know what to do (recalibrate once
and it is done forever).

> Just
> pass calibration data to userland.

What is this good for if kernel can already do the calibration for userland?
If the kernel does it, it don't even waste efforts to pass calibration data
to userland.

And don't forget: if you need calibration data in userland, there are much
better mechanisms. The simplest one is a file (e.g. xorg.conf) which is
something the kernel and X11 already supports.

I.e. adding a new mechanism to pass calibration data from the kernel to
user-space doesn't make any sense, IMHO.

If the kernel knows about calibration it should use it directly and process it.
Like in iio where you can get raw and processed data, although processing could
also be done completely in user-space. So there seem to be good reasons to do
it in kernel...

And, citing your argument from above: "Also you'd either have to invent
new interface, or you'd break touchscreen for people that already have their
touchscreens calibrated."

> 
>> But I don't think it is worth implementing subpixel touch events for real
>> world devices due to the jitter I mentioned.
> 
> Yes, that's not really proper solution, that just overengineered. Not
> worth implementing. Pass calibration data to userland.

You seem to repeat yourself and just say which solution you prefer,
but I am missing the arguments why your solution (Pass calibration data
to userland) is right and the best one. Which problems does it solve?
Which one does it solve better than others? How can you implement it in
a stable and portable way? How can you make sure that all user-space GUI
systems can and will make use of this calibration data?

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> Hi Pavel,
> I love discussions with you :)

Unfortunately I can't say the same.

> > Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > 
> >>> Solve it properly. That means passing calibration
> >>> data from kernel to userland.
> >> 
> >> As written before, the really proper solution would be to provide floating
> >> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
> >> and leaving downscaling to user space (where everybody can make it
> >> worse).
> > 
> > That has no advantages,
> 
> It has the advantage of providing you with the full precision of raw data (but
> properly scaled) so that you don't loose any bit of information. This is what
> you just asked for - one or two mails before.

Not really, right? No matter what kind of fixed point you introduce,
you'll still loose precision.

> > and floating point in kernel is hard. Also
> > you'd either have to invent new interface, or you'd break touchscreen
> > for people that already have their touchscreens calibrated.
> 
> No, I don't break calibration for people using a different chip.

So you propose your touchscreen to behave differently from all other
touchscreens in tree? That's just no-go.

> > Yes, that's not really proper solution, that just overengineered. Not
> > worth implementing. Pass calibration data to userland.
> 
> You seem to repeat yourself and just say which solution you prefer,
> but I am missing the arguments why your solution (Pass calibration data
> to userland) is right and the best one.
> Which problems does it solve?

All you described.

> Which one does it solve better than others?

It is not terminally ugly.

> How can you implement it in
> a stable and portable way?

Easily.

> How can you make sure that all user-space GUI
> systems can and will make use of this calibration data?

You can't, and you don't need to.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> Hi Pavel,
> I love discussions with you :)

Unfortunately I can't say the same.

> > Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > 
> >>> Solve it properly. That means passing calibration
> >>> data from kernel to userland.
> >> 
> >> As written before, the really proper solution would be to provide floating
> >> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
> >> and leaving downscaling to user space (where everybody can make it
> >> worse).
> > 
> > That has no advantages,
> 
> It has the advantage of providing you with the full precision of raw data (but
> properly scaled) so that you don't loose any bit of information. This is what
> you just asked for - one or two mails before.

Not really, right? No matter what kind of fixed point you introduce,
you'll still loose precision.

> > and floating point in kernel is hard. Also
> > you'd either have to invent new interface, or you'd break touchscreen
> > for people that already have their touchscreens calibrated.
> 
> No, I don't break calibration for people using a different chip.

So you propose your touchscreen to behave differently from all other
touchscreens in tree? That's just no-go.

> > Yes, that's not really proper solution, that just overengineered. Not
> > worth implementing. Pass calibration data to userland.
> 
> You seem to repeat yourself and just say which solution you prefer,
> but I am missing the arguments why your solution (Pass calibration data
> to userland) is right and the best one.
> Which problems does it solve?

All you described.

> Which one does it solve better than others?

It is not terminally ugly.

> How can you implement it in
> a stable and portable way?

Easily.

> How can you make sure that all user-space GUI
> systems can and will make use of this calibration data?

You can't, and you don't need to.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 20:05 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>> Hi Pavel,
>> I love discussions with you :)
> 
> Unfortunately I can't say the same.

> 
>>> Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> 
>>>>> Solve it properly. That means passing calibration
>>>>> data from kernel to userland.
>>>> 
>>>> As written before, the really proper solution would be to provide floating
>>>> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
>>>> and leaving downscaling to user space (where everybody can make it
>>>> worse).
>>> 
>>> That has no advantages,
>> 
>> It has the advantage of providing you with the full precision of raw data (but
>> properly scaled) so that you don't loose any bit of information. This is what
>> you just asked for - one or two mails before.
> 
> Not really, right? No matter what kind of fixed point you introduce,
> you'll still loose precision.

Can you please elaborate?

My thoughts:

If the ADC has 12 bit of precision, then let's say 32 bits (16 before and 16
after the decimal point) of fixed point precision are not loosing anything
if you scale to screen coordinates (in most cases they are between 480 and
1280 max).

Theoretically you can loose the LSB of the 16 bits right of the decimal point.
This is ca. 0.000015259 pixels of precision. I don't care about this loss of
precision... Do you? If yes, why?

But as said I don't think we need float or fixed point for practical systems
at all.

> 
>>> and floating point in kernel is hard. Also
>>> you'd either have to invent new interface, or you'd break touchscreen
>>> for people that already have their touchscreens calibrated.
>> 
>> No, I don't break calibration for people using a different chip.
> 
> So you propose your touchscreen to behave differently from all other
> touchscreens in tree?

No. I only propose that my touch screen behaves properly and in the
best way it can. If others are worse, they should also be improved at
some time.

And note that I am not making things different from others in tree, I
am making the tsc2007 right (incl. following the touchscreen bindings
which define the touchscreen size in "Pixels").

> That's just no-go.

In other words: you want to block any improvements unless your favourite
touchscreen is giving directions...

> 
>>> Yes, that's not really proper solution, that just overengineered. Not
>>> worth implementing. Pass calibration data to userland.
>> 
>> You seem to repeat yourself and just say which solution you prefer,
>> but I am missing the arguments why your solution (Pass calibration data
>> to userland) is right and the best one.
>> Which problems does it solve?
> 
> All you described.

I think you are missing one problem: providing already properly scaled touch
values to user space.

Please look how iio is doing raw and processed data.

> 
>> Which one does it solve better than others?
> 
> It is not terminally ugly.

"ugly" is not a technical or scientific criterion and depends on your personal
perception. Do you have a better argument?

> 
>> How can you implement it in
>> a stable and portable way?
> 
> Easily.

Please go ahead and show code.

> 
>> How can you make sure that all user-space GUI
>> systems can and will make use of this calibration data?
> 
> You can't,

Exactly. Hence my proposal is superior. Because it avoids asking
the user-space to use calibration data.

>  and you don't need to.

How can you know that I don't have to? Do you know my systems and
users and what they want?

BR and thanks,
Nikolaus



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 20:05 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>> Hi Pavel,
>> I love discussions with you :)
> 
> Unfortunately I can't say the same.

> 
>>> Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> 
>>>>> Solve it properly. That means passing calibration
>>>>> data from kernel to userland.
>>>> 
>>>> As written before, the really proper solution would be to provide floating
>>>> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
>>>> and leaving downscaling to user space (where everybody can make it
>>>> worse).
>>> 
>>> That has no advantages,
>> 
>> It has the advantage of providing you with the full precision of raw data (but
>> properly scaled) so that you don't loose any bit of information. This is what
>> you just asked for - one or two mails before.
> 
> Not really, right? No matter what kind of fixed point you introduce,
> you'll still loose precision.

Can you please elaborate?

My thoughts:

If the ADC has 12 bit of precision, then let's say 32 bits (16 before and 16
after the decimal point) of fixed point precision are not loosing anything
if you scale to screen coordinates (in most cases they are between 480 and
1280 max).

Theoretically you can loose the LSB of the 16 bits right of the decimal point.
This is ca. 0.000015259 pixels of precision. I don't care about this loss of
precision... Do you? If yes, why?

But as said I don't think we need float or fixed point for practical systems
at all.

> 
>>> and floating point in kernel is hard. Also
>>> you'd either have to invent new interface, or you'd break touchscreen
>>> for people that already have their touchscreens calibrated.
>> 
>> No, I don't break calibration for people using a different chip.
> 
> So you propose your touchscreen to behave differently from all other
> touchscreens in tree?

No. I only propose that my touch screen behaves properly and in the
best way it can. If others are worse, they should also be improved at
some time.

And note that I am not making things different from others in tree, I
am making the tsc2007 right (incl. following the touchscreen bindings
which define the touchscreen size in "Pixels").

> That's just no-go.

In other words: you want to block any improvements unless your favourite
touchscreen is giving directions...

> 
>>> Yes, that's not really proper solution, that just overengineered. Not
>>> worth implementing. Pass calibration data to userland.
>> 
>> You seem to repeat yourself and just say which solution you prefer,
>> but I am missing the arguments why your solution (Pass calibration data
>> to userland) is right and the best one.
>> Which problems does it solve?
> 
> All you described.

I think you are missing one problem: providing already properly scaled touch
values to user space.

Please look how iio is doing raw and processed data.

> 
>> Which one does it solve better than others?
> 
> It is not terminally ugly.

"ugly" is not a technical or scientific criterion and depends on your personal
perception. Do you have a better argument?

> 
>> How can you implement it in
>> a stable and portable way?
> 
> Easily.

Please go ahead and show code.

> 
>> How can you make sure that all user-space GUI
>> systems can and will make use of this calibration data?
> 
> You can't,

Exactly. Hence my proposal is superior. Because it avoids asking
the user-space to use calibration data.

>  and you don't need to.

How can you know that I don't have to? Do you know my systems and
users and what they want?

BR and thanks,
Nikolaus



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

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

Hi,

On Sun, Feb 19, 2017 at 01:07:26PM +0100, H. Nikolaus Schaller wrote:
> I don't really remember when we noticed it first. Maybe it was
> back in tslib times some years ago where setting the sensitivity
> threshold made problems. We then carried along our patch for a
> long time in our local repo (and modified it several times) and
> only started upstreaming some months ago. [...]
> 
> AFAIK, GIMP and for example https://sourceforge.net/projects/xournal/ appear
> to be able to handle X pressure, but I haven't running and tested either one
> on our devices. Pressure is used in such drawing tools to simulate that some
> physical pens make wider strokes on higher pressure.
> 
> This seems to indicate that X can handle pressure in a non-boolean way, but rarely does.
> Especially I think the usual menu, click, drag, scroll gestures are only based
> on BTN_TOUCH status and not on ABS_PRESSURE. So it is rarely noticed to make
> a difference.

ok.

> >>> I suggest to put the resistance vs pressure thing in its own patch,
> >>> that also fixes tsc200x-core and merge it to linux-next after the
> >>> merge window.
> 
> Ok. I will propose a patch.

Thanks. I suggest to add this in the patch description:

While this patch changes the values reported to userspace,
ABS_PRESSURE is used rarely by userspace. Most software only
relies on BTN_TOUCH (boolean), which is not affected by this
patch. Some graphics software makes use of the interface and
does not work correctly with the currently used inverted
behaviour.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

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

Hi,

On Sun, Feb 19, 2017 at 01:07:26PM +0100, H. Nikolaus Schaller wrote:
> I don't really remember when we noticed it first. Maybe it was
> back in tslib times some years ago where setting the sensitivity
> threshold made problems. We then carried along our patch for a
> long time in our local repo (and modified it several times) and
> only started upstreaming some months ago. [...]
> 
> AFAIK, GIMP and for example https://sourceforge.net/projects/xournal/ appear
> to be able to handle X pressure, but I haven't running and tested either one
> on our devices. Pressure is used in such drawing tools to simulate that some
> physical pens make wider strokes on higher pressure.
> 
> This seems to indicate that X can handle pressure in a non-boolean way, but rarely does.
> Especially I think the usual menu, click, drag, scroll gestures are only based
> on BTN_TOUCH status and not on ABS_PRESSURE. So it is rarely noticed to make
> a difference.

ok.

> >>> I suggest to put the resistance vs pressure thing in its own patch,
> >>> that also fixes tsc200x-core and merge it to linux-next after the
> >>> merge window.
> 
> Ok. I will propose a patch.

Thanks. I suggest to add this in the patch description:

While this patch changes the values reported to userspace,
ABS_PRESSURE is used rarely by userspace. Most software only
relies on BTN_TOUCH (boolean), which is not affected by this
patch. Some graphics software makes use of the interface and
does not work correctly with the currently used inverted
behaviour.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!


> But as said I don't think we need float or fixed point for practical systems
> at all.

So you are going to loose precision. And if userspace decides to
calibrate it slightly differently from kernel, lost precision will
matter.

> >>> and floating point in kernel is hard. Also
> >>> you'd either have to invent new interface, or you'd break touchscreen
> >>> for people that already have their touchscreens calibrated.
> >> 
> >> No, I don't break calibration for people using a different chip.
> > 
> > So you propose your touchscreen to behave differently from all other
> > touchscreens in tree?
> 
> No. I only propose that my touch screen behaves properly and in the
> best way it can. If others are worse, they should also be improved at
> some time.

Different from all other drivers. Read: broken.

No. You have to design interface such that they _can_ be improved, and
what you propose does not work that way. 

> And note that I am not making things different from others in tree, I
> am making the tsc2007 right (incl. following the touchscreen bindings
> which define the touchscreen size in "Pixels").

Your touch screen is not in any way special, so it has to behave in
the same way others do.

> > That's just no-go.
> 
> In other words: you want to block any improvements unless your favourite
> touchscreen is giving directions...

Yes. I want to prevent you from pushing crap into the kernel.

If you want to improve it in reasonable way, you know what to do.

> >> You seem to repeat yourself and just say which solution you prefer,
> >> but I am missing the arguments why your solution (Pass calibration data
> >> to userland) is right and the best one.
> >> Which problems does it solve?
> > 
> > All you described.
> 
> I think you are missing one problem: providing already properly scaled touch
> values to user space.

I'm not. Userspace has to know how to do the calibration _anyway_ (for
other hardware), so giving scaled values to userspace is useless.

> >> How can you implement it in
> >> a stable and portable way?
> > 
> > Easily.
> 
> Please go ahead and show code.

You don't get to tell me what to do, unless you pay me.

You want to break kernel, you do coding. Or pay someone else,
preferably someone who knows how to design kernel code.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!


> But as said I don't think we need float or fixed point for practical systems
> at all.

So you are going to loose precision. And if userspace decides to
calibrate it slightly differently from kernel, lost precision will
matter.

> >>> and floating point in kernel is hard. Also
> >>> you'd either have to invent new interface, or you'd break touchscreen
> >>> for people that already have their touchscreens calibrated.
> >> 
> >> No, I don't break calibration for people using a different chip.
> > 
> > So you propose your touchscreen to behave differently from all other
> > touchscreens in tree?
> 
> No. I only propose that my touch screen behaves properly and in the
> best way it can. If others are worse, they should also be improved at
> some time.

Different from all other drivers. Read: broken.

No. You have to design interface such that they _can_ be improved, and
what you propose does not work that way. 

> And note that I am not making things different from others in tree, I
> am making the tsc2007 right (incl. following the touchscreen bindings
> which define the touchscreen size in "Pixels").

Your touch screen is not in any way special, so it has to behave in
the same way others do.

> > That's just no-go.
> 
> In other words: you want to block any improvements unless your favourite
> touchscreen is giving directions...

Yes. I want to prevent you from pushing crap into the kernel.

If you want to improve it in reasonable way, you know what to do.

> >> You seem to repeat yourself and just say which solution you prefer,
> >> but I am missing the arguments why your solution (Pass calibration data
> >> to userland) is right and the best one.
> >> Which problems does it solve?
> > 
> > All you described.
> 
> I think you are missing one problem: providing already properly scaled touch
> values to user space.

I'm not. Userspace has to know how to do the calibration _anyway_ (for
other hardware), so giving scaled values to userspace is useless.

> >> How can you implement it in
> >> a stable and portable way?
> > 
> > Easily.
> 
> Please go ahead and show code.

You don't get to tell me what to do, unless you pay me.

You want to break kernel, you do coding. Or pay someone else,
preferably someone who knows how to design kernel code.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 21:57 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
> 
>> But as said I don't think we need float or fixed point for practical systems
>> at all.
> 
> So you are going to loose precision. And if userspace decides to
> calibrate it slightly differently from kernel, lost precision will
> matter.

Really?

Example:

ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)

This is scaled to let's say 0..640.

Now you find your touch is misaligned by 1% which is 6.4 pixels but barely
noticeable on a 5cm screen (1% is 0.5mm).

So you simply subtract 6 from all coordinates and the screen is aligned again.
Does the 0.4 pixel deviation in precision (= 0.2mm) matter?

If you do this scaling from ADC range 0..4095 to 0..640 in user-space, you will
find that you have to subtract 59 from the ADC values and then scale by 0.16431.
The result will be almost the same and deviate in the micrometer range. How big
is your stylus or finger?

We learn: a real world touch screen is not a high precision instrument.

> 
>>>>> and floating point in kernel is hard. Also
>>>>> you'd either have to invent new interface, or you'd break touchscreen
>>>>> for people that already have their touchscreens calibrated.
>>>> 
>>>> No, I don't break calibration for people using a different chip.
>>> 
>>> So you propose your touchscreen to behave differently from all other
>>> touchscreens in tree?
>> 
>> No. I only propose that my touch screen behaves properly and in the
>> best way it can. If others are worse, they should also be improved at
>> some time.
> 
> Different from all other drivers. Read: broken.

If something differs from requirements or a spec, then it is broken.

Not if it differs from other drivers (implementations). They may be broken
as well or follow different requirements.

Note:
1. the touch screen bindings do ask to scale to screen size (please read
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt )

2. if you don't use these features the driver behaves exactly as it was
before by using defaults and like other drivers which do (not yet) have it

> 
> No. You have to design interface such that they _can_ be improved, and
> what you propose does not work that way.

It works. Please do real world tests...

> 
>> And note that I am not making things different from others in tree, I
>> am making the tsc2007 right (incl. following the touchscreen bindings
>> which define the touchscreen size in "Pixels").
> 
> Your touch screen is not in any way special, so it has to behave in
> the same way others do.

It does. Plus some new features which are missing...

> 
>>> That's just no-go.
>> 
>> In other words: you want to block any improvements unless your favourite
>> touchscreen is giving directions...
> 
> Yes. I want to prevent you from pushing crap into the kernel.

Crap? Well, we have discussed this driver for months here on the list and
after a lot of improvements we came up to v9.

And you still think it is crap and none of the other reviewers has noticed?

> 
> If you want to improve it in reasonable way, you know what to do.
> 
>>>> You seem to repeat yourself and just say which solution you prefer,
>>>> but I am missing the arguments why your solution (Pass calibration data
>>>> to userland) is right and the best one.
>>>> Which problems does it solve?
>>> 
>>> All you described.
>> 
>> I think you are missing one problem: providing already properly scaled touch
>> values to user space.
> 
> I'm not.

You are. Because you said: "All you described." And I had described that as well.

So you were either wrong before or now.

> Userspace has to know how to do the calibration _anyway_ (for
> other hardware),

What for? I do not understand which other hardware you are talking about.

On our devices there is only one touch glued to the panel and that one
has to be calibrated. Ideally before the user gets the device into his
hands => precalibration...

If you connect a digitizer, then that one has to be calibrated of course,
but it is not glued onto the display panel. Hence it is a different issue.

Please describe the use case / scenario you are thinking of.

> so giving scaled values to userspace is useless.

This is another example why I love to discuss with you :)

You are so wonderful in ignoring my explanations during the past 20 mails
where I described exactly and in detail why it is useful for me, for
others, for users of the GTA04 for the upcoming Pyra device... So at
least 2000 or more persons.

One daily user of these devices and kernel contributor already had commented his view.

IMHO, only Pavel Machek is thinking it is useless. Therefore he concludes it must be
useless for everybody else as well.

> 
>>>> How can you implement it in
>>>> a stable and portable way?
>>> 
>>> Easily.
>> 
>> Please go ahead and show code.
> 
> You don't get to tell me what to do, unless you pay me.

Same for me.

But: you get our contributions for free. Unpaid work, we did put into developing
these patches for the benefit of mankind.

> 
> You want to break kernel, you do coding. Or pay someone else,
> preferably someone who knows how to design kernel code.

Ah, so that's the way the wind is blowing...

You are trying to block community contributions to get a paid job by pretending to do
it better :)

This is a quite clever attempt to ruin the open source, volunteer and community idea.

It is defined as "building from and giving back to the community". We could easily run
our own fork of Linux and ignore upstreaming, but I believe that we should give back
something to those who have developed the other parts of Linux we simply use. And you
want to exclude us from this? Nonono.

It is really funny to discuss with you and I can still learn how to work around really
answering questions, accepting that other people have different requirements and ignoring
technical arguments and answers given to form a big picture.

So just derailing this discussion because you want to be paid is not at all fair.
But I can withstand this.

Please give me convincing technical arguments (which include our requirements and not
only yours) like other reviewers do and we will change code.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 21:57 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> Hi!
> 
> 
>> But as said I don't think we need float or fixed point for practical systems
>> at all.
> 
> So you are going to loose precision. And if userspace decides to
> calibrate it slightly differently from kernel, lost precision will
> matter.

Really?

Example:

ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)

This is scaled to let's say 0..640.

Now you find your touch is misaligned by 1% which is 6.4 pixels but barely
noticeable on a 5cm screen (1% is 0.5mm).

So you simply subtract 6 from all coordinates and the screen is aligned again.
Does the 0.4 pixel deviation in precision (= 0.2mm) matter?

If you do this scaling from ADC range 0..4095 to 0..640 in user-space, you will
find that you have to subtract 59 from the ADC values and then scale by 0.16431.
The result will be almost the same and deviate in the micrometer range. How big
is your stylus or finger?

We learn: a real world touch screen is not a high precision instrument.

> 
>>>>> and floating point in kernel is hard. Also
>>>>> you'd either have to invent new interface, or you'd break touchscreen
>>>>> for people that already have their touchscreens calibrated.
>>>> 
>>>> No, I don't break calibration for people using a different chip.
>>> 
>>> So you propose your touchscreen to behave differently from all other
>>> touchscreens in tree?
>> 
>> No. I only propose that my touch screen behaves properly and in the
>> best way it can. If others are worse, they should also be improved at
>> some time.
> 
> Different from all other drivers. Read: broken.

If something differs from requirements or a spec, then it is broken.

Not if it differs from other drivers (implementations). They may be broken
as well or follow different requirements.

Note:
1. the touch screen bindings do ask to scale to screen size (please read
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt )

2. if you don't use these features the driver behaves exactly as it was
before by using defaults and like other drivers which do (not yet) have it

> 
> No. You have to design interface such that they _can_ be improved, and
> what you propose does not work that way.

It works. Please do real world tests...

> 
>> And note that I am not making things different from others in tree, I
>> am making the tsc2007 right (incl. following the touchscreen bindings
>> which define the touchscreen size in "Pixels").
> 
> Your touch screen is not in any way special, so it has to behave in
> the same way others do.

It does. Plus some new features which are missing...

> 
>>> That's just no-go.
>> 
>> In other words: you want to block any improvements unless your favourite
>> touchscreen is giving directions...
> 
> Yes. I want to prevent you from pushing crap into the kernel.

Crap? Well, we have discussed this driver for months here on the list and
after a lot of improvements we came up to v9.

And you still think it is crap and none of the other reviewers has noticed?

> 
> If you want to improve it in reasonable way, you know what to do.
> 
>>>> You seem to repeat yourself and just say which solution you prefer,
>>>> but I am missing the arguments why your solution (Pass calibration data
>>>> to userland) is right and the best one.
>>>> Which problems does it solve?
>>> 
>>> All you described.
>> 
>> I think you are missing one problem: providing already properly scaled touch
>> values to user space.
> 
> I'm not.

You are. Because you said: "All you described." And I had described that as well.

So you were either wrong before or now.

> Userspace has to know how to do the calibration _anyway_ (for
> other hardware),

What for? I do not understand which other hardware you are talking about.

On our devices there is only one touch glued to the panel and that one
has to be calibrated. Ideally before the user gets the device into his
hands => precalibration...

If you connect a digitizer, then that one has to be calibrated of course,
but it is not glued onto the display panel. Hence it is a different issue.

Please describe the use case / scenario you are thinking of.

> so giving scaled values to userspace is useless.

This is another example why I love to discuss with you :)

You are so wonderful in ignoring my explanations during the past 20 mails
where I described exactly and in detail why it is useful for me, for
others, for users of the GTA04 for the upcoming Pyra device... So at
least 2000 or more persons.

One daily user of these devices and kernel contributor already had commented his view.

IMHO, only Pavel Machek is thinking it is useless. Therefore he concludes it must be
useless for everybody else as well.

> 
>>>> How can you implement it in
>>>> a stable and portable way?
>>> 
>>> Easily.
>> 
>> Please go ahead and show code.
> 
> You don't get to tell me what to do, unless you pay me.

Same for me.

But: you get our contributions for free. Unpaid work, we did put into developing
these patches for the benefit of mankind.

> 
> You want to break kernel, you do coding. Or pay someone else,
> preferably someone who knows how to design kernel code.

Ah, so that's the way the wind is blowing...

You are trying to block community contributions to get a paid job by pretending to do
it better :)

This is a quite clever attempt to ruin the open source, volunteer and community idea.

It is defined as "building from and giving back to the community". We could easily run
our own fork of Linux and ignore upstreaming, but I believe that we should give back
something to those who have developed the other parts of Linux we simply use. And you
want to exclude us from this? Nonono.

It is really funny to discuss with you and I can still learn how to work around really
answering questions, accepting that other people have different requirements and ignoring
technical arguments and answers given to form a big picture.

So just derailing this discussion because you want to be paid is not at all fair.
But I can withstand this.

Please give me convincing technical arguments (which include our requirements and not
only yours) like other reviewers do and we will change code.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

hi!

> >> But as said I don't think we need float or fixed point for practical systems
> >> at all.
> > 
> > So you are going to loose precision. And if userspace decides to
> > calibrate it slightly differently from kernel, lost precision will
> > matter.
> 
> Really?

Really.

> Example:
> 
> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
> 
> This is scaled to let's say 0..640.

Ok. Now userspace realizes that kernel alignemnt is off, and it would
want to scale it to 1..642. That will mean that single pixel will be
inaccessible, right?

> > No. You have to design interface such that they _can_ be improved, and
> > what you propose does not work that way.
> 
> It works. Please do real world tests...

You do a real world test on N900, and propose upgrade path.

> > Yes. I want to prevent you from pushing crap into the kernel.
> 
> Crap? Well, we have discussed this driver for months here on the list and
> after a lot of improvements we came up to v9.
> 
> And you still think it is crap and none of the other reviewers has noticed?

I'm pretty sure you will not be able to push calibration into kernel.

> > Userspace has to know how to do the calibration _anyway_ (for
> > other hardware),
> 
> What for? I do not understand which other hardware you are talking about.
> 
> On our devices there is only one touch glued to the panel and that one
> has to be calibrated. Ideally before the user gets the device into his
> hands => precalibration...
> 
> If you connect a digitizer, then that one has to be calibrated of course,
> but it is not glued onto the display panel. Hence it is a different
> issue.

It is actually same issue. One kernel interface should work for all
the touchscreens.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

hi!

> >> But as said I don't think we need float or fixed point for practical systems
> >> at all.
> > 
> > So you are going to loose precision. And if userspace decides to
> > calibrate it slightly differently from kernel, lost precision will
> > matter.
> 
> Really?

Really.

> Example:
> 
> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
> 
> This is scaled to let's say 0..640.

Ok. Now userspace realizes that kernel alignemnt is off, and it would
want to scale it to 1..642. That will mean that single pixel will be
inaccessible, right?

> > No. You have to design interface such that they _can_ be improved, and
> > what you propose does not work that way.
> 
> It works. Please do real world tests...

You do a real world test on N900, and propose upgrade path.

> > Yes. I want to prevent you from pushing crap into the kernel.
> 
> Crap? Well, we have discussed this driver for months here on the list and
> after a lot of improvements we came up to v9.
> 
> And you still think it is crap and none of the other reviewers has noticed?

I'm pretty sure you will not be able to push calibration into kernel.

> > Userspace has to know how to do the calibration _anyway_ (for
> > other hardware),
> 
> What for? I do not understand which other hardware you are talking about.
> 
> On our devices there is only one touch glued to the panel and that one
> has to be calibrated. Ideally before the user gets the device into his
> hands => precalibration...
> 
> If you connect a digitizer, then that one has to be calibrated of course,
> but it is not glued onto the display panel. Hence it is a different
> issue.

It is actually same issue. One kernel interface should work for all
the touchscreens.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Andreas Kemnade]

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

Hi,

On Sun, 19 Feb 2017 21:57:08 +0100
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> 
> > But as said I don't think we need float or fixed point for
> > practical systems at all.
> 
> So you are going to loose precision. And if userspace decides to
> calibrate it slightly differently from kernel, lost precision will
> matter.
> 
> > >>> and floating point in kernel is hard. Also
> > >>> you'd either have to invent new interface, or you'd break
> > >>> touchscreen for people that already have their touchscreens
> > >>> calibrated.
> > >> 
> > >> No, I don't break calibration for people using a different chip.
> > > 
> > > So you propose your touchscreen to behave differently from all
> > > other touchscreens in tree?
> > 
> > No. I only propose that my touch screen behaves properly and in the
> > best way it can. If others are worse, they should also be improved
> > at some time.
> 
> Different from all other drivers. Read: broken.
> 
> No. You have to design interface such that they _can_ be improved, and
> what you propose does not work that way. 
> 
Then the consequent way would be to use i2c directly from userspace.
Because maybe for some really, really unusual you can do
something better there. Maybe adjust on-chip filtering (here the
MAV-filter) to interact better with your userspace filtering or
something like that if you want to exactly detect where maybe a
mosquito tries to drill into your touch screen (if the pressure would
be enough...) 

> > And note that I am not making things different from others in tree,
> > I am making the tsc2007 right (incl. following the touchscreen
> > bindings which define the touchscreen size in "Pixels").
> 
> Your touch screen is not in any way special, so it has to behave in
> the same way others do.
> 

I agree, the tsc2007 (=what the interface provides to userspace) should
not behave special, for example it should behave like the virtual
touchscreen (=what the interface provides to userspace) virtualbox
gives. No need to be calibrated. Well, the internals are different. But
that is what the kernel is good for, abstract such things.
Conclusion: It cannot be totally wrong behavior to have pixel values
there.

And the generic touchscreen bindings describe the size in "Pixels" as
said by Nikolaus,

And here it is up to the dt to decide whether the touch screen is good
enough in position so it does not need to be manually calibrated or
there are chances to improve something. If there is no calibration in
the dt, then nothing changes.

Regards,
Andreas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Andreas Kemnade]

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

Hi,

On Sun, 19 Feb 2017 21:57:08 +0100
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> 
> > But as said I don't think we need float or fixed point for
> > practical systems at all.
> 
> So you are going to loose precision. And if userspace decides to
> calibrate it slightly differently from kernel, lost precision will
> matter.
> 
> > >>> and floating point in kernel is hard. Also
> > >>> you'd either have to invent new interface, or you'd break
> > >>> touchscreen for people that already have their touchscreens
> > >>> calibrated.
> > >> 
> > >> No, I don't break calibration for people using a different chip.
> > > 
> > > So you propose your touchscreen to behave differently from all
> > > other touchscreens in tree?
> > 
> > No. I only propose that my touch screen behaves properly and in the
> > best way it can. If others are worse, they should also be improved
> > at some time.
> 
> Different from all other drivers. Read: broken.
> 
> No. You have to design interface such that they _can_ be improved, and
> what you propose does not work that way. 
> 
Then the consequent way would be to use i2c directly from userspace.
Because maybe for some really, really unusual you can do
something better there. Maybe adjust on-chip filtering (here the
MAV-filter) to interact better with your userspace filtering or
something like that if you want to exactly detect where maybe a
mosquito tries to drill into your touch screen (if the pressure would
be enough...) 

> > And note that I am not making things different from others in tree,
> > I am making the tsc2007 right (incl. following the touchscreen
> > bindings which define the touchscreen size in "Pixels").
> 
> Your touch screen is not in any way special, so it has to behave in
> the same way others do.
> 

I agree, the tsc2007 (=what the interface provides to userspace) should
not behave special, for example it should behave like the virtual
touchscreen (=what the interface provides to userspace) virtualbox
gives. No need to be calibrated. Well, the internals are different. But
that is what the kernel is good for, abstract such things.
Conclusion: It cannot be totally wrong behavior to have pixel values
there.

And the generic touchscreen bindings describe the size in "Pixels" as
said by Nikolaus,

And here it is up to the dt to decide whether the touch screen is good
enough in position so it does not need to be manually calibrated or
there are chances to improve something. If there is no calibration in
the dt, then nothing changes.

Regards,
Andreas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > > And note that I am not making things different from others in tree,
> > > I am making the tsc2007 right (incl. following the touchscreen
> > > bindings which define the touchscreen size in "Pixels").
> > 
> > Your touch screen is not in any way special, so it has to behave in
> > the same way others do.
> > 
> 
> I agree, the tsc2007 (=what the interface provides to userspace) should
> not behave special, for example it should behave like the virtual
> touchscreen (=what the interface provides to userspace) virtualbox
> gives. No need to be calibrated. Well, the internals are different. But
> that is what the kernel is good for, abstract such things.
> Conclusion: It cannot be totally wrong behavior to have pixel values
> there.

It is not "totally wrong". But it is useless code that should not be
in kernel. Calibration certainly does not belong to single
_driver_. Feel free to submit driver but keep the calibration code out
of tree...

But if you have userspace that depends on touchscreen to be
calibrated... that _is_ wrong.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > > And note that I am not making things different from others in tree,
> > > I am making the tsc2007 right (incl. following the touchscreen
> > > bindings which define the touchscreen size in "Pixels").
> > 
> > Your touch screen is not in any way special, so it has to behave in
> > the same way others do.
> > 
> 
> I agree, the tsc2007 (=what the interface provides to userspace) should
> not behave special, for example it should behave like the virtual
> touchscreen (=what the interface provides to userspace) virtualbox
> gives. No need to be calibrated. Well, the internals are different. But
> that is what the kernel is good for, abstract such things.
> Conclusion: It cannot be totally wrong behavior to have pixel values
> there.

It is not "totally wrong". But it is useless code that should not be
in kernel. Calibration certainly does not belong to single
_driver_. Feel free to submit driver but keep the calibration code out
of tree...

But if you have userspace that depends on touchscreen to be
calibrated... that _is_ wrong.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

Hi Nikolaus,

On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > Hi Nikolaus,
> > 
> > On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >> 
> >>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >>> 
> >>> Hi Nikolaus,
> >>> 
> >>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> >>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> >>>> introduced common DT bindings for touchscreens [1] and a helper function to
> >>>> parse the DT.
> >>>> 
> >>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> >>>> added another helper for parsing axis inversion and swapping
> >>>> and applying them to x and y coordinates.
> >>>> 
> >>>> Both helpers have been integrated to accommodate any orientation of the
> >>>> touch panel in relation to the LCD.
> >>>> 
> >>>> A new feature is to introduce scaling the min/max ADC values to the screen
> >>>> size.
> >>>> 
> >>>> This makes it possible to pre-calibrate the touch so that is (almost)
> >>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> >>>> well enough operate the touch before a user space calibration step can
> >>>> improve the precision.
> >>> 
> >>> I question whether doing scaling in kernel is really right solution.
> >> 
> >> Since lower left corner does not exactly report [0 0] and upper right corner
> >> does not report [4095 4095] from the ADC we need offset and steepness correction
> >> of the ADC values.
> >> 
> >> This steepness is the scaling that must happen in kernel and I don't understand
> >> why you want to propagate this ADC errors to user-space by avoiding scaling.
> >> 
> >> Let me iterate what we want to achieve:
> >> * use new common bindings
> >> * offset and steepness calibration of the ADC (called pre-calibration).
> >>  This makes a real device much more reliable to operate with factory installed
> >>  scaling factors.
> >> * flipping and rotation
> >> 
> >> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
> > 
> > That was explicitly called out in the patch:
> > 
> > "A new feature is to introduce scaling the min/max ADC values to the
> > screen size."
> 

> Because it is a feature that was not planned nor required, but is
> there. So it came into the description of what can be done. If this is
> the key problem I am happy with removing it from the commit messages.
> 
> Anyways, scaling to screen coordinates is not my invention. It is
> based on
> 
> 	http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> which defines the size to be in pixels. Well, a resistive touch screen
> does not have pixels.  It might have a resolution/precision given by
> the ADC conversion steps but I assume this is not meant here.
> 
> So this scaling to screen size was also stimulated by this DT
> bindings.
> 

OK, now I see where you are coming from. You assume that pixels
mentioned in the DT binding are LCD pixels, however this is incorrect.
They are "pixels" or the touch controller, i.e. native unites in which
device reports coordinates, as opposed to points per inch, or
millimeters, or whatever. These "pixels" do not have to have 1:1
relation to the LCD pixels; in fact they rarely do.

Input driver may set resolution for given axis in units per mm (or units
per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
to specify the size of entire touch surface and set resolution from it
so that userspace can calculate the proper scaling factor.

> > 
> >> 
> >> Now to achieve the ADC pre-calibration we must calculate
> >> 
> >> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
> >> 
> >> This is scaled up to what is defined by touchscreen-size-x, i.e.
> >> 
> >> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
> >> 
> >> How do you want to avoid this scaling to take place? It happens automatically.
> >> It is not even an additional line of code. And is necessary for compensating ADC
> >> offsets and steepness.
> >> 
> >> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
> >> compensation which is essential for a device which has no means to properly
> >> calibrate before operating the device through touch.
> >> 
> >> The other option would be to avoid common bindings and set
> >> 
> >> 	touchscreen-size-x = (ti,max-x-ti,min-x)
> >> 
> >> This is heavily dependent on specific ADC offsets forwarded to user-space.
> >> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
> >> 
> >>> 
> >>> Why do you want this?
> >> 
> >> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
> >> and LCD pixels and have designed code to achieve exactly that.
> >> 
> >> This is not the case. It is just a byproduct that you can do it.
> >> 
> >> And since it is easier to understand we have made the examples this way.
> >> 
> >>> If your touch resolution is lower than your screen
> >>> then it might be useful, but if it is lower then you are losing data
> >>> that can be very helpful for gesture recognition, and I hope you design
> >>> your userspace so it can handle not only "bad" hardware, but "good" as
> >>> well. And even with "bad" there are a lot of tricks that can be done to
> >>> get "better" touch position in userspace.
> >> 
> >> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
> >> This of course reduces the touch precision to full LCD pixels. For finger-
> >> touch operated devices, subpixel precision is rarely needed.
> >> 
> >> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
> >> such an 1:1 mapping and they will be perfectly happy about this. 
> >> 
> >> But, if you can modify your user-space easily, you can also choose a different
> >> factor.
> >> 
> >> You can for example define touchscreen-size-x=<4096> and then you get almost
> >> the highest precision of the ADC and won't loose any bits. Or even define a
> >> bigger range and get steps >1 bit.
> >> 
> >> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
> >> 
> >> So effectively we get for LCD pixels when the touch sets a mouse pointer:
> >> 
> >> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
> >> 
> >> The most simple setup would then be but others are possible:
> >> 
> >> 	user-space-scale = 1
> >> 	touchscreen-size-x = LCD-size-x
> >> 
> >> Let me cite myself:
> >> 
> >>>> This makes it possible to pre-calibrate the touch so that is (almost)
> > 
> > Yes, it allows you to pre-calibrate, I get it. But you still do properly
> > calibrate later, right?
> 
> No. We want to get rid of this step unless we need to improve the precision by
> some tiny %.
> 
> Why do we want to get rid of it?
> 
> This needs a longer explanation.
> 
> First of all we are working on the Letux distribution which aims at supporting
> multiple devices in the same way and with a single SD card image that contains
> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
> and DTB files for each supported device.
> 
> One of the ideas is to allow users to swap the SD card from one device to the
> other. This means that the touch screen calibration must magically be carried
> along - or we enforce to recalibrate every time the sd card is swapped back or
> forth.
> 
> The same is true for prebuilt SD-images. To have a single (no longer device specific)
> download requires to have a well defined default calibration. Especially on
> devices where you have no keyboard where you can ask the user to manually fine-tune
> something.
> 
> Our challenge is to make it work well without asking for explicit calibration.
> This is where pre-calibration comes into the game.
> 
> It turns out to be related to the touch screen properties and how it is glued onto
> the specific LCD panel, i.e. hardware and its description.
> 
> So the natural location of defining this relation is the DTB for each device
> and not the user-space. And it happens that we already have one per device
> (touch screen, lcd, tsc variant) on the SD card.
> 
> > So you are doing double work here, once in
> > kernel, and second time in userspace.
> 
> This is no longer required, as long as we can use the default 1:1 coordinate mapping
> of e.g. framebuffer or X11 based GUI toolkits.
> 
> If we don't have the 1:1 mapping of touch screen input event coordinates
> to LCD pixels we have a mess of different scaling factors back in user-space
> again. And the problem is setting them up properly in an installable .tbz
> or .dd image.

Why? Nothing stops you from querying the device and figure out scaling.
We do that, for example, on Chrome OS, where we do not have 1:1 matching
between LCDs and touch controllers, and still we do not have static
transformation matrices on the file system either.

> 
> Recently, you have raised another topic I had indeed not thought abut, which is
> the potential subpixel precision of a resistive touch. You get approx. 12
> bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
> bit. So scaling the input event coordinates to pixels throws away 3 bits.
> 
> But there are two things to consider.
> 
> One is that we could set the pre-calibration to keep as much resolution as
> possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
> 
> Unfortunately that differs between devices and hence we need not only
> different DTBs (which we already have) but different scale factors in user-space.
> 
> Next, one could argue that subpixel coordinates should not be handled by
> scaling input event coordinates up and then down again in user-space. The
> correct solution would be that input events could report fixed or floating
> point coordinates, but this is probably beyond what we all want to do.
> 
> The other thing is noise. No resistive touch screen I have seen in the wild with
> the tsc2007 or tsc2046 controller has the precision to really report subpixels.
> Rather we have to set the fuzz between 3 or 10 or so. Which means that those
> bits we cut off by scaling to screen coordinates are already lost in noise.

I really do not care what exactly tsc2007 or any other particular
touchscreen controller does. Please design your software so that it can
use wide range of devices, from noisy to noiseless. If there is noise,
filter it out. It there is a nice touch controller with a lot of
precision - use it, do not dumb it down to the lowest common
denominator.

> 
> > 
> > I'd be more open to allowing setting the "min-axis" values to allow
> > reporting typical range for given device, and let userspace scale as it
> > sees fit.
> 
> The problem is: what is "typical range"? It turns out to be a completely
> arbitrary definition.
> 
> I see a choice between:
> a) full theoretical ADC range
> b) millimeters
> c) pixels of the LCD the touch is glued to

d) Native reporting units for the touch controller. You will have the
touch controller output range, you will have your LCD screen size, and
you scale one into another.

> 
> For me, the most natural and practical "typical range" still seems to be the
> pixels of the lcd panel the touch is glued onto.
> 
> The reason why I see it as superior to the others is that only this leads to
> a stable 1:1 mapping in user-space avoiding to adjust any factors there.
> 
> And this 1:1 saves a lot of configuration hassle if you swap GUI systems
> (X, Wayland, Android, DirectFB, fb based Qt, ...).

Yes, they will need to do that, if they want to use "nice" hardware and
not lose precision. And since they need to do that anyway, there is no
point in doing it in kernel, not with per driver code, and not even in
input core.

You are getting this feedback from several people, please consider topic
of adding scaling to the drivers closed. The only transformations that I
think make sense is to "normalize" output with axis swaps and
inversions, so that kernel uses the same notion of coordinates for all
devices, regardless of how the device was mounted.

> 
> > 
> >> 
> >>> 
> >>>> 
> >>>> Please note that the old ti,fuzz properties have been removed since they
> >>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> >>>> 
> >>>> Finally, calculate_pressure has been renamed to calculate_resistance
> >>>> because that is what it is doing.
> >>> 
> >>> That is not what your patch does though. In the presence of
> >>> "ti,report-resistance" parameter you start reporting resistance through
> >>> ABS_PRESSURE
> >> 
> >> Well, there is some historic confusion wether this driver reports resistance
> >> or pressure.
> >> 
> >> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> >> the fly (because a separate patch is much more complex than doing it right
> >> immediately).
> >> 
> >> This ti,report-resistance property is a means to get the old (wrong) meaning back
> >> in case someone urgently needs it and can't fix the user-space workaround which
> >> he must be using.
> >> 
> >> 
> >> AFAIK there is no mainline board using the DT except ours (and the upcoming
> >> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> >> compatibility property. We don't need it for our devices.
> >> 
> > 
> > You seem to be treating DT data as something very fluid, which is wrong.
> 
> No,only sometimes.
> 
> Of course it should be done right once. Of course there is long discussion about
> what is right...
> 
> > You need to treat it as a firmware, unlikely to change once device is
> > shipped. Unlike legacy platform data, the fact that DTS files are not
> > present in mainline does not mean that we can ignore such users and
> > change behavior at will.
> 
> Well, it happens to me as maintainer of a 99.5% mainline device every
> now and then. Of course this should not be an argument to do it equally bad here.
> 
> One more thought: for some devices it is easier to modify the DTB "firmware"
> than the user space (e.g. if you have no access to it because it is maintained
> by somebody else).

And still, according to DT folks, device tree forms an ABI and thus we
are not to change it, even if it is easy.

> 
> > 
> > That said, if driver behavior is out of line from the subsystem
> > expectations, we need to fix it.
> > 
> > 
> >> That the function name is wrong is a second issue and this double negation might
> >> confuse a litte.
> >> 
> >> Please test on a real device if the patched driver reports pressure now (unless
> >> ti,report-resistance is specified).
> > 
> > I unfortunately can not test this driver as I do not have the hardware.
> 
> Ah, ok. This is indeed a road block.
> 
> Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
> 
> > So all my observations are from code and data sheets.
> 
> > That said, what is the values emitted as ABS_PRESSURE when finger is not
> > touching the device, barely touching the device, or pressing firmly?
> 
> > It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> > confusion as to what is being reported.
> 
> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
> pressing more firmly. This is not "pressure". The other drivers (I have tested
> the OpenPandora with tsc2046) are doing it in a monotonic curve.

OK, then this is clearly wrong and we need to fix it (without any funky
flags).

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

Hi Nikolaus,

On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > Hi Nikolaus,
> > 
> > On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >> 
> >>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>> 
> >>> Hi Nikolaus,
> >>> 
> >>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
> >>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> >>>> introduced common DT bindings for touchscreens [1] and a helper function to
> >>>> parse the DT.
> >>>> 
> >>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
> >>>> added another helper for parsing axis inversion and swapping
> >>>> and applying them to x and y coordinates.
> >>>> 
> >>>> Both helpers have been integrated to accommodate any orientation of the
> >>>> touch panel in relation to the LCD.
> >>>> 
> >>>> A new feature is to introduce scaling the min/max ADC values to the screen
> >>>> size.
> >>>> 
> >>>> This makes it possible to pre-calibrate the touch so that is (almost)
> >>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
> >>>> well enough operate the touch before a user space calibration step can
> >>>> improve the precision.
> >>> 
> >>> I question whether doing scaling in kernel is really right solution.
> >> 
> >> Since lower left corner does not exactly report [0 0] and upper right corner
> >> does not report [4095 4095] from the ADC we need offset and steepness correction
> >> of the ADC values.
> >> 
> >> This steepness is the scaling that must happen in kernel and I don't understand
> >> why you want to propagate this ADC errors to user-space by avoiding scaling.
> >> 
> >> Let me iterate what we want to achieve:
> >> * use new common bindings
> >> * offset and steepness calibration of the ADC (called pre-calibration).
> >>  This makes a real device much more reliable to operate with factory installed
> >>  scaling factors.
> >> * flipping and rotation
> >> 
> >> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
> > 
> > That was explicitly called out in the patch:
> > 
> > "A new feature is to introduce scaling the min/max ADC values to the
> > screen size."
> 

> Because it is a feature that was not planned nor required, but is
> there. So it came into the description of what can be done. If this is
> the key problem I am happy with removing it from the commit messages.
> 
> Anyways, scaling to screen coordinates is not my invention. It is
> based on
> 
> 	http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> which defines the size to be in pixels. Well, a resistive touch screen
> does not have pixels.  It might have a resolution/precision given by
> the ADC conversion steps but I assume this is not meant here.
> 
> So this scaling to screen size was also stimulated by this DT
> bindings.
> 

OK, now I see where you are coming from. You assume that pixels
mentioned in the DT binding are LCD pixels, however this is incorrect.
They are "pixels" or the touch controller, i.e. native unites in which
device reports coordinates, as opposed to points per inch, or
millimeters, or whatever. These "pixels" do not have to have 1:1
relation to the LCD pixels; in fact they rarely do.

Input driver may set resolution for given axis in units per mm (or units
per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
to specify the size of entire touch surface and set resolution from it
so that userspace can calculate the proper scaling factor.

> > 
> >> 
> >> Now to achieve the ADC pre-calibration we must calculate
> >> 
> >> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
> >> 
> >> This is scaled up to what is defined by touchscreen-size-x, i.e.
> >> 
> >> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
> >> 
> >> How do you want to avoid this scaling to take place? It happens automatically.
> >> It is not even an additional line of code. And is necessary for compensating ADC
> >> offsets and steepness.
> >> 
> >> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
> >> compensation which is essential for a device which has no means to properly
> >> calibrate before operating the device through touch.
> >> 
> >> The other option would be to avoid common bindings and set
> >> 
> >> 	touchscreen-size-x = (ti,max-x-ti,min-x)
> >> 
> >> This is heavily dependent on specific ADC offsets forwarded to user-space.
> >> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
> >> 
> >>> 
> >>> Why do you want this?
> >> 
> >> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
> >> and LCD pixels and have designed code to achieve exactly that.
> >> 
> >> This is not the case. It is just a byproduct that you can do it.
> >> 
> >> And since it is easier to understand we have made the examples this way.
> >> 
> >>> If your touch resolution is lower than your screen
> >>> then it might be useful, but if it is lower then you are losing data
> >>> that can be very helpful for gesture recognition, and I hope you design
> >>> your userspace so it can handle not only "bad" hardware, but "good" as
> >>> well. And even with "bad" there are a lot of tricks that can be done to
> >>> get "better" touch position in userspace.
> >> 
> >> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
> >> This of course reduces the touch precision to full LCD pixels. For finger-
> >> touch operated devices, subpixel precision is rarely needed.
> >> 
> >> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
> >> such an 1:1 mapping and they will be perfectly happy about this. 
> >> 
> >> But, if you can modify your user-space easily, you can also choose a different
> >> factor.
> >> 
> >> You can for example define touchscreen-size-x=<4096> and then you get almost
> >> the highest precision of the ADC and won't loose any bits. Or even define a
> >> bigger range and get steps >1 bit.
> >> 
> >> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
> >> 
> >> So effectively we get for LCD pixels when the touch sets a mouse pointer:
> >> 
> >> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
> >> 
> >> The most simple setup would then be but others are possible:
> >> 
> >> 	user-space-scale = 1
> >> 	touchscreen-size-x = LCD-size-x
> >> 
> >> Let me cite myself:
> >> 
> >>>> This makes it possible to pre-calibrate the touch so that is (almost)
> > 
> > Yes, it allows you to pre-calibrate, I get it. But you still do properly
> > calibrate later, right?
> 
> No. We want to get rid of this step unless we need to improve the precision by
> some tiny %.
> 
> Why do we want to get rid of it?
> 
> This needs a longer explanation.
> 
> First of all we are working on the Letux distribution which aims at supporting
> multiple devices in the same way and with a single SD card image that contains
> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
> and DTB files for each supported device.
> 
> One of the ideas is to allow users to swap the SD card from one device to the
> other. This means that the touch screen calibration must magically be carried
> along - or we enforce to recalibrate every time the sd card is swapped back or
> forth.
> 
> The same is true for prebuilt SD-images. To have a single (no longer device specific)
> download requires to have a well defined default calibration. Especially on
> devices where you have no keyboard where you can ask the user to manually fine-tune
> something.
> 
> Our challenge is to make it work well without asking for explicit calibration.
> This is where pre-calibration comes into the game.
> 
> It turns out to be related to the touch screen properties and how it is glued onto
> the specific LCD panel, i.e. hardware and its description.
> 
> So the natural location of defining this relation is the DTB for each device
> and not the user-space. And it happens that we already have one per device
> (touch screen, lcd, tsc variant) on the SD card.
> 
> > So you are doing double work here, once in
> > kernel, and second time in userspace.
> 
> This is no longer required, as long as we can use the default 1:1 coordinate mapping
> of e.g. framebuffer or X11 based GUI toolkits.
> 
> If we don't have the 1:1 mapping of touch screen input event coordinates
> to LCD pixels we have a mess of different scaling factors back in user-space
> again. And the problem is setting them up properly in an installable .tbz
> or .dd image.

Why? Nothing stops you from querying the device and figure out scaling.
We do that, for example, on Chrome OS, where we do not have 1:1 matching
between LCDs and touch controllers, and still we do not have static
transformation matrices on the file system either.

> 
> Recently, you have raised another topic I had indeed not thought abut, which is
> the potential subpixel precision of a resistive touch. You get approx. 12
> bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
> bit. So scaling the input event coordinates to pixels throws away 3 bits.
> 
> But there are two things to consider.
> 
> One is that we could set the pre-calibration to keep as much resolution as
> possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
> 
> Unfortunately that differs between devices and hence we need not only
> different DTBs (which we already have) but different scale factors in user-space.
> 
> Next, one could argue that subpixel coordinates should not be handled by
> scaling input event coordinates up and then down again in user-space. The
> correct solution would be that input events could report fixed or floating
> point coordinates, but this is probably beyond what we all want to do.
> 
> The other thing is noise. No resistive touch screen I have seen in the wild with
> the tsc2007 or tsc2046 controller has the precision to really report subpixels.
> Rather we have to set the fuzz between 3 or 10 or so. Which means that those
> bits we cut off by scaling to screen coordinates are already lost in noise.

I really do not care what exactly tsc2007 or any other particular
touchscreen controller does. Please design your software so that it can
use wide range of devices, from noisy to noiseless. If there is noise,
filter it out. It there is a nice touch controller with a lot of
precision - use it, do not dumb it down to the lowest common
denominator.

> 
> > 
> > I'd be more open to allowing setting the "min-axis" values to allow
> > reporting typical range for given device, and let userspace scale as it
> > sees fit.
> 
> The problem is: what is "typical range"? It turns out to be a completely
> arbitrary definition.
> 
> I see a choice between:
> a) full theoretical ADC range
> b) millimeters
> c) pixels of the LCD the touch is glued to

d) Native reporting units for the touch controller. You will have the
touch controller output range, you will have your LCD screen size, and
you scale one into another.

> 
> For me, the most natural and practical "typical range" still seems to be the
> pixels of the lcd panel the touch is glued onto.
> 
> The reason why I see it as superior to the others is that only this leads to
> a stable 1:1 mapping in user-space avoiding to adjust any factors there.
> 
> And this 1:1 saves a lot of configuration hassle if you swap GUI systems
> (X, Wayland, Android, DirectFB, fb based Qt, ...).

Yes, they will need to do that, if they want to use "nice" hardware and
not lose precision. And since they need to do that anyway, there is no
point in doing it in kernel, not with per driver code, and not even in
input core.

You are getting this feedback from several people, please consider topic
of adding scaling to the drivers closed. The only transformations that I
think make sense is to "normalize" output with axis swaps and
inversions, so that kernel uses the same notion of coordinates for all
devices, regardless of how the device was mounted.

> 
> > 
> >> 
> >>> 
> >>>> 
> >>>> Please note that the old ti,fuzz properties have been removed since they
> >>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
> >>>> 
> >>>> Finally, calculate_pressure has been renamed to calculate_resistance
> >>>> because that is what it is doing.
> >>> 
> >>> That is not what your patch does though. In the presence of
> >>> "ti,report-resistance" parameter you start reporting resistance through
> >>> ABS_PRESSURE
> >> 
> >> Well, there is some historic confusion wether this driver reports resistance
> >> or pressure.
> >> 
> >> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
> >> the fly (because a separate patch is much more complex than doing it right
> >> immediately).
> >> 
> >> This ti,report-resistance property is a means to get the old (wrong) meaning back
> >> in case someone urgently needs it and can't fix the user-space workaround which
> >> he must be using.
> >> 
> >> 
> >> AFAIK there is no mainline board using the DT except ours (and the upcoming
> >> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
> >> compatibility property. We don't need it for our devices.
> >> 
> > 
> > You seem to be treating DT data as something very fluid, which is wrong.
> 
> No,only sometimes.
> 
> Of course it should be done right once. Of course there is long discussion about
> what is right...
> 
> > You need to treat it as a firmware, unlikely to change once device is
> > shipped. Unlike legacy platform data, the fact that DTS files are not
> > present in mainline does not mean that we can ignore such users and
> > change behavior at will.
> 
> Well, it happens to me as maintainer of a 99.5% mainline device every
> now and then. Of course this should not be an argument to do it equally bad here.
> 
> One more thought: for some devices it is easier to modify the DTB "firmware"
> than the user space (e.g. if you have no access to it because it is maintained
> by somebody else).

And still, according to DT folks, device tree forms an ABI and thus we
are not to change it, even if it is easy.

> 
> > 
> > That said, if driver behavior is out of line from the subsystem
> > expectations, we need to fix it.
> > 
> > 
> >> That the function name is wrong is a second issue and this double negation might
> >> confuse a litte.
> >> 
> >> Please test on a real device if the patched driver reports pressure now (unless
> >> ti,report-resistance is specified).
> > 
> > I unfortunately can not test this driver as I do not have the hardware.
> 
> Ah, ok. This is indeed a road block.
> 
> Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
> 
> > So all my observations are from code and data sheets.
> 
> > That said, what is the values emitted as ABS_PRESSURE when finger is not
> > touching the device, barely touching the device, or pressing firmly?
> 
> > It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> > confusion as to what is being reported.
> 
> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
> pressing more firmly. This is not "pressure". The other drivers (I have tested
> the OpenPandora with tsc2046) are doing it in a monotonic curve.

OK, then this is clearly wrong and we need to fix it (without any funky
flags).

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Sebastian,

> Am 19.02.2017 um 21:15 schrieb Sebastian Reichel <sre@kernel.org>:
> 
> Hi,
> 
> On Sun, Feb 19, 2017 at 01:07:26PM +0100, H. Nikolaus Schaller wrote:
>> I don't really remember when we noticed it first. Maybe it was
>> back in tslib times some years ago where setting the sensitivity
>> threshold made problems. We then carried along our patch for a
>> long time in our local repo (and modified it several times) and
>> only started upstreaming some months ago. [...]
>> 
>> AFAIK, GIMP and for example https://sourceforge.net/projects/xournal/ appear
>> to be able to handle X pressure, but I haven't running and tested either one
>> on our devices. Pressure is used in such drawing tools to simulate that some
>> physical pens make wider strokes on higher pressure.
>> 
>> This seems to indicate that X can handle pressure in a non-boolean way, but rarely does.
>> Especially I think the usual menu, click, drag, scroll gestures are only based
>> on BTN_TOUCH status and not on ABS_PRESSURE. So it is rarely noticed to make
>> a difference.
> 
> ok.
> 
>>>>> I suggest to put the resistance vs pressure thing in its own patch,
>>>>> that also fixes tsc200x-core and merge it to linux-next after the
>>>>> merge window.
>> 
>> Ok. I will propose a patch.
> 
> Thanks. I suggest to add this in the patch description:
> 
> While this patch changes the values reported to userspace,
> ABS_PRESSURE is used rarely by userspace. Most software only
> relies on BTN_TOUCH (boolean), which is not affected by this
> patch. Some graphics software makes use of the interface and
> does not work correctly with the currently used inverted
> behaviour.

Added. Patch set will come in some minutes (have to run checkpatch
first).

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Sebastian,

> Am 19.02.2017 um 21:15 schrieb Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> 
> Hi,
> 
> On Sun, Feb 19, 2017 at 01:07:26PM +0100, H. Nikolaus Schaller wrote:
>> I don't really remember when we noticed it first. Maybe it was
>> back in tslib times some years ago where setting the sensitivity
>> threshold made problems. We then carried along our patch for a
>> long time in our local repo (and modified it several times) and
>> only started upstreaming some months ago. [...]
>> 
>> AFAIK, GIMP and for example https://sourceforge.net/projects/xournal/ appear
>> to be able to handle X pressure, but I haven't running and tested either one
>> on our devices. Pressure is used in such drawing tools to simulate that some
>> physical pens make wider strokes on higher pressure.
>> 
>> This seems to indicate that X can handle pressure in a non-boolean way, but rarely does.
>> Especially I think the usual menu, click, drag, scroll gestures are only based
>> on BTN_TOUCH status and not on ABS_PRESSURE. So it is rarely noticed to make
>> a difference.
> 
> ok.
> 
>>>>> I suggest to put the resistance vs pressure thing in its own patch,
>>>>> that also fixes tsc200x-core and merge it to linux-next after the
>>>>> merge window.
>> 
>> Ok. I will propose a patch.
> 
> Thanks. I suggest to add this in the patch description:
> 
> While this patch changes the values reported to userspace,
> ABS_PRESSURE is used rarely by userspace. Most software only
> relies on BTN_TOUCH (boolean), which is not affected by this
> patch. Some graphics software makes use of the interface and
> does not work correctly with the currently used inverted
> behaviour.

Added. Patch set will come in some minutes (have to run checkpatch
first).

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> hi!
> 
>>>> But as said I don't think we need float or fixed point for practical systems
>>>> at all.
>>> 
>>> So you are going to loose precision. And if userspace decides to
>>> calibrate it slightly differently from kernel, lost precision will
>>> matter.
>> 
>> Really?
> 
> Really.
> 
>> Example:
>> 
>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
>> 
>> This is scaled to let's say 0..640.
> 
> Ok. Now userspace realizes that kernel alignemnt is off, and it would
> want to scale it to 1..642.

Screen coordinates are still 0..639.

> That will mean that single pixel will be
> inaccessible, right?

Yes, that can happen if the additional user-space scale is > 1.0.

As long as it is small (I expect <1.01 = 1% error in scale) it is
barely noticeable.

Therefore, I asked before: how big in pixels is your finger or stylus?
Does this effect matter?

A resistive touch is a man-machine-interface where people press buttons of at
least 12x12 pixels size (or they are no longer visually recognizable).

A resistive touch is not intended to be a high-precision measurement instrument.

So the discussion boils down to "what gives the better usability?":
a) getting rid of the nasty user-space calibration step (and plethora of different tools)
b) getting highest theoretical precision which has a low practical relevance

I am in favor of a). Like most users we ask. A minority is in favor of b).
Since we don't exclude b) users from reconfiguring their system to get it done
as they like. I think this is the best we can achieve.

> 
>>> No. You have to design interface such that they _can_ be improved, and
>>> what you propose does not work that way.
>> 
>> It works. Please do real world tests...
> 
> You do a real world test on N900, and propose upgrade path.

I have no N900 running. But since it uses a tsc2004/5 controller which seems
to be quite similar, you can likely copy&paste some code or add the algorithm:

ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)

Thats it.

If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
user-space gets what it would have got before adding such a formula and then you
can and must do calibration there.

Taking this as the defaults if none of the new properties is specified, makes
the scaling feature completely disappear. And I don't care about 2 additional
subtractions, one multiplication and one division per axis.

So the upgrade path is:
1. introduce new optional properties, parse and store them in the struct
2. set defaults for the optional properties as described above
3. add the formula to the code (1 line for each axis)
4. deploy - nobody will notice
5. update the DT and remove user-space calibration - people will be happy
   that they do not have to calibrate first any more

> 
>>> Yes. I want to prevent you from pushing crap into the kernel.
>> 
>> Crap? Well, we have discussed this driver for months here on the list and
>> after a lot of improvements we came up to v9.
>> 
>> And you still think it is crap and none of the other reviewers has noticed?
> 
> I'm pretty sure you will not be able to push calibration into kernel.

> 
>>> Userspace has to know how to do the calibration _anyway_ (for
>>> other hardware),
>> 
>> What for? I do not understand which other hardware you are talking about.
>> 
>> On our devices there is only one touch glued to the panel and that one
>> has to be calibrated. Ideally before the user gets the device into his
>> hands => precalibration...
>> 
>> If you connect a digitizer, then that one has to be calibrated of course,
>> but it is not glued onto the display panel. Hence it is a different
>> issue.
> 
> It is actually same issue. One kernel interface should work for all
> the touchscreens.

Do we propose a different kernel interface? We propose to still use input events.
There is no change at all here.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> hi!
> 
>>>> But as said I don't think we need float or fixed point for practical systems
>>>> at all.
>>> 
>>> So you are going to loose precision. And if userspace decides to
>>> calibrate it slightly differently from kernel, lost precision will
>>> matter.
>> 
>> Really?
> 
> Really.
> 
>> Example:
>> 
>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
>> 
>> This is scaled to let's say 0..640.
> 
> Ok. Now userspace realizes that kernel alignemnt is off, and it would
> want to scale it to 1..642.

Screen coordinates are still 0..639.

> That will mean that single pixel will be
> inaccessible, right?

Yes, that can happen if the additional user-space scale is > 1.0.

As long as it is small (I expect <1.01 = 1% error in scale) it is
barely noticeable.

Therefore, I asked before: how big in pixels is your finger or stylus?
Does this effect matter?

A resistive touch is a man-machine-interface where people press buttons of at
least 12x12 pixels size (or they are no longer visually recognizable).

A resistive touch is not intended to be a high-precision measurement instrument.

So the discussion boils down to "what gives the better usability?":
a) getting rid of the nasty user-space calibration step (and plethora of different tools)
b) getting highest theoretical precision which has a low practical relevance

I am in favor of a). Like most users we ask. A minority is in favor of b).
Since we don't exclude b) users from reconfiguring their system to get it done
as they like. I think this is the best we can achieve.

> 
>>> No. You have to design interface such that they _can_ be improved, and
>>> what you propose does not work that way.
>> 
>> It works. Please do real world tests...
> 
> You do a real world test on N900, and propose upgrade path.

I have no N900 running. But since it uses a tsc2004/5 controller which seems
to be quite similar, you can likely copy&paste some code or add the algorithm:

ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)

Thats it.

If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
user-space gets what it would have got before adding such a formula and then you
can and must do calibration there.

Taking this as the defaults if none of the new properties is specified, makes
the scaling feature completely disappear. And I don't care about 2 additional
subtractions, one multiplication and one division per axis.

So the upgrade path is:
1. introduce new optional properties, parse and store them in the struct
2. set defaults for the optional properties as described above
3. add the formula to the code (1 line for each axis)
4. deploy - nobody will notice
5. update the DT and remove user-space calibration - people will be happy
   that they do not have to calibrate first any more

> 
>>> Yes. I want to prevent you from pushing crap into the kernel.
>> 
>> Crap? Well, we have discussed this driver for months here on the list and
>> after a lot of improvements we came up to v9.
>> 
>> And you still think it is crap and none of the other reviewers has noticed?
> 
> I'm pretty sure you will not be able to push calibration into kernel.

> 
>>> Userspace has to know how to do the calibration _anyway_ (for
>>> other hardware),
>> 
>> What for? I do not understand which other hardware you are talking about.
>> 
>> On our devices there is only one touch glued to the panel and that one
>> has to be calibrated. Ideally before the user gets the device into his
>> hands => precalibration...
>> 
>> If you connect a digitizer, then that one has to be calibrated of course,
>> but it is not glued onto the display panel. Hence it is a different
>> issue.
> 
> It is actually same issue. One kernel interface should work for all
> the touchscreens.

Do we propose a different kernel interface? We propose to still use input events.
There is no change at all here.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 02:07 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> Hi Nikolaus,
> 
> On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>> 
>>>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>> 
>>>>> Hi Nikolaus,
>>>>> 
>>>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>>>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>>>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>>>>> parse the DT.
>>>>>> 
>>>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>>>> added another helper for parsing axis inversion and swapping
>>>>>> and applying them to x and y coordinates.
>>>>>> 
>>>>>> Both helpers have been integrated to accommodate any orientation of the
>>>>>> touch panel in relation to the LCD.
>>>>>> 
>>>>>> A new feature is to introduce scaling the min/max ADC values to the screen
>>>>>> size.
>>>>>> 
>>>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>>>>>> well enough operate the touch before a user space calibration step can
>>>>>> improve the precision.
>>>>> 
>>>>> I question whether doing scaling in kernel is really right solution.
>>>> 
>>>> Since lower left corner does not exactly report [0 0] and upper right corner
>>>> does not report [4095 4095] from the ADC we need offset and steepness correction
>>>> of the ADC values.
>>>> 
>>>> This steepness is the scaling that must happen in kernel and I don't understand
>>>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>>>> 
>>>> Let me iterate what we want to achieve:
>>>> * use new common bindings
>>>> * offset and steepness calibration of the ADC (called pre-calibration).
>>>> This makes a real device much more reliable to operate with factory installed
>>>> scaling factors.
>>>> * flipping and rotation
>>>> 
>>>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
>>> 
>>> That was explicitly called out in the patch:
>>> 
>>> "A new feature is to introduce scaling the min/max ADC values to the
>>> screen size."
>> 
> 
>> Because it is a feature that was not planned nor required, but is
>> there. So it came into the description of what can be done. If this is
>> the key problem I am happy with removing it from the commit messages.
>> 
>> Anyways, scaling to screen coordinates is not my invention. It is
>> based on
>> 
>> 	http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>> 
>> which defines the size to be in pixels. Well, a resistive touch screen
>> does not have pixels.  It might have a resolution/precision given by
>> the ADC conversion steps but I assume this is not meant here.
>> 
>> So this scaling to screen size was also stimulated by this DT
>> bindings.
>> 
> 
> OK, now I see where you are coming from. You assume that pixels
> mentioned in the DT binding are LCD pixels,

Yes. Because that makes a lot of sense to me to understand it that way.

> however this is incorrect.

How should I know that, if it is not explicitly defined?

We even had the very same discussion some months ago during v2 or v3,
if I remember correctly. Sebastian raised some concerns about the interpretation
back then but I though that it was clarified and accepted how I interpret
it. At least there were no complaints about it but a lot of valuable comments
to improve the code. So we are now at v9.

> They are "pixels" or the touch controller, i.e. native unites in which
> device reports coordinates, as opposed to points per inch, or
> millimeters, or whatever. These "pixels" do not have to have 1:1
> relation to the LCD pixels; in fact they rarely do.

I wouldn't call this "pixels". Rather "ADC steps" or something.

"Pixels" are picture elements for me and a touch has no picture. It is
an input device. Hence my assumption that it must clearly mean the LCD
pixels it is glued to. And nothing else.

What I don't understand with your definition is why it is in the DT
at all. The driver is 100% tied to a specific chip. So this is a hard
data sheet constant for all tsc2007 chips which can be compiled into
the driver binary. It does not even need to be defined in a DT "firmware".

This was another reason why I though this can not be meant by pixels
in the DT bindings.

And from a theoretical point of view the units are even completely
arbitrary. Loss of precision is only a factor here if you do not have
subpixel reporting to the input layer. But that is an implementation
detail and has nothing to do with the bindings.

Anyways, You can simply set "touchscreen-size = 4096" for your tsc2007
system and you get from the driver the maximum precision it can ever provide.
This is what it did before and what you expect.

So please notice it is not an either or. It is an as well as what we propose.
Defined by the formulae used for scaling.

> 
> Input driver may set resolution for given axis in units per mm (or units
> per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
> check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
> to specify the size of entire touch surface and set resolution from it
> so that userspace can calculate the proper scaling factor.

How is this information exposed by the kernel to user-space? By scanning the DT file
or tree?

> 
>>> 
>>>> 
>>>> Now to achieve the ADC pre-calibration we must calculate
>>>> 
>>>> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
>>>> 
>>>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>>> 
>>>> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>>>> 
>>>> How do you want to avoid this scaling to take place? It happens automatically.
>>>> It is not even an additional line of code. And is necessary for compensating ADC
>>>> offsets and steepness.
>>>> 
>>>> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
>>>> compensation which is essential for a device which has no means to properly
>>>> calibrate before operating the device through touch.
>>>> 
>>>> The other option would be to avoid common bindings and set
>>>> 
>>>> 	touchscreen-size-x = (ti,max-x-ti,min-x)
>>>> 
>>>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>>>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>>>> 
>>>>> 
>>>>> Why do you want this?
>>>> 
>>>> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
>>>> and LCD pixels and have designed code to achieve exactly that.
>>>> 
>>>> This is not the case. It is just a byproduct that you can do it.
>>>> 
>>>> And since it is easier to understand we have made the examples this way.
>>>> 
>>>>> If your touch resolution is lower than your screen
>>>>> then it might be useful, but if it is lower then you are losing data
>>>>> that can be very helpful for gesture recognition, and I hope you design
>>>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>>>> well. And even with "bad" there are a lot of tricks that can be done to
>>>>> get "better" touch position in userspace.
>>>> 
>>>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>>>> This of course reduces the touch precision to full LCD pixels. For finger-
>>>> touch operated devices, subpixel precision is rarely needed.
>>>> 
>>>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>>>> such an 1:1 mapping and they will be perfectly happy about this. 
>>>> 
>>>> But, if you can modify your user-space easily, you can also choose a different
>>>> factor.
>>>> 
>>>> You can for example define touchscreen-size-x=<4096> and then you get almost
>>>> the highest precision of the ADC and won't loose any bits. Or even define a
>>>> bigger range and get steps >1 bit.
>>>> 
>>>> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
>>>> 
>>>> So effectively we get for LCD pixels when the touch sets a mouse pointer:
>>>> 
>>>> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
>>>> 
>>>> The most simple setup would then be but others are possible:
>>>> 
>>>> 	user-space-scale = 1
>>>> 	touchscreen-size-x = LCD-size-x
>>>> 
>>>> Let me cite myself:
>>>> 
>>>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>> 
>>> Yes, it allows you to pre-calibrate, I get it. But you still do properly
>>> calibrate later, right?
>> 
>> No. We want to get rid of this step unless we need to improve the precision by
>> some tiny %.
>> 
>> Why do we want to get rid of it?
>> 
>> This needs a longer explanation.
>> 
>> First of all we are working on the Letux distribution which aims at supporting
>> multiple devices in the same way and with a single SD card image that contains
>> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
>> and DTB files for each supported device.
>> 
>> One of the ideas is to allow users to swap the SD card from one device to the
>> other. This means that the touch screen calibration must magically be carried
>> along - or we enforce to recalibrate every time the sd card is swapped back or
>> forth.
>> 
>> The same is true for prebuilt SD-images. To have a single (no longer device specific)
>> download requires to have a well defined default calibration. Especially on
>> devices where you have no keyboard where you can ask the user to manually fine-tune
>> something.
>> 
>> Our challenge is to make it work well without asking for explicit calibration.
>> This is where pre-calibration comes into the game.
>> 
>> It turns out to be related to the touch screen properties and how it is glued onto
>> the specific LCD panel, i.e. hardware and its description.
>> 
>> So the natural location of defining this relation is the DTB for each device
>> and not the user-space. And it happens that we already have one per device
>> (touch screen, lcd, tsc variant) on the SD card.
>> 
>>> So you are doing double work here, once in
>>> kernel, and second time in userspace.
>> 
>> This is no longer required, as long as we can use the default 1:1 coordinate mapping
>> of e.g. framebuffer or X11 based GUI toolkits.
>> 
>> If we don't have the 1:1 mapping of touch screen input event coordinates
>> to LCD pixels we have a mess of different scaling factors back in user-space
>> again. And the problem is setting them up properly in an installable .tbz
>> or .dd image.
> 
> Why? Nothing stops you from querying the device and figure out scaling.

What stops me is that I have no (and do not want to have) that level of control over
user-space code.

I can't change Debian, AchLinux, Ubuntu, Replicant, and 100 other systems in parallel
to make the touch work as we want to have it, i.e. precalibrated.

BTW, there is a tendency to point to the kernel to do it right...

> We do that, for example, on Chrome OS, where we do not have 1:1 matching
> between LCDs and touch controllers, and still we do not have static
> transformation matrices on the file system either.

Yes, of course it can be solved that way. We could even go further and develop
a touch screen interface by using /dev/i2c. This avoids having a tsc2007 driver
at all. And all other touch screen drivers can be removed as well. It is all
possible, but IMHO not reasonable for good reasons.

> 
>> 
>> Recently, you have raised another topic I had indeed not thought abut, which is
>> the potential subpixel precision of a resistive touch. You get approx. 12
>> bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
>> bit. So scaling the input event coordinates to pixels throws away 3 bits.
>> 
>> But there are two things to consider.
>> 
>> One is that we could set the pre-calibration to keep as much resolution as
>> possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
>> 
>> Unfortunately that differs between devices and hence we need not only
>> different DTBs (which we already have) but different scale factors in user-space.
>> 
>> Next, one could argue that subpixel coordinates should not be handled by
>> scaling input event coordinates up and then down again in user-space. The
>> correct solution would be that input events could report fixed or floating
>> point coordinates, but this is probably beyond what we all want to do.
>> 
>> The other thing is noise. No resistive touch screen I have seen in the wild with
>> the tsc2007 or tsc2046 controller has the precision to really report subpixels.
>> Rather we have to set the fuzz between 3 or 10 or so. Which means that those
>> bits we cut off by scaling to screen coordinates are already lost in noise.
> 
> I really do not care what exactly tsc2007 or any other particular
> touchscreen controller does. Please design your software so that it can
> use wide range of devices, from noisy to noiseless. If there is noise,
> filter it out.

1. noise is an unavoidable physical phenomenon for resistive touch + ADC
2. filtering noise is what the input layer is doing by the fuzz factor. So it is one layer
above the tsc2007 driver.

> It there is a nice touch controller with a lot of
> precision - use it,

I still do not see how this patch influences non-tsc2007 touch controllers.

I explained how the tsc2007 can be used with full precision. Either by providing
a different value for touchscreen-size and recompiling the DTB or by using subpixel
coordinates in input events.

> do not dumb it down to the lowest common
> denominator.
> 
>> 
>>> 
>>> I'd be more open to allowing setting the "min-axis" values to allow
>>> reporting typical range for given device, and let userspace scale as it
>>> sees fit.
>> 
>> The problem is: what is "typical range"? It turns out to be a completely
>> arbitrary definition.
>> 
>> I see a choice between:
>> a) full theoretical ADC range
>> b) millimeters
>> c) pixels of the LCD the touch is glued to
> 
> d) Native reporting units for the touch controller. You will have the
> touch controller output range, you will have your LCD screen size, and
> you scale one into another.

That is exactly what I mean with a) ("full theoretical ADC range" = "touch controller output range"),
so it is not a new alternative.

IMHO c) is the right and natural default.

> 
>> 
>> For me, the most natural and practical "typical range" still seems to be the
>> pixels of the lcd panel the touch is glued onto.
>> 
>> The reason why I see it as superior to the others is that only this leads to
>> a stable 1:1 mapping in user-space avoiding to adjust any factors there.
>> 
>> And this 1:1 saves a lot of configuration hassle if you swap GUI systems
>> (X, Wayland, Android, DirectFB, fb based Qt, ...).
> 
> Yes, they will need to do that, if they want to use "nice" hardware and
> not lose precision.

This is where I think a proper solution for not loosing precision would be to
introduce subpixel reporting to the input layer.

But in our practical experience with real devices, people complained that the
touch is misaligned. But nobody complained about loss of precision so far. It
came up here as a theoretical discussion in a quite late phase for the first
time.

> And since they need to do that anyway, there is no
> point in doing it in kernel, not with per driver code, and not even in
> input core.
> 
> You are getting this feedback from several people,

So far I only know Pavel and you. Which are two.

I also have the feedback of many users of the GTA04 that the pre-calibration and
scaling is really good (when using these patches).

So I wonder what is more important: users or something else?

> please consider topic
> of adding scaling to the drivers closed.

You are of course free to decide this way since you are the maintainer. I just
want to note for the records that you ignore user's wishes. I hope this is not
a general phenomenon.

> The only transformations that I
> think make sense is to "normalize" output with axis swaps and
> inversions, so that kernel uses the same notion of coordinates for all
> devices, regardless of how the device was mounted.

Who will do that?

Do you expect that I submit a version which lacks one feature I think it
is important? And one which is difficult to not implement by accident if you
want to use the common touchscreen bindings?

> 
> 
>> 
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> Please note that the old ti,fuzz properties have been removed since they
>>>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>>>> 
>>>>>> Finally, calculate_pressure has been renamed to calculate_resistance
>>>>>> because that is what it is doing.
>>>>> 
>>>>> That is not what your patch does though. In the presence of
>>>>> "ti,report-resistance" parameter you start reporting resistance through
>>>>> ABS_PRESSURE
>>>> 
>>>> Well, there is some historic confusion wether this driver reports resistance
>>>> or pressure.
>>>> 
>>>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>>>> the fly (because a separate patch is much more complex than doing it right
>>>> immediately).
>>>> 
>>>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>>>> in case someone urgently needs it and can't fix the user-space workaround which
>>>> he must be using.
>>>> 
>>>> 
>>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>>> compatibility property. We don't need it for our devices.
>>>> 
>>> 
>>> You seem to be treating DT data as something very fluid, which is wrong.
>> 
>> No,only sometimes.
>> 
>> Of course it should be done right once. Of course there is long discussion about
>> what is right...
>> 
>>> You need to treat it as a firmware, unlikely to change once device is
>>> shipped. Unlike legacy platform data, the fact that DTS files are not
>>> present in mainline does not mean that we can ignore such users and
>>> change behavior at will.
>> 
>> Well, it happens to me as maintainer of a 99.5% mainline device every
>> now and then. Of course this should not be an argument to do it equally bad here.
>> 
>> One more thought: for some devices it is easier to modify the DTB "firmware"
>> than the user space (e.g. if you have no access to it because it is maintained
>> by somebody else).
> 
> And still, according to DT folks, device tree forms an ABI and thus we
> are not to change it, even if it is easy.

I think this needs a more differentiated view.

In my view the names of the binding properties and what they influence form indeed
an ABI. It should be stable and interpreted in the same way.

But it allows to load different firmware for different requirements. Like the user
application ABI is stable but you can still load different software.

So changing the value of a property in a specific .dtb file is a modified firmware
but does not change the ABI. Adding/removing properties is an ABI change.

Here, we are discussing of using different values for touchscreen-size if someone
needs higher precision and wants to do user-space scaling.

This patch neither stops anyone from doing it nor does it require anyone to use
it. Hence we give you the most flexible solution I can think of but there are complaints
because it seems to be too flexible.

So loading a "low resolution but precalibrated" firmware or loading a "high precision
firmware which needs user-space calibration step" does not change ABI.

>> 
>>> 
>>> That said, if driver behavior is out of line from the subsystem
>>> expectations, we need to fix it.
>>> 
>>> 
>>>> That the function name is wrong is a second issue and this double negation might
>>>> confuse a litte.
>>>> 
>>>> Please test on a real device if the patched driver reports pressure now (unless
>>>> ti,report-resistance is specified).
>>> 
>>> I unfortunately can not test this driver as I do not have the hardware.
>> 
>> Ah, ok. This is indeed a road block.
>> 
>> Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
>> 
>>> So all my observations are from code and data sheets.
>> 
>>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>>> touching the device, barely touching the device, or pressing firmly?
>> 
>>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>>> confusion as to what is being reported.
>> 
>> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
>> pressing more firmly. This is not "pressure". The other drivers (I have tested
>> the OpenPandora with tsc2046) are doing it in a monotonic curve.
> 
> OK, then this is clearly wrong and we need to fix it (without any funky
> flags).

I am almost done with a patch series for this as promised to Sebastian.
Comes in some minutes.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 02:07 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> Hi Nikolaus,
> 
> On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>> 
>>>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>>>>> 
>>>>> Hi Nikolaus,
>>>>> 
>>>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
>>>>>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>>>>>> introduced common DT bindings for touchscreens [1] and a helper function to
>>>>>> parse the DT.
>>>>>> 
>>>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>>>> added another helper for parsing axis inversion and swapping
>>>>>> and applying them to x and y coordinates.
>>>>>> 
>>>>>> Both helpers have been integrated to accommodate any orientation of the
>>>>>> touch panel in relation to the LCD.
>>>>>> 
>>>>>> A new feature is to introduce scaling the min/max ADC values to the screen
>>>>>> size.
>>>>>> 
>>>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>>>>> exactly matches the LCD pixel coordinates it is glued onto. This allows to
>>>>>> well enough operate the touch before a user space calibration step can
>>>>>> improve the precision.
>>>>> 
>>>>> I question whether doing scaling in kernel is really right solution.
>>>> 
>>>> Since lower left corner does not exactly report [0 0] and upper right corner
>>>> does not report [4095 4095] from the ADC we need offset and steepness correction
>>>> of the ADC values.
>>>> 
>>>> This steepness is the scaling that must happen in kernel and I don't understand
>>>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>>>> 
>>>> Let me iterate what we want to achieve:
>>>> * use new common bindings
>>>> * offset and steepness calibration of the ADC (called pre-calibration).
>>>> This makes a real device much more reliable to operate with factory installed
>>>> scaling factors.
>>>> * flipping and rotation
>>>> 
>>>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
>>> 
>>> That was explicitly called out in the patch:
>>> 
>>> "A new feature is to introduce scaling the min/max ADC values to the
>>> screen size."
>> 
> 
>> Because it is a feature that was not planned nor required, but is
>> there. So it came into the description of what can be done. If this is
>> the key problem I am happy with removing it from the commit messages.
>> 
>> Anyways, scaling to screen coordinates is not my invention. It is
>> based on
>> 
>> 	http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>> 
>> which defines the size to be in pixels. Well, a resistive touch screen
>> does not have pixels.  It might have a resolution/precision given by
>> the ADC conversion steps but I assume this is not meant here.
>> 
>> So this scaling to screen size was also stimulated by this DT
>> bindings.
>> 
> 
> OK, now I see where you are coming from. You assume that pixels
> mentioned in the DT binding are LCD pixels,

Yes. Because that makes a lot of sense to me to understand it that way.

> however this is incorrect.

How should I know that, if it is not explicitly defined?

We even had the very same discussion some months ago during v2 or v3,
if I remember correctly. Sebastian raised some concerns about the interpretation
back then but I though that it was clarified and accepted how I interpret
it. At least there were no complaints about it but a lot of valuable comments
to improve the code. So we are now at v9.

> They are "pixels" or the touch controller, i.e. native unites in which
> device reports coordinates, as opposed to points per inch, or
> millimeters, or whatever. These "pixels" do not have to have 1:1
> relation to the LCD pixels; in fact they rarely do.

I wouldn't call this "pixels". Rather "ADC steps" or something.

"Pixels" are picture elements for me and a touch has no picture. It is
an input device. Hence my assumption that it must clearly mean the LCD
pixels it is glued to. And nothing else.

What I don't understand with your definition is why it is in the DT
at all. The driver is 100% tied to a specific chip. So this is a hard
data sheet constant for all tsc2007 chips which can be compiled into
the driver binary. It does not even need to be defined in a DT "firmware".

This was another reason why I though this can not be meant by pixels
in the DT bindings.

And from a theoretical point of view the units are even completely
arbitrary. Loss of precision is only a factor here if you do not have
subpixel reporting to the input layer. But that is an implementation
detail and has nothing to do with the bindings.

Anyways, You can simply set "touchscreen-size = 4096" for your tsc2007
system and you get from the driver the maximum precision it can ever provide.
This is what it did before and what you expect.

So please notice it is not an either or. It is an as well as what we propose.
Defined by the formulae used for scaling.

> 
> Input driver may set resolution for given axis in units per mm (or units
> per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
> check the binding, you can use "touchscreen-x-mm" and "touchscreen-y-mm"
> to specify the size of entire touch surface and set resolution from it
> so that userspace can calculate the proper scaling factor.

How is this information exposed by the kernel to user-space? By scanning the DT file
or tree?

> 
>>> 
>>>> 
>>>> Now to achieve the ADC pre-calibration we must calculate
>>>> 
>>>> 	x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ... 1.0
>>>> 
>>>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>>> 
>>>> 	x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>>>> 
>>>> How do you want to avoid this scaling to take place? It happens automatically.
>>>> It is not even an additional line of code. And is necessary for compensating ADC
>>>> offsets and steepness.
>>>> 
>>>> So the only way to avoid the scaling option is to eliminate the precalibration/ADC
>>>> compensation which is essential for a device which has no means to properly
>>>> calibrate before operating the device through touch.
>>>> 
>>>> The other option would be to avoid common bindings and set
>>>> 
>>>> 	touchscreen-size-x = (ti,max-x-ti,min-x)
>>>> 
>>>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>>>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>>>> 
>>>>> 
>>>>> Why do you want this?
>>>> 
>>>> It seems that you assume that we want to enforce 1:1 scaling between touch pixels
>>>> and LCD pixels and have designed code to achieve exactly that.
>>>> 
>>>> This is not the case. It is just a byproduct that you can do it.
>>>> 
>>>> And since it is easier to understand we have made the examples this way.
>>>> 
>>>>> If your touch resolution is lower than your screen
>>>>> then it might be useful, but if it is lower then you are losing data
>>>>> that can be very helpful for gesture recognition, and I hope you design
>>>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>>>> well. And even with "bad" there are a lot of tricks that can be done to
>>>>> get "better" touch position in userspace.
>>>> 
>>>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>>>> This of course reduces the touch precision to full LCD pixels. For finger-
>>>> touch operated devices, subpixel precision is rarely needed.
>>>> 
>>>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>>>> such an 1:1 mapping and they will be perfectly happy about this. 
>>>> 
>>>> But, if you can modify your user-space easily, you can also choose a different
>>>> factor.
>>>> 
>>>> You can for example define touchscreen-size-x=<4096> and then you get almost
>>>> the highest precision of the ADC and won't loose any bits. Or even define a
>>>> bigger range and get steps >1 bit.
>>>> 
>>>> LCD driver (e.g. X11 calibration matrix) can scale it down again to LCD pixels.
>>>> 
>>>> So effectively we get for LCD pixels when the touch sets a mouse pointer:
>>>> 
>>>> 	x'' = user-space-scale * <<input-event<< ((touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x))
>>>> 
>>>> The most simple setup would then be but others are possible:
>>>> 
>>>> 	user-space-scale = 1
>>>> 	touchscreen-size-x = LCD-size-x
>>>> 
>>>> Let me cite myself:
>>>> 
>>>>>> This makes it possible to pre-calibrate the touch so that is (almost)
>>> 
>>> Yes, it allows you to pre-calibrate, I get it. But you still do properly
>>> calibrate later, right?
>> 
>> No. We want to get rid of this step unless we need to improve the precision by
>> some tiny %.
>> 
>> Why do we want to get rid of it?
>> 
>> This needs a longer explanation.
>> 
>> First of all we are working on the Letux distribution which aims at supporting
>> multiple devices in the same way and with a single SD card image that contains
>> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the kernel uImage
>> and DTB files for each supported device.
>> 
>> One of the ideas is to allow users to swap the SD card from one device to the
>> other. This means that the touch screen calibration must magically be carried
>> along - or we enforce to recalibrate every time the sd card is swapped back or
>> forth.
>> 
>> The same is true for prebuilt SD-images. To have a single (no longer device specific)
>> download requires to have a well defined default calibration. Especially on
>> devices where you have no keyboard where you can ask the user to manually fine-tune
>> something.
>> 
>> Our challenge is to make it work well without asking for explicit calibration.
>> This is where pre-calibration comes into the game.
>> 
>> It turns out to be related to the touch screen properties and how it is glued onto
>> the specific LCD panel, i.e. hardware and its description.
>> 
>> So the natural location of defining this relation is the DTB for each device
>> and not the user-space. And it happens that we already have one per device
>> (touch screen, lcd, tsc variant) on the SD card.
>> 
>>> So you are doing double work here, once in
>>> kernel, and second time in userspace.
>> 
>> This is no longer required, as long as we can use the default 1:1 coordinate mapping
>> of e.g. framebuffer or X11 based GUI toolkits.
>> 
>> If we don't have the 1:1 mapping of touch screen input event coordinates
>> to LCD pixels we have a mess of different scaling factors back in user-space
>> again. And the problem is setting them up properly in an installable .tbz
>> or .dd image.
> 
> Why? Nothing stops you from querying the device and figure out scaling.

What stops me is that I have no (and do not want to have) that level of control over
user-space code.

I can't change Debian, AchLinux, Ubuntu, Replicant, and 100 other systems in parallel
to make the touch work as we want to have it, i.e. precalibrated.

BTW, there is a tendency to point to the kernel to do it right...

> We do that, for example, on Chrome OS, where we do not have 1:1 matching
> between LCDs and touch controllers, and still we do not have static
> transformation matrices on the file system either.

Yes, of course it can be solved that way. We could even go further and develop
a touch screen interface by using /dev/i2c. This avoids having a tsc2007 driver
at all. And all other touch screen drivers can be removed as well. It is all
possible, but IMHO not reasonable for good reasons.

> 
>> 
>> Recently, you have raised another topic I had indeed not thought abut, which is
>> the potential subpixel precision of a resistive touch. You get approx. 12
>> bit from the ADC but the x coordinate of the 480 pixel wide screen is just 9
>> bit. So scaling the input event coordinates to pixels throws away 3 bits.
>> 
>> But there are two things to consider.
>> 
>> One is that we could set the pre-calibration to keep as much resolution as
>> possible, ca. 12 pixels and make the user-space scale down to screen coordinates.
>> 
>> Unfortunately that differs between devices and hence we need not only
>> different DTBs (which we already have) but different scale factors in user-space.
>> 
>> Next, one could argue that subpixel coordinates should not be handled by
>> scaling input event coordinates up and then down again in user-space. The
>> correct solution would be that input events could report fixed or floating
>> point coordinates, but this is probably beyond what we all want to do.
>> 
>> The other thing is noise. No resistive touch screen I have seen in the wild with
>> the tsc2007 or tsc2046 controller has the precision to really report subpixels.
>> Rather we have to set the fuzz between 3 or 10 or so. Which means that those
>> bits we cut off by scaling to screen coordinates are already lost in noise.
> 
> I really do not care what exactly tsc2007 or any other particular
> touchscreen controller does. Please design your software so that it can
> use wide range of devices, from noisy to noiseless. If there is noise,
> filter it out.

1. noise is an unavoidable physical phenomenon for resistive touch + ADC
2. filtering noise is what the input layer is doing by the fuzz factor. So it is one layer
above the tsc2007 driver.

> It there is a nice touch controller with a lot of
> precision - use it,

I still do not see how this patch influences non-tsc2007 touch controllers.

I explained how the tsc2007 can be used with full precision. Either by providing
a different value for touchscreen-size and recompiling the DTB or by using subpixel
coordinates in input events.

> do not dumb it down to the lowest common
> denominator.
> 
>> 
>>> 
>>> I'd be more open to allowing setting the "min-axis" values to allow
>>> reporting typical range for given device, and let userspace scale as it
>>> sees fit.
>> 
>> The problem is: what is "typical range"? It turns out to be a completely
>> arbitrary definition.
>> 
>> I see a choice between:
>> a) full theoretical ADC range
>> b) millimeters
>> c) pixels of the LCD the touch is glued to
> 
> d) Native reporting units for the touch controller. You will have the
> touch controller output range, you will have your LCD screen size, and
> you scale one into another.

That is exactly what I mean with a) ("full theoretical ADC range" = "touch controller output range"),
so it is not a new alternative.

IMHO c) is the right and natural default.

> 
>> 
>> For me, the most natural and practical "typical range" still seems to be the
>> pixels of the lcd panel the touch is glued onto.
>> 
>> The reason why I see it as superior to the others is that only this leads to
>> a stable 1:1 mapping in user-space avoiding to adjust any factors there.
>> 
>> And this 1:1 saves a lot of configuration hassle if you swap GUI systems
>> (X, Wayland, Android, DirectFB, fb based Qt, ...).
> 
> Yes, they will need to do that, if they want to use "nice" hardware and
> not lose precision.

This is where I think a proper solution for not loosing precision would be to
introduce subpixel reporting to the input layer.

But in our practical experience with real devices, people complained that the
touch is misaligned. But nobody complained about loss of precision so far. It
came up here as a theoretical discussion in a quite late phase for the first
time.

> And since they need to do that anyway, there is no
> point in doing it in kernel, not with per driver code, and not even in
> input core.
> 
> You are getting this feedback from several people,

So far I only know Pavel and you. Which are two.

I also have the feedback of many users of the GTA04 that the pre-calibration and
scaling is really good (when using these patches).

So I wonder what is more important: users or something else?

> please consider topic
> of adding scaling to the drivers closed.

You are of course free to decide this way since you are the maintainer. I just
want to note for the records that you ignore user's wishes. I hope this is not
a general phenomenon.

> The only transformations that I
> think make sense is to "normalize" output with axis swaps and
> inversions, so that kernel uses the same notion of coordinates for all
> devices, regardless of how the device was mounted.

Who will do that?

Do you expect that I submit a version which lacks one feature I think it
is important? And one which is difficult to not implement by accident if you
want to use the common touchscreen bindings?

> 
> 
>> 
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> Please note that the old ti,fuzz properties have been removed since they
>>>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>>>> 
>>>>>> Finally, calculate_pressure has been renamed to calculate_resistance
>>>>>> because that is what it is doing.
>>>>> 
>>>>> That is not what your patch does though. In the presence of
>>>>> "ti,report-resistance" parameter you start reporting resistance through
>>>>> ABS_PRESSURE
>>>> 
>>>> Well, there is some historic confusion wether this driver reports resistance
>>>> or pressure.
>>>> 
>>>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on
>>>> the fly (because a separate patch is much more complex than doing it right
>>>> immediately).
>>>> 
>>>> This ti,report-resistance property is a means to get the old (wrong) meaning back
>>>> in case someone urgently needs it and can't fix the user-space workaround which
>>>> he must be using.
>>>> 
>>>> 
>>>> AFAIK there is no mainline board using the DT except ours (and the upcoming
>>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove this
>>>> compatibility property. We don't need it for our devices.
>>>> 
>>> 
>>> You seem to be treating DT data as something very fluid, which is wrong.
>> 
>> No,only sometimes.
>> 
>> Of course it should be done right once. Of course there is long discussion about
>> what is right...
>> 
>>> You need to treat it as a firmware, unlikely to change once device is
>>> shipped. Unlike legacy platform data, the fact that DTS files are not
>>> present in mainline does not mean that we can ignore such users and
>>> change behavior at will.
>> 
>> Well, it happens to me as maintainer of a 99.5% mainline device every
>> now and then. Of course this should not be an argument to do it equally bad here.
>> 
>> One more thought: for some devices it is easier to modify the DTB "firmware"
>> than the user space (e.g. if you have no access to it because it is maintained
>> by somebody else).
> 
> And still, according to DT folks, device tree forms an ABI and thus we
> are not to change it, even if it is easy.

I think this needs a more differentiated view.

In my view the names of the binding properties and what they influence form indeed
an ABI. It should be stable and interpreted in the same way.

But it allows to load different firmware for different requirements. Like the user
application ABI is stable but you can still load different software.

So changing the value of a property in a specific .dtb file is a modified firmware
but does not change the ABI. Adding/removing properties is an ABI change.

Here, we are discussing of using different values for touchscreen-size if someone
needs higher precision and wants to do user-space scaling.

This patch neither stops anyone from doing it nor does it require anyone to use
it. Hence we give you the most flexible solution I can think of but there are complaints
because it seems to be too flexible.

So loading a "low resolution but precalibrated" firmware or loading a "high precision
firmware which needs user-space calibration step" does not change ABI.

>> 
>>> 
>>> That said, if driver behavior is out of line from the subsystem
>>> expectations, we need to fix it.
>>> 
>>> 
>>>> That the function name is wrong is a second issue and this double negation might
>>>> confuse a litte.
>>>> 
>>>> Please test on a real device if the patched driver reports pressure now (unless
>>>> ti,report-resistance is specified).
>>> 
>>> I unfortunately can not test this driver as I do not have the hardware.
>> 
>> Ah, ok. This is indeed a road block.
>> 
>> Maybe someone else with a real tsc2007 hardware is reading this discussion and can comment?
>> 
>>> So all my observations are from code and data sheets.
>> 
>>> That said, what is the values emitted as ABS_PRESSURE when finger is not
>>> touching the device, barely touching the device, or pressing firmly?
>> 
>>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
>>> confusion as to what is being reported.
>> 
>> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes down when
>> pressing more firmly. This is not "pressure". The other drivers (I have tested
>> the OpenPandora with tsc2046) are doing it in a monotonic curve.
> 
> OK, then this is clearly wrong and we need to fix it (without any funky
> flags).

I am almost done with a patch series for this as promised to Sebastian.
Comes in some minutes.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 02:07 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> Hi Nikolaus,
>=20
> On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>=20
>>> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>=20
>>> Hi Nikolaus,
>>>=20
>>> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller =
wrote:
>>>> Hi Dmitry,
>>>>=20
>>>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>>>>>=20
>>>>> Hi Nikolaus,
>>>>>=20
>>>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller =
wrote:
>>>>>> commit b98abe52fa8e ("Input: add common DT binding for =
touchscreens")
>>>>>> introduced common DT bindings for touchscreens [1] and a helper =
function to
>>>>>> parse the DT.
>>>>>>=20
>>>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for =
inverted / swapped axes")
>>>>>> added another helper for parsing axis inversion and swapping
>>>>>> and applying them to x and y coordinates.
>>>>>>=20
>>>>>> Both helpers have been integrated to accommodate any orientation =
of the
>>>>>> touch panel in relation to the LCD.
>>>>>>=20
>>>>>> A new feature is to introduce scaling the min/max ADC values to =
the screen
>>>>>> size.
>>>>>>=20
>>>>>> This makes it possible to pre-calibrate the touch so that is =
(almost)
>>>>>> exactly matches the LCD pixel coordinates it is glued onto. This =
allows to
>>>>>> well enough operate the touch before a user space calibration =
step can
>>>>>> improve the precision.
>>>>>=20
>>>>> I question whether doing scaling in kernel is really right =
solution.
>>>>=20
>>>> Since lower left corner does not exactly report [0 0] and upper =
right corner
>>>> does not report [4095 4095] from the ADC we need offset and =
steepness correction
>>>> of the ADC values.
>>>>=20
>>>> This steepness is the scaling that must happen in kernel and I =
don't understand
>>>> why you want to propagate this ADC errors to user-space by avoiding =
scaling.
>>>>=20
>>>> Let me iterate what we want to achieve:
>>>> * use new common bindings
>>>> * offset and steepness calibration of the ADC (called =
pre-calibration).
>>>> This makes a real device much more reliable to operate with factory =
installed
>>>> scaling factors.
>>>> * flipping and rotation
>>>>=20
>>>> (note that touch pixel to LCD pixel scaling is not explicitly on =
this list!)
>>>=20
>>> That was explicitly called out in the patch:
>>>=20
>>> "A new feature is to introduce scaling the min/max ADC values to the
>>> screen size."
>>=20
>=20
>> Because it is a feature that was not planned nor required, but is
>> there. So it came into the description of what can be done. If this =
is
>> the key problem I am happy with removing it from the commit messages.
>>=20
>> Anyways, scaling to screen coordinates is not my invention. It is
>> based on
>>=20
>> 	=
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/inp=
ut/touchscreen/touchscreen.txt
>>=20
>> which defines the size to be in pixels. Well, a resistive touch =
screen
>> does not have pixels.  It might have a resolution/precision given by
>> the ADC conversion steps but I assume this is not meant here.
>>=20
>> So this scaling to screen size was also stimulated by this DT
>> bindings.
>>=20
>=20
> OK, now I see where you are coming from. You assume that pixels
> mentioned in the DT binding are LCD pixels,

Yes. Because that makes a lot of sense to me to understand it that way.

> however this is incorrect.

How should I know that, if it is not explicitly defined?

We even had the very same discussion some months ago during v2 or v3,
if I remember correctly. Sebastian raised some concerns about the =
interpretation
back then but I though that it was clarified and accepted how I =
interpret
it. At least there were no complaints about it but a lot of valuable =
comments
to improve the code. So we are now at v9.

> They are "pixels" or the touch controller, i.e. native unites in which
> device reports coordinates, as opposed to points per inch, or
> millimeters, or whatever. These "pixels" do not have to have 1:1
> relation to the LCD pixels; in fact they rarely do.

I wouldn't call this "pixels". Rather "ADC steps" or something.

"Pixels" are picture elements for me and a touch has no picture. It is
an input device. Hence my assumption that it must clearly mean the LCD
pixels it is glued to. And nothing else.

What I don't understand with your definition is why it is in the DT
at all. The driver is 100% tied to a specific chip. So this is a hard
data sheet constant for all tsc2007 chips which can be compiled into
the driver binary. It does not even need to be defined in a DT =
"firmware".

This was another reason why I though this can not be meant by pixels
in the DT bindings.

And from a theoretical point of view the units are even completely
arbitrary. Loss of precision is only a factor here if you do not have
subpixel reporting to the input layer. But that is an implementation
detail and has nothing to do with the bindings.

Anyways, You can simply set "touchscreen-size =3D 4096" for your tsc2007
system and you get from the driver the maximum precision it can ever =
provide.
This is what it did before and what you expect.

So please notice it is not an either or. It is an as well as what we =
propose.
Defined by the formulae used for scaling.

>=20
> Input driver may set resolution for given axis in units per mm (or =
units
> per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and if you
> check the binding, you can use "touchscreen-x-mm" and =
"touchscreen-y-mm"
> to specify the size of entire touch surface and set resolution from it
> so that userspace can calculate the proper scaling factor.

How is this information exposed by the kernel to user-space? By scanning =
the DT file
or tree?

>=20
>>>=20
>>>>=20
>>>> Now to achieve the ADC pre-calibration we must calculate
>>>>=20
>>>> 	x' =3D (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from =
0.0 ... 1.0
>>>>=20
>>>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>>>=20
>>>> 	x' =3D (touchscreen-size-x * (x - ti,min-x)) / =
(ti,max-x-ti,min-x)
>>>>=20
>>>> How do you want to avoid this scaling to take place? It happens =
automatically.
>>>> It is not even an additional line of code. And is necessary for =
compensating ADC
>>>> offsets and steepness.
>>>>=20
>>>> So the only way to avoid the scaling option is to eliminate the =
precalibration/ADC
>>>> compensation which is essential for a device which has no means to =
properly
>>>> calibrate before operating the device through touch.
>>>>=20
>>>> The other option would be to avoid common bindings and set
>>>>=20
>>>> 	touchscreen-size-x =3D (ti,max-x-ti,min-x)
>>>>=20
>>>> This is heavily dependent on specific ADC offsets forwarded to =
user-space.
>>>> IMHO the worst we can do (and the current tsc2007 driver does it =
that way!).
>>>>=20
>>>>>=20
>>>>> Why do you want this?
>>>>=20
>>>> It seems that you assume that we want to enforce 1:1 scaling =
between touch pixels
>>>> and LCD pixels and have designed code to achieve exactly that.
>>>>=20
>>>> This is not the case. It is just a byproduct that you can do it.
>>>>=20
>>>> And since it is easier to understand we have made the examples this =
way.
>>>>=20
>>>>> If your touch resolution is lower than your screen
>>>>> then it might be useful, but if it is lower then you are losing =
data
>>>>> that can be very helpful for gesture recognition, and I hope you =
design
>>>>> your userspace so it can handle not only "bad" hardware, but =
"good" as
>>>>> well. And even with "bad" there are a lot of tricks that can be =
done to
>>>>> get "better" touch position in userspace.
>>>>=20
>>>> You can just *choose* DT parameters touchscreen-size-x to match the =
LCD size.
>>>> This of course reduces the touch precision to full LCD pixels. For =
finger-
>>>> touch operated devices, subpixel precision is rarely needed.
>>>>=20
>>>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that =
there is
>>>> such an 1:1 mapping and they will be perfectly happy about this.=20
>>>>=20
>>>> But, if you can modify your user-space easily, you can also choose =
a different
>>>> factor.
>>>>=20
>>>> You can for example define touchscreen-size-x=3D<4096> and then you =
get almost
>>>> the highest precision of the ADC and won't loose any bits. Or even =
define a
>>>> bigger range and get steps >1 bit.
>>>>=20
>>>> LCD driver (e.g. X11 calibration matrix) can scale it down again to =
LCD pixels.
>>>>=20
>>>> So effectively we get for LCD pixels when the touch sets a mouse =
pointer:
>>>>=20
>>>> 	x'' =3D user-space-scale * <<input-event<< ((touchscreen-size-x =
* (x - ti,min-x)) / (ti,max-x-ti,min-x))
>>>>=20
>>>> The most simple setup would then be but others are possible:
>>>>=20
>>>> 	user-space-scale =3D 1
>>>> 	touchscreen-size-x =3D LCD-size-x
>>>>=20
>>>> Let me cite myself:
>>>>=20
>>>>>> This makes it possible to pre-calibrate the touch so that is =
(almost)
>>>=20
>>> Yes, it allows you to pre-calibrate, I get it. But you still do =
properly
>>> calibrate later, right?
>>=20
>> No. We want to get rid of this step unless we need to improve the =
precision by
>> some tiny %.
>>=20
>> Why do we want to get rid of it?
>>=20
>> This needs a longer explanation.
>>=20
>> First of all we are working on the Letux distribution which aims at =
supporting
>> multiple devices in the same way and with a single SD card image that =
contains
>> one or multiple rootfs (Debian X11, QtMoko, Replicant etc.) the =
kernel uImage
>> and DTB files for each supported device.
>>=20
>> One of the ideas is to allow users to swap the SD card from one =
device to the
>> other. This means that the touch screen calibration must magically be =
carried
>> along - or we enforce to recalibrate every time the sd card is =
swapped back or
>> forth.
>>=20
>> The same is true for prebuilt SD-images. To have a single (no longer =
device specific)
>> download requires to have a well defined default calibration. =
Especially on
>> devices where you have no keyboard where you can ask the user to =
manually fine-tune
>> something.
>>=20
>> Our challenge is to make it work well without asking for explicit =
calibration.
>> This is where pre-calibration comes into the game.
>>=20
>> It turns out to be related to the touch screen properties and how it =
is glued onto
>> the specific LCD panel, i.e. hardware and its description.
>>=20
>> So the natural location of defining this relation is the DTB for each =
device
>> and not the user-space. And it happens that we already have one per =
device
>> (touch screen, lcd, tsc variant) on the SD card.
>>=20
>>> So you are doing double work here, once in
>>> kernel, and second time in userspace.
>>=20
>> This is no longer required, as long as we can use the default 1:1 =
coordinate mapping
>> of e.g. framebuffer or X11 based GUI toolkits.
>>=20
>> If we don't have the 1:1 mapping of touch screen input event =
coordinates
>> to LCD pixels we have a mess of different scaling factors back in =
user-space
>> again. And the problem is setting them up properly in an installable =
.tbz
>> or .dd image.
>=20
> Why? Nothing stops you from querying the device and figure out =
scaling.

What stops me is that I have no (and do not want to have) that level of =
control over
user-space code.

I can't change Debian, AchLinux, Ubuntu, Replicant, and 100 other =
systems in parallel
to make the touch work as we want to have it, i.e. precalibrated.

BTW, there is a tendency to point to the kernel to do it right...

> We do that, for example, on Chrome OS, where we do not have 1:1 =
matching
> between LCDs and touch controllers, and still we do not have static
> transformation matrices on the file system either.

Yes, of course it can be solved that way. We could even go further and =
develop
a touch screen interface by using /dev/i2c. This avoids having a tsc2007 =
driver
at all. And all other touch screen drivers can be removed as well. It is =
all
possible, but IMHO not reasonable for good reasons.

>=20
>>=20
>> Recently, you have raised another topic I had indeed not thought =
abut, which is
>> the potential subpixel precision of a resistive touch. You get =
approx. 12
>> bit from the ADC but the x coordinate of the 480 pixel wide screen is =
just 9
>> bit. So scaling the input event coordinates to pixels throws away 3 =
bits.
>>=20
>> But there are two things to consider.
>>=20
>> One is that we could set the pre-calibration to keep as much =
resolution as
>> possible, ca. 12 pixels and make the user-space scale down to screen =
coordinates.
>>=20
>> Unfortunately that differs between devices and hence we need not only
>> different DTBs (which we already have) but different scale factors in =
user-space.
>>=20
>> Next, one could argue that subpixel coordinates should not be handled =
by
>> scaling input event coordinates up and then down again in user-space. =
The
>> correct solution would be that input events could report fixed or =
floating
>> point coordinates, but this is probably beyond what we all want to =
do.
>>=20
>> The other thing is noise. No resistive touch screen I have seen in =
the wild with
>> the tsc2007 or tsc2046 controller has the precision to really report =
subpixels.
>> Rather we have to set the fuzz between 3 or 10 or so. Which means =
that those
>> bits we cut off by scaling to screen coordinates are already lost in =
noise.
>=20
> I really do not care what exactly tsc2007 or any other particular
> touchscreen controller does. Please design your software so that it =
can
> use wide range of devices, from noisy to noiseless. If there is noise,
> filter it out.

1. noise is an unavoidable physical phenomenon for resistive touch + ADC
2. filtering noise is what the input layer is doing by the fuzz factor. =
So it is one layer
above the tsc2007 driver.

> It there is a nice touch controller with a lot of
> precision - use it,

I still do not see how this patch influences non-tsc2007 touch =
controllers.

I explained how the tsc2007 can be used with full precision. Either by =
providing
a different value for touchscreen-size and recompiling the DTB or by =
using subpixel
coordinates in input events.

> do not dumb it down to the lowest common
> denominator.
>=20
>>=20
>>>=20
>>> I'd be more open to allowing setting the "min-axis" values to allow
>>> reporting typical range for given device, and let userspace scale as =
it
>>> sees fit.
>>=20
>> The problem is: what is "typical range"? It turns out to be a =
completely
>> arbitrary definition.
>>=20
>> I see a choice between:
>> a) full theoretical ADC range
>> b) millimeters
>> c) pixels of the LCD the touch is glued to
>=20
> d) Native reporting units for the touch controller. You will have the
> touch controller output range, you will have your LCD screen size, and
> you scale one into another.

That is exactly what I mean with a) ("full theoretical ADC range" =3D =
"touch controller output range"),
so it is not a new alternative.

IMHO c) is the right and natural default.

>=20
>>=20
>> For me, the most natural and practical "typical range" still seems to =
be the
>> pixels of the lcd panel the touch is glued onto.
>>=20
>> The reason why I see it as superior to the others is that only this =
leads to
>> a stable 1:1 mapping in user-space avoiding to adjust any factors =
there.
>>=20
>> And this 1:1 saves a lot of configuration hassle if you swap GUI =
systems
>> (X, Wayland, Android, DirectFB, fb based Qt, ...).
>=20
> Yes, they will need to do that, if they want to use "nice" hardware =
and
> not lose precision.

This is where I think a proper solution for not loosing precision would =
be to
introduce subpixel reporting to the input layer.

But in our practical experience with real devices, people complained =
that the
touch is misaligned. But nobody complained about loss of precision so =
far. It
came up here as a theoretical discussion in a quite late phase for the =
first
time.

> And since they need to do that anyway, there is no
> point in doing it in kernel, not with per driver code, and not even in
> input core.
>=20
> You are getting this feedback from several people,

So far I only know Pavel and you. Which are two.

I also have the feedback of many users of the GTA04 that the =
pre-calibration and
scaling is really good (when using these patches).

So I wonder what is more important: users or something else?

> please consider topic
> of adding scaling to the drivers closed.

You are of course free to decide this way since you are the maintainer. =
I just
want to note for the records that you ignore user's wishes. I hope this =
is not
a general phenomenon.

> The only transformations that I
> think make sense is to "normalize" output with axis swaps and
> inversions, so that kernel uses the same notion of coordinates for all
> devices, regardless of how the device was mounted.

Who will do that?

Do you expect that I submit a version which lacks one feature I think it
is important? And one which is difficult to not implement by accident if =
you
want to use the common touchscreen bindings?

>=20
>=20
>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Please note that the old ti,fuzz properties have been removed =
since they
>>>>>> are replaced by the common bindings touchscreen-fuzz-x/y/z.
>>>>>>=20
>>>>>> Finally, calculate_pressure has been renamed to =
calculate_resistance
>>>>>> because that is what it is doing.
>>>>>=20
>>>>> That is not what your patch does though. In the presence of
>>>>> "ti,report-resistance" parameter you start reporting resistance =
through
>>>>> ABS_PRESSURE
>>>>=20
>>>> Well, there is some historic confusion wether this driver reports =
resistance
>>>> or pressure.
>>>>=20
>>>> The unpatched tsc2007 driver does it wrong (please test!) and we =
fix it on
>>>> the fly (because a separate patch is much more complex than doing =
it right
>>>> immediately).
>>>>=20
>>>> This ti,report-resistance property is a means to get the old =
(wrong) meaning back
>>>> in case someone urgently needs it and can't fix the user-space =
workaround which
>>>> he must be using.
>>>>=20
>>>>=20
>>>> AFAIK there is no mainline board using the DT except ours (and the =
upcoming
>>>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can =
remove this
>>>> compatibility property. We don't need it for our devices.
>>>>=20
>>>=20
>>> You seem to be treating DT data as something very fluid, which is =
wrong.
>>=20
>> No,only sometimes.
>>=20
>> Of course it should be done right once. Of course there is long =
discussion about
>> what is right...
>>=20
>>> You need to treat it as a firmware, unlikely to change once device =
is
>>> shipped. Unlike legacy platform data, the fact that DTS files are =
not
>>> present in mainline does not mean that we can ignore such users and
>>> change behavior at will.
>>=20
>> Well, it happens to me as maintainer of a 99.5% mainline device every
>> now and then. Of course this should not be an argument to do it =
equally bad here.
>>=20
>> One more thought: for some devices it is easier to modify the DTB =
"firmware"
>> than the user space (e.g. if you have no access to it because it is =
maintained
>> by somebody else).
>=20
> And still, according to DT folks, device tree forms an ABI and thus we
> are not to change it, even if it is easy.

I think this needs a more differentiated view.

In my view the names of the binding properties and what they influence =
form indeed
an ABI. It should be stable and interpreted in the same way.

But it allows to load different firmware for different requirements. =
Like the user
application ABI is stable but you can still load different software.

So changing the value of a property in a specific .dtb file is a =
modified firmware
but does not change the ABI. Adding/removing properties is an ABI =
change.

Here, we are discussing of using different values for touchscreen-size =
if someone
needs higher precision and wants to do user-space scaling.

This patch neither stops anyone from doing it nor does it require anyone =
to use
it. Hence we give you the most flexible solution I can think of but =
there are complaints
because it seems to be too flexible.

So loading a "low resolution but precalibrated" firmware or loading a =
"high precision
firmware which needs user-space calibration step" does not change ABI.

>>=20
>>>=20
>>> That said, if driver behavior is out of line from the subsystem
>>> expectations, we need to fix it.
>>>=20
>>>=20
>>>> That the function name is wrong is a second issue and this double =
negation might
>>>> confuse a litte.
>>>>=20
>>>> Please test on a real device if the patched driver reports pressure =
now (unless
>>>> ti,report-resistance is specified).
>>>=20
>>> I unfortunately can not test this driver as I do not have the =
hardware.
>>=20
>> Ah, ok. This is indeed a road block.
>>=20
>> Maybe someone else with a real tsc2007 hardware is reading this =
discussion and can comment?
>>=20
>>> So all my observations are from code and data sheets.
>>=20
>>> That said, what is the values emitted as ABS_PRESSURE when finger is =
not
>>> touching the device, barely touching the device, or pressing firmly?
>>=20
>>> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we =
have
>>> confusion as to what is being reported.
>>=20
>> Indeed. The original tsc2007 jumps from 0 to a maximum value and goes =
down when
>> pressing more firmly. This is not "pressure". The other drivers (I =
have tested
>> the OpenPandora with tsc2046) are doing it in a monotonic curve.
>=20
> OK, then this is clearly wrong and we need to fix it (without any =
funky
> flags).

I am almost done with a patch series for this as promised to Sebastian.
Comes in some minutes.

BR and thanks,
Nikolaus

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 23:39 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>>> And note that I am not making things different from others in tree,
>>>> I am making the tsc2007 right (incl. following the touchscreen
>>>> bindings which define the touchscreen size in "Pixels").
>>> 
>>> Your touch screen is not in any way special, so it has to behave in
>>> the same way others do.
>>> 
>> 
>> I agree, the tsc2007 (=what the interface provides to userspace) should
>> not behave special, for example it should behave like the virtual
>> touchscreen (=what the interface provides to userspace) virtualbox
>> gives. No need to be calibrated. Well, the internals are different. But
>> that is what the kernel is good for, abstract such things.
>> Conclusion: It cannot be totally wrong behavior to have pixel values
>> there.
> 
> It is not "totally wrong". But it is useless code that should not be
> in kernel. Calibration certainly does not belong to single
> _driver_.

It belongs to driver + attached panel. I.e. hardware. Which the kernel
or driver should IMHO abstract from as good as possible.

> Feel free to submit driver

For what? The tsc2007 driver already exists.

> but keep the calibration code out
> of tree...

It is the really important patch to add this.

> 
> But if you have userspace that depends on touchscreen to be
> calibrated... that _is_ wrong.

User-space people and real users have the opposite opinion. They
prefer if a touch is plug&play. I.e. without need for calibration.

When did you last time re-calibrate the heads of your hard disk in
user-space?

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pavel,

> Am 19.02.2017 um 23:39 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> Hi!
> 
>>>> And note that I am not making things different from others in tree,
>>>> I am making the tsc2007 right (incl. following the touchscreen
>>>> bindings which define the touchscreen size in "Pixels").
>>> 
>>> Your touch screen is not in any way special, so it has to behave in
>>> the same way others do.
>>> 
>> 
>> I agree, the tsc2007 (=what the interface provides to userspace) should
>> not behave special, for example it should behave like the virtual
>> touchscreen (=what the interface provides to userspace) virtualbox
>> gives. No need to be calibrated. Well, the internals are different. But
>> that is what the kernel is good for, abstract such things.
>> Conclusion: It cannot be totally wrong behavior to have pixel values
>> there.
> 
> It is not "totally wrong". But it is useless code that should not be
> in kernel. Calibration certainly does not belong to single
> _driver_.

It belongs to driver + attached panel. I.e. hardware. Which the kernel
or driver should IMHO abstract from as good as possible.

> Feel free to submit driver

For what? The tsc2007 driver already exists.

> but keep the calibration code out
> of tree...

It is the really important patch to add this.

> 
> But if you have userspace that depends on touchscreen to be
> calibrated... that _is_ wrong.

User-space people and real users have the opposite opinion. They
prefer if a touch is plug&play. I.e. without need for calibration.

When did you last time re-calibrate the heads of your hard disk in
user-space?

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> As long as it is small (I expect <1.01 = 1% error in scale) it is
> barely noticeable.
> 
> Therefore, I asked before: how big in pixels is your finger or stylus?
> Does this effect matter?

If I draw a line in gimp, I don't expect it to have steps because of
"barely noticeable" errors.

> A resistive touch is a man-machine-interface where people press buttons of at
> least 12x12 pixels size (or they are no longer visually recognizable).

Resistive touch is used for drawing, too.
 
> So the discussion boils down to "what gives the better usability?":
> a) getting rid of the nasty user-space calibration step (and plethora of different tools)
> b) getting highest theoretical precision which has a low practical relevance
> 
> I am in favor of a). Like most users we ask. A minority is in favor of b).
> Since we don't exclude b) users from reconfiguring their system to get it done
> as they like. I think this is the best we can achieve.

Do you even read what I wrote?

Because I presented way to have both a) _and_ b).

> >>> No. You have to design interface such that they _can_ be improved, and
> >>> what you propose does not work that way.
> >> 
> >> It works. Please do real world tests...
> > 
> > You do a real world test on N900, and propose upgrade path.
> 
> I have no N900 running. But since it uses a tsc2004/5 controller which seems
> to be quite similar, you can likely copy&paste some code or add the algorithm:
> 
> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)
> 
> Thats it.
> 
> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
> user-space gets what it would have got before adding such a formula and then you
> can and must do calibration there.
> 
> Taking this as the defaults if none of the new properties is specified, makes
> the scaling feature completely disappear. And I don't care about 2 additional
> subtractions, one multiplication and one division per axis.
> 
> So the upgrade path is:
> 1. introduce new optional properties, parse and store them in the struct
> 2. set defaults for the optional properties as described above
> 3. add the formula to the code (1 line for each axis)
> 4. deploy - nobody will notice

Good so far.

> 5. update the DT and remove user-space calibration - people will be happy
>    that they do not have to calibrate first any more

You can't do this. And this is fatal problem with your proposal.

If I update the DT in the kernel, my users will be very unhappy,
because their screens will now be miscalibrated. New kernel must not
force users to update their userland at the same time.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> As long as it is small (I expect <1.01 = 1% error in scale) it is
> barely noticeable.
> 
> Therefore, I asked before: how big in pixels is your finger or stylus?
> Does this effect matter?

If I draw a line in gimp, I don't expect it to have steps because of
"barely noticeable" errors.

> A resistive touch is a man-machine-interface where people press buttons of at
> least 12x12 pixels size (or they are no longer visually recognizable).

Resistive touch is used for drawing, too.
 
> So the discussion boils down to "what gives the better usability?":
> a) getting rid of the nasty user-space calibration step (and plethora of different tools)
> b) getting highest theoretical precision which has a low practical relevance
> 
> I am in favor of a). Like most users we ask. A minority is in favor of b).
> Since we don't exclude b) users from reconfiguring their system to get it done
> as they like. I think this is the best we can achieve.

Do you even read what I wrote?

Because I presented way to have both a) _and_ b).

> >>> No. You have to design interface such that they _can_ be improved, and
> >>> what you propose does not work that way.
> >> 
> >> It works. Please do real world tests...
> > 
> > You do a real world test on N900, and propose upgrade path.
> 
> I have no N900 running. But since it uses a tsc2004/5 controller which seems
> to be quite similar, you can likely copy&paste some code or add the algorithm:
> 
> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)
> 
> Thats it.
> 
> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
> user-space gets what it would have got before adding such a formula and then you
> can and must do calibration there.
> 
> Taking this as the defaults if none of the new properties is specified, makes
> the scaling feature completely disappear. And I don't care about 2 additional
> subtractions, one multiplication and one division per axis.
> 
> So the upgrade path is:
> 1. introduce new optional properties, parse and store them in the struct
> 2. set defaults for the optional properties as described above
> 3. add the formula to the code (1 line for each axis)
> 4. deploy - nobody will notice

Good so far.

> 5. update the DT and remove user-space calibration - people will be happy
>    that they do not have to calibrate first any more

You can't do this. And this is fatal problem with your proposal.

If I update the DT in the kernel, my users will be very unhappy,
because their screens will now be miscalibrated. New kernel must not
force users to update their userland at the same time.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > But if you have userspace that depends on touchscreen to be
> > calibrated... that _is_ wrong.
> 
> User-space people and real users have the opposite opinion. They
> prefer if a touch is plug&play. I.e. without need for calibration.

Some people prefer to calibrate their touchscreens; because of
per-device variations, that gives better precision.

You can pass default calibration data from device tree to kernel to
userland. But you can not force people to use that calibration.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > But if you have userspace that depends on touchscreen to be
> > calibrated... that _is_ wrong.
> 
> User-space people and real users have the opposite opinion. They
> prefer if a touch is plug&play. I.e. without need for calibration.

Some people prefer to calibrate their touchscreens; because of
per-device variations, that gives better precision.

You can pass default calibration data from device tree to kernel to
userland. But you can not force people to use that calibration.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1460 bytes --]

Hi Nikolaus!

On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Input driver may set resolution for given axis in units per mm (or
> > units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
> > if you check the binding, you can use "touchscreen-x-mm" and
> > "touchscreen-y-mm" to specify the size of entire touch surface and
> > set resolution from it so that userspace can calculate the proper
> > scaling factor.
> 
> How is this information exposed by the kernel to user-space? By
> scanning the DT file or tree?

Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS 
ioctl() on input device. Look at struct input_absinfo, you should have 
all needed information here. This is generic input interface, no DT is 
needed.

I hope that XServer is already using it for evdev devices...

For whole implementation look at evtest program. That should be good 
starting point for your userspace implementation.

While I'm watching this discussion... in my opinion kernel should just 
invert input axes (when needed) and should not do any other 
normalization or integer/floating-point re-calibration/re-calculation. 
If it correctly exports minimum value, maximum value and resolution then 
userspace can correctly re-scale input events to units which userspace 
needs (e.g. mapping into LCD screen pixels or whatever is needed).

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1460 bytes --]

Hi Nikolaus!

On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
> > Input driver may set resolution for given axis in units per mm (or
> > units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
> > if you check the binding, you can use "touchscreen-x-mm" and
> > "touchscreen-y-mm" to specify the size of entire touch surface and
> > set resolution from it so that userspace can calculate the proper
> > scaling factor.
> 
> How is this information exposed by the kernel to user-space? By
> scanning the DT file or tree?

Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS 
ioctl() on input device. Look at struct input_absinfo, you should have 
all needed information here. This is generic input interface, no DT is 
needed.

I hope that XServer is already using it for evdev devices...

For whole implementation look at evtest program. That should be good 
starting point for your userspace implementation.

While I'm watching this discussion... in my opinion kernel should just 
invert input axes (when needed) and should not do any other 
normalization or integer/floating-point re-calibration/re-calculation. 
If it correctly exports minimum value, maximum value and resolution then 
userspace can correctly re-scale input events to units which userspace 
needs (e.g. mapping into LCD screen pixels or whatever is needed).

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

HI Pavel,

> Am 20.02.2017 um 20:29 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>> As long as it is small (I expect <1.01 = 1% error in scale) it is
>> barely noticeable.
>> 
>> Therefore, I asked before: how big in pixels is your finger or stylus?
>> Does this effect matter?
> 
> If I draw a line in gimp, I don't expect it to have steps because of
> "barely noticeable" errors.

You can't draw a line with exactly 1 pixel distance on such a touch screen.

> 
>> A resistive touch is a man-machine-interface where people press buttons of at
>> least 12x12 pixels size (or they are no longer visually recognizable).
> 
> Resistive touch is used for drawing, too.

Yes, for taking handwritten notes but not for high-precision graphics design.
For that you take a bigger screen and zoom the relevant areas.

> 
>> So the discussion boils down to "what gives the better usability?":
>> a) getting rid of the nasty user-space calibration step (and plethora of different tools)
>> b) getting highest theoretical precision which has a low practical relevance
>> 
>> I am in favor of a). Like most users we ask. A minority is in favor of b).
>> Since we don't exclude b) users from reconfiguring their system to get it done
>> as they like. I think this is the best we can achieve.
> 
> Do you even read what I wrote?
> 
> Because I presented way to have both a) _and_ b).

I am not aware that you did this. You made a proposal for the X system but not
for others, e.g. Replicant.

> 
>>>>> No. You have to design interface such that they _can_ be improved, and
>>>>> what you propose does not work that way.
>>>> 
>>>> It works. Please do real world tests...
>>> 
>>> You do a real world test on N900, and propose upgrade path.
>> 
>> I have no N900 running. But since it uses a tsc2004/5 controller which seems
>> to be quite similar, you can likely copy&paste some code or add the algorithm:
>> 
>> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)
>> 
>> Thats it.
>> 
>> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
>> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
>> user-space gets what it would have got before adding such a formula and then you
>> can and must do calibration there.
>> 
>> Taking this as the defaults if none of the new properties is specified, makes
>> the scaling feature completely disappear. And I don't care about 2 additional
>> subtractions, one multiplication and one division per axis.
>> 
>> So the upgrade path is:
>> 1. introduce new optional properties, parse and store them in the struct
>> 2. set defaults for the optional properties as described above
>> 3. add the formula to the code (1 line for each axis)
>> 4. deploy - nobody will notice
> 
> Good so far.

Ok!

> 
>> 5. update the DT and remove user-space calibration - people will be happy
>>   that they do not have to calibrate first any more
> 
> You can't do this. And this is fatal problem with your proposal.

> 
> If I update the DT in the kernel, my users will be very unhappy,
> because their screens will now be miscalibrated.

If you tell them that they should recalibrate once, after they upgrade
to Linux 4.12 because they no longer need it I doubt they will not be very
unhappy.

And as said I do not expect or force you to take step 5 for the N900 touch
screen. Not even step 1.

I would take this more sensitive if you would use the same chip.

> New kernel must not
> force users to update their userland at the same time.

Yes, it shouldn't. But to be honest, this is not my experience. I have to
tweak userland a little almost every time a new kernel merge window is done.
Admittedly not in the input system. And I may be using the wrong distribution.

But if you ever want to deploy better features it is really difficult to avoid.

Nevertheless, what problem do you have to implement steps 1-4 in kernel
and step 5 outside?

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

HI Pavel,

> Am 20.02.2017 um 20:29 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> Hi!
> 
>> As long as it is small (I expect <1.01 = 1% error in scale) it is
>> barely noticeable.
>> 
>> Therefore, I asked before: how big in pixels is your finger or stylus?
>> Does this effect matter?
> 
> If I draw a line in gimp, I don't expect it to have steps because of
> "barely noticeable" errors.

You can't draw a line with exactly 1 pixel distance on such a touch screen.

> 
>> A resistive touch is a man-machine-interface where people press buttons of at
>> least 12x12 pixels size (or they are no longer visually recognizable).
> 
> Resistive touch is used for drawing, too.

Yes, for taking handwritten notes but not for high-precision graphics design.
For that you take a bigger screen and zoom the relevant areas.

> 
>> So the discussion boils down to "what gives the better usability?":
>> a) getting rid of the nasty user-space calibration step (and plethora of different tools)
>> b) getting highest theoretical precision which has a low practical relevance
>> 
>> I am in favor of a). Like most users we ask. A minority is in favor of b).
>> Since we don't exclude b) users from reconfiguring their system to get it done
>> as they like. I think this is the best we can achieve.
> 
> Do you even read what I wrote?
> 
> Because I presented way to have both a) _and_ b).

I am not aware that you did this. You made a proposal for the X system but not
for others, e.g. Replicant.

> 
>>>>> No. You have to design interface such that they _can_ be improved, and
>>>>> what you propose does not work that way.
>>>> 
>>>> It works. Please do real world tests...
>>> 
>>> You do a real world test on N900, and propose upgrade path.
>> 
>> I have no N900 running. But since it uses a tsc2004/5 controller which seems
>> to be quite similar, you can likely copy&paste some code or add the algorithm:
>> 
>> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)
>> 
>> Thats it.
>> 
>> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
>> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
>> user-space gets what it would have got before adding such a formula and then you
>> can and must do calibration there.
>> 
>> Taking this as the defaults if none of the new properties is specified, makes
>> the scaling feature completely disappear. And I don't care about 2 additional
>> subtractions, one multiplication and one division per axis.
>> 
>> So the upgrade path is:
>> 1. introduce new optional properties, parse and store them in the struct
>> 2. set defaults for the optional properties as described above
>> 3. add the formula to the code (1 line for each axis)
>> 4. deploy - nobody will notice
> 
> Good so far.

Ok!

> 
>> 5. update the DT and remove user-space calibration - people will be happy
>>   that they do not have to calibrate first any more
> 
> You can't do this. And this is fatal problem with your proposal.

> 
> If I update the DT in the kernel, my users will be very unhappy,
> because their screens will now be miscalibrated.

If you tell them that they should recalibrate once, after they upgrade
to Linux 4.12 because they no longer need it I doubt they will not be very
unhappy.

And as said I do not expect or force you to take step 5 for the N900 touch
screen. Not even step 1.

I would take this more sensitive if you would use the same chip.

> New kernel must not
> force users to update their userland at the same time.

Yes, it shouldn't. But to be honest, this is not my experience. I have to
tweak userland a little almost every time a new kernel merge window is done.
Admittedly not in the input system. And I may be using the wrong distribution.

But if you ever want to deploy better features it is really difficult to avoid.

Nevertheless, what problem do you have to implement steps 1-4 in kernel
and step 5 outside?

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi,

> Am 20.02.2017 um 20:32 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> But if you have userspace that depends on touchscreen to be
>>> calibrated... that _is_ wrong.
>> 
>> User-space people and real users have the opposite opinion. They
>> prefer if a touch is plug&play. I.e. without need for calibration.
> 
> Some people prefer to calibrate their touchscreens; because of
> per-device variations, that gives better precision.
> 
> You can pass default calibration data from device tree to kernel to
> userland. But you can not force people to use that calibration.

Yes, you can do that if you want. I hope it became clear by the formula
in my last mail.

I just want to be able to do it the other way for those users who don't
care about this per-device variation.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi,

> Am 20.02.2017 um 20:32 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> But if you have userspace that depends on touchscreen to be
>>> calibrated... that _is_ wrong.
>> 
>> User-space people and real users have the opposite opinion. They
>> prefer if a touch is plug&play. I.e. without need for calibration.
> 
> Some people prefer to calibrate their touchscreens; because of
> per-device variations, that gives better precision.
> 
> You can pass default calibration data from device tree to kernel to
> userland. But you can not force people to use that calibration.

Yes, you can do that if you want. I hope it became clear by the formula
in my last mail.

I just want to be able to do it the other way for those users who don't
care about this per-device variation.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm (or
>>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
>>> if you check the binding, you can use "touchscreen-x-mm" and
>>> "touchscreen-y-mm" to specify the size of entire touch surface and
>>> set resolution from it so that userspace can calculate the proper
>>> scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should have
> all needed information here. This is generic input interface, no DT is
> needed.

This assumes that I can and want to write a graphics system myself.

> 
> I hope that XServer is already using it for evdev devices...

No idea if it does. It is a black box for me out of our control.

> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.

The problem I have is that *I* have no userspace implementation and
the GTA04 project does not want to enforce one. We have several different
ones: X11 based (LXDE and others), Qt (fb based), Replicant to name some.

All have the same problem to be solved once. The common denominator for
a solution are 2 lines of code in the kernel plus some DT properties
you need anyways if calibration should be automated in userland.

> 
> While I'm watching this discussion... in my opinion kernel should just
> invert input axes (when needed) and should not do any other
> normalization or integer/floating-point re-calibration/re-calculation.
> If it correctly exports minimum value, maximum value and resolution then
> userspace can correctly re-scale input events to units which userspace
> needs (e.g. mapping into LCD screen pixels or whatever is needed).

It can, but afaik it does not yet. And if it does, it does it in a plethora
of different implementation states. That is the reason why we want to solve
it once for all userlands in the kernel and not rely on user-space help.

Surely, userland can do a lot of things. It could also do the whole
file system stuff (FUSE).

A more input device related example comes to my mind: userland could do
keyboard mapping completely. It would suffice if the kernel presents
some x/y coordinates or gpio-numbers for buttons and user-space could map.
Still there is a (pre-)mapping to Key-Codes. And yes, they are mapped a second
time in userland if needed, but it works sufficiently well if not done.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm (or
>>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
>>> if you check the binding, you can use "touchscreen-x-mm" and
>>> "touchscreen-y-mm" to specify the size of entire touch surface and
>>> set resolution from it so that userspace can calculate the proper
>>> scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should have
> all needed information here. This is generic input interface, no DT is
> needed.

This assumes that I can and want to write a graphics system myself.

> 
> I hope that XServer is already using it for evdev devices...

No idea if it does. It is a black box for me out of our control.

> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.

The problem I have is that *I* have no userspace implementation and
the GTA04 project does not want to enforce one. We have several different
ones: X11 based (LXDE and others), Qt (fb based), Replicant to name some.

All have the same problem to be solved once. The common denominator for
a solution are 2 lines of code in the kernel plus some DT properties
you need anyways if calibration should be automated in userland.

> 
> While I'm watching this discussion... in my opinion kernel should just
> invert input axes (when needed) and should not do any other
> normalization or integer/floating-point re-calibration/re-calculation.
> If it correctly exports minimum value, maximum value and resolution then
> userspace can correctly re-scale input events to units which userspace
> needs (e.g. mapping into LCD screen pixels or whatever is needed).

It can, but afaik it does not yet. And if it does, it does it in a plethora
of different implementation states. That is the reason why we want to solve
it once for all userlands in the kernel and not rely on user-space help.

Surely, userland can do a lot of things. It could also do the whole
file system stuff (FUSE).

A more input device related example comes to my mind: userland could do
keyboard mapping completely. It would suffice if the kernel presents
some x/y coordinates or gpio-numbers for buttons and user-space could map.
Still there is a (pre-)mapping to Key-Codes. And yes, they are mapped a second
time in userland if needed, but it works sufficiently well if not done.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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


> Am 20.02.2017 um 21:22 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi,
> 
>> Am 20.02.2017 um 20:32 schrieb Pavel Machek <pavel@ucw.cz>:
>> 
>> Hi!
>> 
>>>> But if you have userspace that depends on touchscreen to be
>>>> calibrated... that _is_ wrong.
>>> 
>>> User-space people and real users have the opposite opinion. They
>>> prefer if a touch is plug&play. I.e. without need for calibration.
>> 
>> Some people prefer to calibrate their touchscreens; because of
>> per-device variations, that gives better precision.
>> 
>> You can pass default calibration data from device tree to kernel to
>> userland. But you can not force people to use that calibration.
> 
> Yes, you can do that if you want. I hope it became clear by the formula
> in my last mail.

Sorry this can be completely misleading, if read in conjunction with your
sentences. Brevity in answers may disturb the message.

It does not mean that you can and should force people to use that calibration...

It means that users still can do per-device calibration and do not have
to use the pre-calibration capability of the driver. Hence we called it
pre-calibration.

> 
> I just want to be able to do it the other way for those users who don't
> care about this per-device variation.
> 
> BR,
> Nikolaus
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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


> Am 20.02.2017 um 21:22 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> 
> Hi,
> 
>> Am 20.02.2017 um 20:32 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
>> 
>> Hi!
>> 
>>>> But if you have userspace that depends on touchscreen to be
>>>> calibrated... that _is_ wrong.
>>> 
>>> User-space people and real users have the opposite opinion. They
>>> prefer if a touch is plug&play. I.e. without need for calibration.
>> 
>> Some people prefer to calibrate their touchscreens; because of
>> per-device variations, that gives better precision.
>> 
>> You can pass default calibration data from device tree to kernel to
>> userland. But you can not force people to use that calibration.
> 
> Yes, you can do that if you want. I hope it became clear by the formula
> in my last mail.

Sorry this can be completely misleading, if read in conjunction with your
sentences. Brevity in answers may disturb the message.

It does not mean that you can and should force people to use that calibration...

It means that users still can do per-device calibration and do not have
to use the pre-calibration capability of the driver. Hence we called it
pre-calibration.

> 
> I just want to be able to do it the other way for those users who don't
> care about this per-device variation.
> 
> BR,
> Nikolaus
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel-S0jZdbWzriLCfDggNXIi3w@public.gmane.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 4653 bytes --]

On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > Hi Nikolaus!
> > 
> > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >> 
> >>> Input driver may set resolution for given axis in units per mm
> >>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>> ABS_RZ), and if you check the binding, you can use
> >>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
> >>> entire touch surface and set resolution from it so that
> >>> userspace can calculate the proper scaling factor.
> >> 
> >> How is this information exposed by the kernel to user-space? By
> >> scanning the DT file or tree?
> > 
> > Set input_abs_set_res() from kernel. And in userspace call
> > EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> > you should have all needed information here. This is generic input
> > interface, no DT is needed.
> 
> This assumes that I can and want to write a graphics system myself.

Not only. There are already existing graphics systems. And you need to 
provide needed information from kernel, so they can start using it.

So input_abs_set_res() is needed to use in your kernel driver.

> > I hope that XServer is already using it for evdev devices...
> 
> No idea if it does. It is a black box for me out of our control.

https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1479

So yes, it does.

> > For whole implementation look at evtest program. That should be
> > good starting point for your userspace implementation.
> 
> The problem I have is that *I* have no userspace implementation and
> the GTA04 project does not want to enforce one. We have several
> different ones: X11 based (LXDE and others), Qt (fb based),
> Replicant to name some.
> 
> All have the same problem to be solved once. The common denominator
> for a solution are 2 lines of code in the kernel plus some DT
> properties you need anyways if calibration should be automated in
> userland.

As I wrote above part of linux input API is resolution value. And from 
all information I understood that having current value, minimal value, 
maximal value and resolution is enough for correct calculation of pixel 
coordinates in userspace.

And Xserver evdev driver is using it.

If other non-X11 application (which you want/need to use) use resolution 
information incorrectly (or calculate positions incorrectly), then this 
is bug that application. Not in Linux kernel, that is important.

And I would rather see fixes of such bugs in that (broken) application 
as doing workarounds in kernel, just because of bugs in application.

More important, are those applications really broken?

From my point of view: Reporting size of input device is already part of 
stable kernel <--> userspace API/ABI and it should be used instead of 
inventing new way...

> > While I'm watching this discussion... in my opinion kernel should
> > just invert input axes (when needed) and should not do any other
> > normalization or integer/floating-point
> > re-calibration/re-calculation. If it correctly exports minimum
> > value, maximum value and resolution then userspace can correctly
> > re-scale input events to units which userspace needs (e.g. mapping
> > into LCD screen pixels or whatever is needed).
> 
> It can, but afaik it does not yet.

I did not tested it, but code is in xf86-input-evdev already there.

So please try to implement input_abs_set_res() in kernel driver and test 
userspace.

> And if it does, it does it in a
> plethora of different implementation states. That is the reason why
> we want to solve it once for all userlands in the kernel and not
> rely on user-space help.

For me this looks like "we are going to fix userspace bugs in kernel". 
Really! Not a good idea. Plus I still see this as abusing kernel API/ABI 
as resolution should be handled differently as you are proposing.

> Surely, userland can do a lot of things. It could also do the whole
> file system stuff (FUSE).
> 
> A more input device related example comes to my mind: userland could
> do keyboard mapping completely. It would suffice if the kernel
> presents some x/y coordinates or gpio-numbers for buttons and
> user-space could map. Still there is a (pre-)mapping to Key-Codes.
> And yes, they are mapped a second time in userland if needed, but it
> works sufficiently well if not done.
> 
> BR and thanks,
> Nikolaus

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 4713 bytes --]

On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > Hi Nikolaus!
> > 
> > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >> 
> >>> Input driver may set resolution for given axis in units per mm
> >>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>> ABS_RZ), and if you check the binding, you can use
> >>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
> >>> entire touch surface and set resolution from it so that
> >>> userspace can calculate the proper scaling factor.
> >> 
> >> How is this information exposed by the kernel to user-space? By
> >> scanning the DT file or tree?
> > 
> > Set input_abs_set_res() from kernel. And in userspace call
> > EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> > you should have all needed information here. This is generic input
> > interface, no DT is needed.
> 
> This assumes that I can and want to write a graphics system myself.

Not only. There are already existing graphics systems. And you need to 
provide needed information from kernel, so they can start using it.

So input_abs_set_res() is needed to use in your kernel driver.

> > I hope that XServer is already using it for evdev devices...
> 
> No idea if it does. It is a black box for me out of our control.

https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1479

So yes, it does.

> > For whole implementation look at evtest program. That should be
> > good starting point for your userspace implementation.
> 
> The problem I have is that *I* have no userspace implementation and
> the GTA04 project does not want to enforce one. We have several
> different ones: X11 based (LXDE and others), Qt (fb based),
> Replicant to name some.
> 
> All have the same problem to be solved once. The common denominator
> for a solution are 2 lines of code in the kernel plus some DT
> properties you need anyways if calibration should be automated in
> userland.

As I wrote above part of linux input API is resolution value. And from 
all information I understood that having current value, minimal value, 
maximal value and resolution is enough for correct calculation of pixel 
coordinates in userspace.

And Xserver evdev driver is using it.

If other non-X11 application (which you want/need to use) use resolution 
information incorrectly (or calculate positions incorrectly), then this 
is bug that application. Not in Linux kernel, that is important.

And I would rather see fixes of such bugs in that (broken) application 
as doing workarounds in kernel, just because of bugs in application.

More important, are those applications really broken?

From my point of view: Reporting size of input device is already part of 
stable kernel <--> userspace API/ABI and it should be used instead of 
inventing new way...

> > While I'm watching this discussion... in my opinion kernel should
> > just invert input axes (when needed) and should not do any other
> > normalization or integer/floating-point
> > re-calibration/re-calculation. If it correctly exports minimum
> > value, maximum value and resolution then userspace can correctly
> > re-scale input events to units which userspace needs (e.g. mapping
> > into LCD screen pixels or whatever is needed).
> 
> It can, but afaik it does not yet.

I did not tested it, but code is in xf86-input-evdev already there.

So please try to implement input_abs_set_res() in kernel driver and test 
userspace.

> And if it does, it does it in a
> plethora of different implementation states. That is the reason why
> we want to solve it once for all userlands in the kernel and not
> rely on user-space help.

For me this looks like "we are going to fix userspace bugs in kernel". 
Really! Not a good idea. Plus I still see this as abusing kernel API/ABI 
as resolution should be handled differently as you are proposing.

> Surely, userland can do a lot of things. It could also do the whole
> file system stuff (FUSE).
> 
> A more input device related example comes to my mind: userland could
> do keyboard mapping completely. It would suffice if the kernel
> presents some x/y coordinates or gpio-numbers for buttons and
> user-space could map. Still there is a (pre-)mapping to Key-Codes.
> And yes, they are mapped a second time in userland if needed, but it
> works sufficiently well if not done.
> 
> BR and thanks,
> Nikolaus

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1828 bytes --]

On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> > Hi Dmitry,
> > 
> > > Input driver may set resolution for given axis in units per mm
> > > (or units per radian for rotational axis ABS_RX, ABS_RY,
> > > ABS_RZ), and if you check the binding, you can use
> > > "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
> > > entire touch surface and set resolution from it so that
> > > userspace can calculate the proper scaling factor.
> > 
> > How is this information exposed by the kernel to user-space? By
> > scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should
> have all needed information here. This is generic input interface,
> no DT is needed.

Looking at kernel code... via EVIOCSABS ioctl() you can even set 
resolution from userspace for specified input device.

So this could be potentially used for calibrating input device from 
userspace? (In case DT data will not fully match current HW)

> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> While I'm watching this discussion... in my opinion kernel should
> just invert input axes (when needed) and should not do any other
> normalization or integer/floating-point
> re-calibration/re-calculation. If it correctly exports minimum
> value, maximum value and resolution then userspace can correctly
> re-scale input events to units which userspace needs (e.g. mapping
> into LCD screen pixels or whatever is needed).

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1858 bytes --]

On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> > Hi Dmitry,
> > 
> > > Input driver may set resolution for given axis in units per mm
> > > (or units per radian for rotational axis ABS_RX, ABS_RY,
> > > ABS_RZ), and if you check the binding, you can use
> > > "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
> > > entire touch surface and set resolution from it so that
> > > userspace can calculate the proper scaling factor.
> > 
> > How is this information exposed by the kernel to user-space? By
> > scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should
> have all needed information here. This is generic input interface,
> no DT is needed.

Looking at kernel code... via EVIOCSABS ioctl() you can even set 
resolution from userspace for specified input device.

So this could be potentially used for calibrating input device from 
userspace? (In case DT data will not fully match current HW)

> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> While I'm watching this discussion... in my opinion kernel should
> just invert input axes (when needed) and should not do any other
> normalization or integer/floating-point
> re-calibration/re-calculation. If it correctly exports minimum
> value, maximum value and resolution then userspace can correctly
> re-scale input events to units which userspace needs (e.g. mapping
> into LCD screen pixels or whatever is needed).

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
>> Hi Pali,
>> 
>>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> Hi Nikolaus!
>>> 
>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>> 
>>>>> Input driver may set resolution for given axis in units per mm
>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>> ABS_RZ), and if you check the binding, you can use
>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>> entire touch surface and set resolution from it so that
>>>>> userspace can calculate the proper scaling factor.
>>>> 
>>>> How is this information exposed by the kernel to user-space? By
>>>> scanning the DT file or tree?
>>> 
>>> Set input_abs_set_res() from kernel. And in userspace call
>>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
>>> you should have all needed information here. This is generic input
>>> interface, no DT is needed.
>> 
>> This assumes that I can and want to write a graphics system myself.
> 
> Not only. There are already existing graphics systems. And you need to
> provide needed information from kernel, so they can start using it.
> 
> So input_abs_set_res() is needed to use in your kernel driver.

I didn't know about this feature and obviously nobody else has implemented
it in the tsc2007 driver.

> 
>>> I hope that XServer is already using it for evdev devices...
>> 
>> No idea if it does. It is a black box for me out of our control.
> 
> https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1479
> 
> So yes, it does.
> 
>>> For whole implementation look at evtest program. That should be
>>> good starting point for your userspace implementation.
>> 
>> The problem I have is that *I* have no userspace implementation and
>> the GTA04 project does not want to enforce one. We have several
>> different ones: X11 based (LXDE and others), Qt (fb based),
>> Replicant to name some.
>> 
>> All have the same problem to be solved once. The common denominator
>> for a solution are 2 lines of code in the kernel plus some DT
>> properties you need anyways if calibration should be automated in
>> userland.
> 
> As I wrote above part of linux input API is resolution value. And from
> all information I understood that having current value, minimal value,
> maximal value and resolution is enough for correct calculation of pixel
> coordinates in userspace.
> 
> And Xserver evdev driver is using it.
> 
> If other non-X11 application (which you want/need to use) use resolution
> information incorrectly (or calculate positions incorrectly), then this
> is bug that application. Not in Linux kernel, that is important.
> 
> And I would rather see fixes of such bugs in that (broken) application
> as doing workarounds in kernel, just because of bugs in application.
> 
> More important, are those applications really broken?
> 
> From my point of view: Reporting size of input device is already part of
> stable kernel <--> userspace API/ABI and it should be used instead of
> inventing new way...
> 
>>> While I'm watching this discussion... in my opinion kernel should
>>> just invert input axes (when needed) and should not do any other
>>> normalization or integer/floating-point
>>> re-calibration/re-calculation. If it correctly exports minimum
>>> value, maximum value and resolution then userspace can correctly
>>> re-scale input events to units which userspace needs (e.g. mapping
>>> into LCD screen pixels or whatever is needed).
>> 
>> It can, but afaik it does not yet.
> 
> I did not tested it, but code is in xf86-input-evdev already there.
> 
> So please try to implement input_abs_set_res() in kernel driver and test
> userspace.
> 
>> And if it does, it does it in a
>> plethora of different implementation states. That is the reason why
>> we want to solve it once for all userlands in the kernel and not
>> rely on user-space help.
> 
> For me this looks like "we are going to fix userspace bugs in kernel".

Such things are system bugs and it is neither necessarily a userspace
or kernel bug.

> Really! Not a good idea. Plus I still see this as abusing kernel API/ABI
> as resolution should be handled differently as you are proposing.

I don't understand what you say here. Where are we abusing kernel
API/ABI?

> 
>> Surely, userland can do a lot of things. It could also do the whole
>> file system stuff (FUSE).
>> 
>> A more input device related example comes to my mind: userland could
>> do keyboard mapping completely. It would suffice if the kernel
>> presents some x/y coordinates or gpio-numbers for buttons and
>> user-space could map. Still there is a (pre-)mapping to Key-Codes.
>> And yes, they are mapped a second time in userland if needed, but it
>> works sufficiently well if not done.
>> 
>> BR and thanks,
>> Nikolaus

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
>> Hi Pali,
>> 
>>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> 
>>> Hi Nikolaus!
>>> 
>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>> 
>>>>> Input driver may set resolution for given axis in units per mm
>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>> ABS_RZ), and if you check the binding, you can use
>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>> entire touch surface and set resolution from it so that
>>>>> userspace can calculate the proper scaling factor.
>>>> 
>>>> How is this information exposed by the kernel to user-space? By
>>>> scanning the DT file or tree?
>>> 
>>> Set input_abs_set_res() from kernel. And in userspace call
>>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
>>> you should have all needed information here. This is generic input
>>> interface, no DT is needed.
>> 
>> This assumes that I can and want to write a graphics system myself.
> 
> Not only. There are already existing graphics systems. And you need to
> provide needed information from kernel, so they can start using it.
> 
> So input_abs_set_res() is needed to use in your kernel driver.

I didn't know about this feature and obviously nobody else has implemented
it in the tsc2007 driver.

> 
>>> I hope that XServer is already using it for evdev devices...
>> 
>> No idea if it does. It is a black box for me out of our control.
> 
> https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1479
> 
> So yes, it does.
> 
>>> For whole implementation look at evtest program. That should be
>>> good starting point for your userspace implementation.
>> 
>> The problem I have is that *I* have no userspace implementation and
>> the GTA04 project does not want to enforce one. We have several
>> different ones: X11 based (LXDE and others), Qt (fb based),
>> Replicant to name some.
>> 
>> All have the same problem to be solved once. The common denominator
>> for a solution are 2 lines of code in the kernel plus some DT
>> properties you need anyways if calibration should be automated in
>> userland.
> 
> As I wrote above part of linux input API is resolution value. And from
> all information I understood that having current value, minimal value,
> maximal value and resolution is enough for correct calculation of pixel
> coordinates in userspace.
> 
> And Xserver evdev driver is using it.
> 
> If other non-X11 application (which you want/need to use) use resolution
> information incorrectly (or calculate positions incorrectly), then this
> is bug that application. Not in Linux kernel, that is important.
> 
> And I would rather see fixes of such bugs in that (broken) application
> as doing workarounds in kernel, just because of bugs in application.
> 
> More important, are those applications really broken?
> 
> From my point of view: Reporting size of input device is already part of
> stable kernel <--> userspace API/ABI and it should be used instead of
> inventing new way...
> 
>>> While I'm watching this discussion... in my opinion kernel should
>>> just invert input axes (when needed) and should not do any other
>>> normalization or integer/floating-point
>>> re-calibration/re-calculation. If it correctly exports minimum
>>> value, maximum value and resolution then userspace can correctly
>>> re-scale input events to units which userspace needs (e.g. mapping
>>> into LCD screen pixels or whatever is needed).
>> 
>> It can, but afaik it does not yet.
> 
> I did not tested it, but code is in xf86-input-evdev already there.
> 
> So please try to implement input_abs_set_res() in kernel driver and test
> userspace.
> 
>> And if it does, it does it in a
>> plethora of different implementation states. That is the reason why
>> we want to solve it once for all userlands in the kernel and not
>> rely on user-space help.
> 
> For me this looks like "we are going to fix userspace bugs in kernel".

Such things are system bugs and it is neither necessarily a userspace
or kernel bug.

> Really! Not a good idea. Plus I still see this as abusing kernel API/ABI
> as resolution should be handled differently as you are proposing.

I don't understand what you say here. Where are we abusing kernel
API/ABI?

> 
>> Surely, userland can do a lot of things. It could also do the whole
>> file system stuff (FUSE).
>> 
>> A more input device related example comes to my mind: userland could
>> do keyboard mapping completely. It would suffice if the kernel
>> presents some x/y coordinates or gpio-numbers for buttons and
>> user-space could map. Still there is a (pre-)mapping to Key-Codes.
>> And yes, they are mapped a second time in userland if needed, but it
>> works sufficiently well if not done.
>> 
>> BR and thanks,
>> Nikolaus

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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


> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>> Hi Nikolaus!
>> 
>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
>>>> Input driver may set resolution for given axis in units per mm
>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>> ABS_RZ), and if you check the binding, you can use
>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>> entire touch surface and set resolution from it so that
>>>> userspace can calculate the proper scaling factor.
>>> 
>>> How is this information exposed by the kernel to user-space? By
>>> scanning the DT file or tree?
>> 
>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>> ioctl() on input device. Look at struct input_absinfo, you should
>> have all needed information here. This is generic input interface,
>> no DT is needed.
> 
> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> resolution from userspace for specified input device.
> 
> So this could be potentially used for calibrating input device from
> userspace? (In case DT data will not fully match current HW)
> 
>> I hope that XServer is already using it for evdev devices...
>> 
>> For whole implementation look at evtest program. That should be good
>> starting point for your userspace implementation.
>> 
>> While I'm watching this discussion... in my opinion kernel should
>> just invert input axes (when needed)

It is questionable why it should do that at all then.

User-Space can also easily do it. Either the driver should provide raw
data only or if it does pre-processing (scaling by +/-1), why exclude
pre-scaling by other factors?

>> and should not do any other
>> normalization or integer/floating-point
>> re-calibration/re-calculation. If it correctly exports minimum
>> value, maximum value and resolution then userspace can correctly
>> re-scale input events to units which userspace needs (e.g. mapping
>> into LCD screen pixels or whatever is needed).
> 
> --
> Pali Rohár
> pali.rohar@gmail.com


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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


> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>> Hi Nikolaus!
>> 
>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
>>>> Input driver may set resolution for given axis in units per mm
>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>> ABS_RZ), and if you check the binding, you can use
>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>> entire touch surface and set resolution from it so that
>>>> userspace can calculate the proper scaling factor.
>>> 
>>> How is this information exposed by the kernel to user-space? By
>>> scanning the DT file or tree?
>> 
>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>> ioctl() on input device. Look at struct input_absinfo, you should
>> have all needed information here. This is generic input interface,
>> no DT is needed.
> 
> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> resolution from userspace for specified input device.
> 
> So this could be potentially used for calibrating input device from
> userspace? (In case DT data will not fully match current HW)
> 
>> I hope that XServer is already using it for evdev devices...
>> 
>> For whole implementation look at evtest program. That should be good
>> starting point for your userspace implementation.
>> 
>> While I'm watching this discussion... in my opinion kernel should
>> just invert input axes (when needed)

It is questionable why it should do that at all then.

User-Space can also easily do it. Either the driver should provide raw
data only or if it does pre-processing (scaling by +/-1), why exclude
pre-scaling by other factors?

>> and should not do any other
>> normalization or integer/floating-point
>> re-calibration/re-calculation. If it correctly exports minimum
>> value, maximum value and resolution then userspace can correctly
>> re-scale input events to units which userspace needs (e.g. mapping
>> into LCD screen pixels or whatever is needed).
> 
> --
> Pali Rohár
> pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>
>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>> Hi Nikolaus!
>>>
>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>>
>>>>> Input driver may set resolution for given axis in units per mm
>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>> ABS_RZ), and if you check the binding, you can use
>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>> entire touch surface and set resolution from it so that
>>>>> userspace can calculate the proper scaling factor.
>>>>
>>>> How is this information exposed by the kernel to user-space? By
>>>> scanning the DT file or tree?
>>>
>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>> ioctl() on input device. Look at struct input_absinfo, you should
>>> have all needed information here. This is generic input interface,
>>> no DT is needed.
>>
>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>> resolution from userspace for specified input device.
>>
>> So this could be potentially used for calibrating input device from
>> userspace? (In case DT data will not fully match current HW)
>>
>>> I hope that XServer is already using it for evdev devices...
>>>
>>> For whole implementation look at evtest program. That should be good
>>> starting point for your userspace implementation.
>>>
>>> While I'm watching this discussion... in my opinion kernel should
>>> just invert input axes (when needed)
>
> It is questionable why it should do that at all then.

Because the task of the kernel is to provide unified view of the
hardware. Axis swapping and inversion is needed to that "up" is always
"up" and "right" is always "right".

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
>
>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>> Hi Nikolaus!
>>>
>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>>
>>>>> Input driver may set resolution for given axis in units per mm
>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>> ABS_RZ), and if you check the binding, you can use
>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>> entire touch surface and set resolution from it so that
>>>>> userspace can calculate the proper scaling factor.
>>>>
>>>> How is this information exposed by the kernel to user-space? By
>>>> scanning the DT file or tree?
>>>
>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>> ioctl() on input device. Look at struct input_absinfo, you should
>>> have all needed information here. This is generic input interface,
>>> no DT is needed.
>>
>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>> resolution from userspace for specified input device.
>>
>> So this could be potentially used for calibrating input device from
>> userspace? (In case DT data will not fully match current HW)
>>
>>> I hope that XServer is already using it for evdev devices...
>>>
>>> For whole implementation look at evtest program. That should be good
>>> starting point for your userspace implementation.
>>>
>>> While I'm watching this discussion... in my opinion kernel should
>>> just invert input axes (when needed)
>
> It is questionable why it should do that at all then.

Because the task of the kernel is to provide unified view of the
hardware. Axis swapping and inversion is needed to that "up" is always
"up" and "right" is always "right".

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> w=
rote:
>
>> Am 20.02.2017 um 22:08 schrieb Pali Roh=C3=A1r <pali.rohar@gmail.com>:
>>
>> On Monday 20 February 2017 20:42:15 Pali Roh=C3=A1r wrote:
>>> Hi Nikolaus!
>>>
>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>> Hi Dmitry,
>>>>
>>>>> Input driver may set resolution for given axis in units per mm
>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>> ABS_RZ), and if you check the binding, you can use
>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>> entire touch surface and set resolution from it so that
>>>>> userspace can calculate the proper scaling factor.
>>>>
>>>> How is this information exposed by the kernel to user-space? By
>>>> scanning the DT file or tree?
>>>
>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>> ioctl() on input device. Look at struct input_absinfo, you should
>>> have all needed information here. This is generic input interface,
>>> no DT is needed.
>>
>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>> resolution from userspace for specified input device.
>>
>> So this could be potentially used for calibrating input device from
>> userspace? (In case DT data will not fully match current HW)
>>
>>> I hope that XServer is already using it for evdev devices...
>>>
>>> For whole implementation look at evtest program. That should be good
>>> starting point for your userspace implementation.
>>>
>>> While I'm watching this discussion... in my opinion kernel should
>>> just invert input axes (when needed)
>
> It is questionable why it should do that at all then.

Because the task of the kernel is to provide unified view of the
hardware. Axis swapping and inversion is needed to that "up" is always
"up" and "right" is always "right".

Thanks.

--=20
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3626 bytes --]

On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
> >> Hi Pali,
> >> 
> >>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> Hi Nikolaus!
> >>> 
> >>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>> Hi Dmitry,
> >>>> 
> >>>>> Input driver may set resolution for given axis in units per mm
> >>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>> ABS_RZ), and if you check the binding, you can use
> >>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>> of entire touch surface and set resolution from it so that
> >>>>> userspace can calculate the proper scaling factor.
> >>>> 
> >>>> How is this information exposed by the kernel to user-space? By
> >>>> scanning the DT file or tree?
> >>> 
> >>> Set input_abs_set_res() from kernel. And in userspace call
> >>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> >>> you should have all needed information here. This is generic
> >>> input interface, no DT is needed.
> >> 
> >> This assumes that I can and want to write a graphics system
> >> myself.
> > 
> > Not only. There are already existing graphics systems. And you need
> > to provide needed information from kernel, so they can start using
> > it.
> > 
> > So input_abs_set_res() is needed to use in your kernel driver.
> 
> I didn't know about this feature and obviously nobody else has
> implemented it in the tsc2007 driver.

So... before doing other things, can you deeply look at it and check if 
it really fixes this problem? Because I think that yes.

You can probably set it from DT and in your DT file you can have stored 
screen size (or resolution factor).

Also for testing, you can set it even via userspace (ioctl which I wrote 
in previous email).

> >> And if it does, it does it in a
> >> plethora of different implementation states. That is the reason
> >> why we want to solve it once for all userlands in the kernel and
> >> not rely on user-space help.
> > 
> > For me this looks like "we are going to fix userspace bugs in
> > kernel".
> 
> Such things are system bugs and it is neither necessarily a userspace
> or kernel bug.

In case kernel defines stable API/ABI and correctly provides information 
via that API/ABI and application does not work correctly, then I would 
say it is bug in application. Not in kernel.

We can say that some kernel API/ABI is wrong too. And in this case it 
could be bug in kernel.

So is current stable kernel API/ABI for input device wrong? I do not 
thing. But if you think that yes, please show us what exactly and we can 
start discussing how to fix such problem which you see/have. I know that 
no application is without bugs, but in my opinion problem which you are 
describing is already solved and defined by current stable kernel ABI.

> > Really! Not a good idea. Plus I still see this as abusing kernel
> > API/ABI as resolution should be handled differently as you are
> > proposing.
> 
> I don't understand what you say here. Where are we abusing kernel
> API/ABI?

I mean that we already have stable API/ABI how to export size of input 
screen from kernel to userspace. And you want to rescale event data 
directly in kernel to workaround problem of screen size. So I think this 
is abusing API/ABI as kernel already have API for it.

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3716 bytes --]

On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
> >> Hi Pali,
> >> 
> >>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>> 
> >>> Hi Nikolaus!
> >>> 
> >>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>> Hi Dmitry,
> >>>> 
> >>>>> Input driver may set resolution for given axis in units per mm
> >>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>> ABS_RZ), and if you check the binding, you can use
> >>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>> of entire touch surface and set resolution from it so that
> >>>>> userspace can calculate the proper scaling factor.
> >>>> 
> >>>> How is this information exposed by the kernel to user-space? By
> >>>> scanning the DT file or tree?
> >>> 
> >>> Set input_abs_set_res() from kernel. And in userspace call
> >>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> >>> you should have all needed information here. This is generic
> >>> input interface, no DT is needed.
> >> 
> >> This assumes that I can and want to write a graphics system
> >> myself.
> > 
> > Not only. There are already existing graphics systems. And you need
> > to provide needed information from kernel, so they can start using
> > it.
> > 
> > So input_abs_set_res() is needed to use in your kernel driver.
> 
> I didn't know about this feature and obviously nobody else has
> implemented it in the tsc2007 driver.

So... before doing other things, can you deeply look at it and check if 
it really fixes this problem? Because I think that yes.

You can probably set it from DT and in your DT file you can have stored 
screen size (or resolution factor).

Also for testing, you can set it even via userspace (ioctl which I wrote 
in previous email).

> >> And if it does, it does it in a
> >> plethora of different implementation states. That is the reason
> >> why we want to solve it once for all userlands in the kernel and
> >> not rely on user-space help.
> > 
> > For me this looks like "we are going to fix userspace bugs in
> > kernel".
> 
> Such things are system bugs and it is neither necessarily a userspace
> or kernel bug.

In case kernel defines stable API/ABI and correctly provides information 
via that API/ABI and application does not work correctly, then I would 
say it is bug in application. Not in kernel.

We can say that some kernel API/ABI is wrong too. And in this case it 
could be bug in kernel.

So is current stable kernel API/ABI for input device wrong? I do not 
thing. But if you think that yes, please show us what exactly and we can 
start discussing how to fix such problem which you see/have. I know that 
no application is without bugs, but in my opinion problem which you are 
describing is already solved and defined by current stable kernel ABI.

> > Really! Not a good idea. Plus I still see this as abusing kernel
> > API/ABI as resolution should be handled differently as you are
> > proposing.
> 
> I don't understand what you say here. Where are we abusing kernel
> API/ABI?

I mean that we already have stable API/ABI how to export size of input 
screen from kernel to userspace. And you want to rescale event data 
directly in kernel to workaround problem of screen size. So I think this 
is abusing API/ABI as kernel already have API for it.

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1576 bytes --]

On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
> > Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >> While I'm watching this discussion... in my opinion kernel should
> >> just invert input axes (when needed)
> 
> It is questionable why it should do that at all then.
> 
> User-Space can also easily do it. Either the driver should provide
> raw data only or if it does pre-processing (scaling by +/-1), why
> exclude pre-scaling by other factors?

Via resolution property which is in that EVIOCSABS ioctl() you specify 
value which represent unit per mm. So you cannot do full rescaling like 
via affine transformation. Specially you cannot swap axes or invert it.

As such thing is not supported by current kernel <--> userspace API it 
needs to be done in kernel.

Moreover I see that this is already handled by kernel's of_touchscreen.c 
code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

And... I'm not sure but I think that linux exports absolute input 
devices with coordinates where point (0,0) is mapped as left upper 
corner.

> >> and should not do any other
> >> normalization or integer/floating-point
> >> re-calibration/re-calculation. If it correctly exports minimum
> >> value, maximum value and resolution then userspace can correctly
> >> re-scale input events to units which userspace needs (e.g. mapping
> >> into LCD screen pixels or whatever is needed).

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1576 bytes --]

On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
> > Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >> While I'm watching this discussion... in my opinion kernel should
> >> just invert input axes (when needed)
> 
> It is questionable why it should do that at all then.
> 
> User-Space can also easily do it. Either the driver should provide
> raw data only or if it does pre-processing (scaling by +/-1), why
> exclude pre-scaling by other factors?

Via resolution property which is in that EVIOCSABS ioctl() you specify 
value which represent unit per mm. So you cannot do full rescaling like 
via affine transformation. Specially you cannot swap axes or invert it.

As such thing is not supported by current kernel <--> userspace API it 
needs to be done in kernel.

Moreover I see that this is already handled by kernel's of_touchscreen.c 
code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

And... I'm not sure but I think that linux exports absolute input 
devices with coordinates where point (0,0) is mapped as left upper 
corner.

> >> and should not do any other
> >> normalization or integer/floating-point
> >> re-calibration/re-calculation. If it correctly exports minimum
> >> value, maximum value and resolution then userspace can correctly
> >> re-scale input events to units which userspace needs (e.g. mapping
> >> into LCD screen pixels or whatever is needed).

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Petr Cvek]

Hi,

Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> Hi Nikolaus!
>>>>
>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>> entire touch surface and set resolution from it so that
>>>>>> userspace can calculate the proper scaling factor.
>>>>>
>>>>> How is this information exposed by the kernel to user-space? By
>>>>> scanning the DT file or tree?
>>>>
>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>> have all needed information here. This is generic input interface,
>>>> no DT is needed.
>>>
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>>
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>>
>>>> I hope that XServer is already using it for evdev devices...
>>>>
>>>> For whole implementation look at evtest program. That should be good
>>>> starting point for your userspace implementation.
>>>>
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>>
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).

best regards,
Petr

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Petr Cvek]

Hi,

Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
>>
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> Hi Nikolaus!
>>>>
>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>> entire touch surface and set resolution from it so that
>>>>>> userspace can calculate the proper scaling factor.
>>>>>
>>>>> How is this information exposed by the kernel to user-space? By
>>>>> scanning the DT file or tree?
>>>>
>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>> have all needed information here. This is generic input interface,
>>>> no DT is needed.
>>>
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>>
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>>
>>>> I hope that XServer is already using it for evdev devices...
>>>>
>>>> For whole implementation look at evtest program. That should be good
>>>> starting point for your userspace implementation.
>>>>
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>>
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).

best regards,
Petr

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
> Hi,
>
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>
>>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>>
>>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>>> Hi Nikolaus!
>>>>>
>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>>
>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>>> entire touch surface and set resolution from it so that
>>>>>>> userspace can calculate the proper scaling factor.
>>>>>>
>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>> scanning the DT file or tree?
>>>>>
>>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>>> have all needed information here. This is generic input interface,
>>>>> no DT is needed.
>>>>
>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>> resolution from userspace for specified input device.
>>>>
>>>> So this could be potentially used for calibrating input device from
>>>> userspace? (In case DT data will not fully match current HW)
>>>>
>>>>> I hope that XServer is already using it for evdev devices...
>>>>>
>>>>> For whole implementation look at evtest program. That should be good
>>>>> starting point for your userspace implementation.
>>>>>
>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>> just invert input axes (when needed)
>>>
>>> It is questionable why it should do that at all then.
>>
>> Because the task of the kernel is to provide unified view of the
>> hardware. Axis swapping and inversion is needed to that "up" is always
>> "up" and "right" is always "right".
>
> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).

Yes, you can make it work for your touchscreen as long as you know
that it inverted somehow. How you gain this knowledge is the question.

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek-qphu/3gb4gc@public.gmane.org> wrote:
> Hi,
>
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
>>>
>>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>
>>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>>> Hi Nikolaus!
>>>>>
>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>>
>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>>> entire touch surface and set resolution from it so that
>>>>>>> userspace can calculate the proper scaling factor.
>>>>>>
>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>> scanning the DT file or tree?
>>>>>
>>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>>> have all needed information here. This is generic input interface,
>>>>> no DT is needed.
>>>>
>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>> resolution from userspace for specified input device.
>>>>
>>>> So this could be potentially used for calibrating input device from
>>>> userspace? (In case DT data will not fully match current HW)
>>>>
>>>>> I hope that XServer is already using it for evdev devices...
>>>>>
>>>>> For whole implementation look at evtest program. That should be good
>>>>> starting point for your userspace implementation.
>>>>>
>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>> just invert input axes (when needed)
>>>
>>> It is questionable why it should do that at all then.
>>
>> Because the task of the kernel is to provide unified view of the
>> hardware. Axis swapping and inversion is needed to that "up" is always
>> "up" and "right" is always "right".
>
> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).

Yes, you can make it work for your touchscreen as long as you know
that it inverted somehow. How you gain this knowledge is the question.

Thanks.

-- 
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
> Hi,
>
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com=
> wrote:
>>>
>>>> Am 20.02.2017 um 22:08 schrieb Pali Roh=C3=A1r <pali.rohar@gmail.com>:
>>>>
>>>> On Monday 20 February 2017 20:42:15 Pali Roh=C3=A1r wrote:
>>>>> Hi Nikolaus!
>>>>>
>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>>
>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>>> entire touch surface and set resolution from it so that
>>>>>>> userspace can calculate the proper scaling factor.
>>>>>>
>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>> scanning the DT file or tree?
>>>>>
>>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>>> have all needed information here. This is generic input interface,
>>>>> no DT is needed.
>>>>
>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>> resolution from userspace for specified input device.
>>>>
>>>> So this could be potentially used for calibrating input device from
>>>> userspace? (In case DT data will not fully match current HW)
>>>>
>>>>> I hope that XServer is already using it for evdev devices...
>>>>>
>>>>> For whole implementation look at evtest program. That should be good
>>>>> starting point for your userspace implementation.
>>>>>
>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>> just invert input axes (when needed)
>>>
>>> It is questionable why it should do that at all then.
>>
>> Because the task of the kernel is to provide unified view of the
>> hardware. Axis swapping and inversion is needed to that "up" is always
>> "up" and "right" is always "right".
>
> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (=
on TSC2046).

Yes, you can make it work for your touchscreen as long as you know
that it inverted somehow. How you gain this knowledge is the question.

Thanks.

--=20
Dmitry

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Petr Cvek]

Hi

Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a):
> Hi Pavel,
> 
>> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>:
>>
>> hi!
>>
>>>>> But as said I don't think we need float or fixed point for practical systems
>>>>> at all.
>>>>
>>>> So you are going to loose precision. And if userspace decides to
>>>> calibrate it slightly differently from kernel, lost precision will
>>>> matter.
>>>
>>> Really?
>>
>> Really.
>>
>>> Example:
>>>
>>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
>>>
>>> This is scaled to let's say 0..640.
>>
>> Ok. Now userspace realizes that kernel alignemnt is off, and it would
>> want to scale it to 1..642.
> 
> Screen coordinates are still 0..639.
> 
>> That will mean that single pixel will be
>> inaccessible, right?
> 
> Yes, that can happen if the additional user-space scale is > 1.0.
> 
> As long as it is small (I expect <1.01 = 1% error in scale) it is
> barely noticeable.
> 
> Therefore, I asked before: how big in pixels is your finger or stylus?
> Does this effect matter?
> 
> A resistive touch is a man-machine-interface where people press buttons of at
> least 12x12 pixels size (or they are no longer visually recognizable).

Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I would like
to be able to select a single letter in the console.

cheers,
Petr

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Petr Cvek]

Hi

Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a):
> Hi Pavel,
> 
>> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
>>
>> hi!
>>
>>>>> But as said I don't think we need float or fixed point for practical systems
>>>>> at all.
>>>>
>>>> So you are going to loose precision. And if userspace decides to
>>>> calibrate it slightly differently from kernel, lost precision will
>>>> matter.
>>>
>>> Really?
>>
>> Really.
>>
>>> Example:
>>>
>>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
>>>
>>> This is scaled to let's say 0..640.
>>
>> Ok. Now userspace realizes that kernel alignemnt is off, and it would
>> want to scale it to 1..642.
> 
> Screen coordinates are still 0..639.
> 
>> That will mean that single pixel will be
>> inaccessible, right?
> 
> Yes, that can happen if the additional user-space scale is > 1.0.
> 
> As long as it is small (I expect <1.01 = 1% error in scale) it is
> barely noticeable.
> 
> Therefore, I asked before: how big in pixels is your finger or stylus?
> Does this effect matter?
> 
> A resistive touch is a man-machine-interface where people press buttons of at
> least 12x12 pixels size (or they are no longer visually recognizable).

Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I would like
to be able to select a single letter in the console.

cheers,
Petr

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2768 bytes --]

On Monday 20 February 2017 23:21:37 Petr Cvek wrote:
> Hi,
> 
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller
> > <hns@goldelico.com> wrote:
> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >>>> Hi Nikolaus!
> >>>> 
> >>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>> Hi Dmitry,
> >>>>> 
> >>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>>> of entire touch surface and set resolution from it so that
> >>>>>> userspace can calculate the proper scaling factor.
> >>>>> 
> >>>>> How is this information exposed by the kernel to user-space? By
> >>>>> scanning the DT file or tree?
> >>>> 
> >>>> Set input_abs_set_res() from kernel. And in userspace call
> >>>> EVIOCGABS ioctl() on input device. Look at struct
> >>>> input_absinfo, you should have all needed information here.
> >>>> This is generic input interface, no DT is needed.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device
> >>> from userspace? (In case DT data will not fully match current
> >>> HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be
> >>>> good starting point for your userspace implementation.
> >>>> 
> >>>> While I'm watching this discussion... in my opinion kernel
> >>>> should just invert input axes (when needed)
> >> 
> >> It is questionable why it should do that at all then.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is
> > always "up" and "right" is always "right".
> 
> Actually my Xorg calibration 3x3 matrix is fine with both axis
> inverted (on TSC2046).

Yes, 3x3 matrix which represent affine transformation can code inverted 
axis. This is IIRC what Xorg is doing.

But with information of min, max and current values plus resolution you 
cannot code information that axes are inverted (unless you misuse fact 
what is minimal and what maximal value). And this is what kernel 
provides for input device.

Affine transformation supported by Xorg is "stronger" as resolution 
provided by kernel.

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2768 bytes --]

On Monday 20 February 2017 23:21:37 Petr Cvek wrote:
> Hi,
> 
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller
> > <hns@goldelico.com> wrote:
> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >>>> Hi Nikolaus!
> >>>> 
> >>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>> Hi Dmitry,
> >>>>> 
> >>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>>> of entire touch surface and set resolution from it so that
> >>>>>> userspace can calculate the proper scaling factor.
> >>>>> 
> >>>>> How is this information exposed by the kernel to user-space? By
> >>>>> scanning the DT file or tree?
> >>>> 
> >>>> Set input_abs_set_res() from kernel. And in userspace call
> >>>> EVIOCGABS ioctl() on input device. Look at struct
> >>>> input_absinfo, you should have all needed information here.
> >>>> This is generic input interface, no DT is needed.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device
> >>> from userspace? (In case DT data will not fully match current
> >>> HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be
> >>>> good starting point for your userspace implementation.
> >>>> 
> >>>> While I'm watching this discussion... in my opinion kernel
> >>>> should just invert input axes (when needed)
> >> 
> >> It is questionable why it should do that at all then.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is
> > always "up" and "right" is always "right".
> 
> Actually my Xorg calibration 3x3 matrix is fine with both axis
> inverted (on TSC2046).

Yes, 3x3 matrix which represent affine transformation can code inverted 
axis. This is IIRC what Xorg is doing.

But with information of min, max and current values plus resolution you 
cannot code information that axes are inverted (unless you misuse fact 
what is minimal and what maximal value). And this is what kernel 
provides for input device.

Affine transformation supported by Xorg is "stronger" as resolution 
provided by kernel.

-- 
Pali Rohár
pali.rohar@gmail.com

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

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi,

> Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> 
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> Hi Nikolaus!
>>>> 
>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>> Hi Dmitry,
>>>>> 
>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>> entire touch surface and set resolution from it so that
>>>>>> userspace can calculate the proper scaling factor.
>>>>> 
>>>>> How is this information exposed by the kernel to user-space? By
>>>>> scanning the DT file or tree?
>>>> 
>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>> have all needed information here. This is generic input interface,
>>>> no DT is needed.
>>> 
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>> 
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>> 
>>>> I hope that XServer is already using it for evdev devices...
>>>> 
>>>> For whole implementation look at evtest program. That should be good
>>>> starting point for your userspace implementation.
>>>> 
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
screen and touching pixel (639,479) is always (639,479)?

I think it is time to end this discussion.

It has show me how much a mess and half-baked area this is, which I did
not expect. I read contradicting messages from different people:

* don't break user space because it is carved in stone
* fix users space if you want to do it properly
* scaling by +/-1 and shifting by full range is ok
* scaling by ts-size/adc-range and shifting by adc_min is not ok
* full numeric ADC resolution is required but subpixel coordinates is not acceptable

I will monitor this to see if this becomes sorted out before submitting anything
new.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi,

> Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> 
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> Hi Nikolaus!
>>>> 
>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>> Hi Dmitry,
>>>>> 
>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>> entire touch surface and set resolution from it so that
>>>>>> userspace can calculate the proper scaling factor.
>>>>> 
>>>>> How is this information exposed by the kernel to user-space? By
>>>>> scanning the DT file or tree?
>>>> 
>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>> have all needed information here. This is generic input interface,
>>>> no DT is needed.
>>> 
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>> 
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>> 
>>>> I hope that XServer is already using it for evdev devices...
>>>> 
>>>> For whole implementation look at evtest program. That should be good
>>>> starting point for your userspace implementation.
>>>> 
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
screen and touching pixel (639,479) is always (639,479)?

I think it is time to end this discussion.

It has show me how much a mess and half-baked area this is, which I did
not expect. I read contradicting messages from different people:

* don't break user space because it is carved in stone
* fix users space if you want to do it properly
* scaling by +/-1 and shifting by full range is ok
* scaling by ts-size/adc-range and shifting by adc_min is not ok
* full numeric ADC resolution is required but subpixel coordinates is not acceptable

I will monitor this to see if this becomes sorted out before submitting anything
new.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi,

> Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller =
<hns@goldelico.com> wrote:
>>=20
>>> Am 20.02.2017 um 22:08 schrieb Pali Roh=C3=A1r =
<pali.rohar@gmail.com>:
>>>=20
>>> On Monday 20 February 2017 20:42:15 Pali Roh=C3=A1r wrote:
>>>> Hi Nikolaus!
>>>>=20
>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>> Hi Dmitry,
>>>>>=20
>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>> entire touch surface and set resolution from it so that
>>>>>> userspace can calculate the proper scaling factor.
>>>>>=20
>>>>> How is this information exposed by the kernel to user-space? By
>>>>> scanning the DT file or tree?
>>>>=20
>>>> Set input_abs_set_res() from kernel. And in userspace call =
EVIOCGABS
>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>> have all needed information here. This is generic input interface,
>>>> no DT is needed.
>>>=20
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>>=20
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>>=20
>>>> I hope that XServer is already using it for evdev devices...
>>>>=20
>>>> For whole implementation look at evtest program. That should be =
good
>>>> starting point for your userspace implementation.
>>>>=20
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>>=20
>> It is questionable why it should do that at all then.
>=20
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on =
the
screen and touching pixel (639,479) is always (639,479)?

I think it is time to end this discussion.

It has show me how much a mess and half-baked area this is, which I did
not expect. I read contradicting messages from different people:

* don't break user space because it is carved in stone
* fix users space if you want to do it properly
* scaling by +/-1 and shifting by full range is ok
* scaling by ts-size/adc-range and shifting by adc_min is not ok
* full numeric ADC resolution is required but subpixel coordinates is =
not acceptable

I will monitor this to see if this becomes sorted out before submitting =
anything
new.

BR and thanks,
Nikolaus=

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
>> Hi Pali,
>> 
>>> Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
>>>> Hi Pali,
>>>> 
>>>>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>>> 
>>>>> Hi Nikolaus!
>>>>> 
>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>> 
>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
>>>>>>> of entire touch surface and set resolution from it so that
>>>>>>> userspace can calculate the proper scaling factor.
>>>>>> 
>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>> scanning the DT file or tree?
>>>>> 
>>>>> Set input_abs_set_res() from kernel. And in userspace call
>>>>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
>>>>> you should have all needed information here. This is generic
>>>>> input interface, no DT is needed.
>>>> 
>>>> This assumes that I can and want to write a graphics system
>>>> myself.
>>> 
>>> Not only. There are already existing graphics systems. And you need
>>> to provide needed information from kernel, so they can start using
>>> it.
>>> 
>>> So input_abs_set_res() is needed to use in your kernel driver.
>> 
>> I didn't know about this feature and obviously nobody else has
>> implemented it in the tsc2007 driver.
> 
> So... before doing other things, can you deeply look at it and check if
> it really fixes this problem? Because I think that yes.
> 
> You can probably set it from DT and in your DT file you can have stored
> screen size (or resolution factor).
> 
> Also for testing, you can set it even via userspace (ioctl which I wrote
> in previous email).

Interesting thing. It does not seem to be well known because nobody else
brought it up during several months of lenghty discussions.

I have seen it is in use for scaling topics, e.g. https://lkml.org/lkml/2015/7/9/749

> 
>>>> And if it does, it does it in a
>>>> plethora of different implementation states. That is the reason
>>>> why we want to solve it once for all userlands in the kernel and
>>>> not rely on user-space help.
>>> 
>>> For me this looks like "we are going to fix userspace bugs in
>>> kernel".
>> 
>> Such things are system bugs and it is neither necessarily a userspace
>> or kernel bug.
> 
> In case kernel defines stable API/ABI and correctly provides information
> via that API/ABI and application does not work correctly, then I would
> say it is bug in application. Not in kernel.

So a kernel can simply add a new interface and declare bugs for userland?

> 
> We can say that some kernel API/ABI is wrong too. And in this case it
> could be bug in kernel.
> 
> So is current stable kernel API/ABI for input device wrong? I do not
> thing.

Difficult to judge because there is scarce documentation of this.

> But if you think that yes, please show us what exactly and we can
> start discussing how to fix such problem which you see/have. I know that
> no application is without bugs, but in my opinion problem which you are
> describing is already solved and defined by current stable kernel ABI.
> 
>>> Really! Not a good idea. Plus I still see this as abusing kernel
>>> API/ABI as resolution should be handled differently as you are
>>> proposing.
>> 
>> I don't understand what you say here. Where are we abusing kernel
>> API/ABI?
> 
> I mean that we already have stable API/ABI how to export size of input
> screen from kernel to userspace. And you want to rescale event data
> directly in kernel to workaround problem of screen size. So I think this
> is abusing API/ABI as kernel already have API for it.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
>> Hi Pali,
>> 
>>> Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> 
>>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
>>>> Hi Pali,
>>>> 
>>>>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>> 
>>>>> Hi Nikolaus!
>>>>> 
>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>> Hi Dmitry,
>>>>>> 
>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
>>>>>>> of entire touch surface and set resolution from it so that
>>>>>>> userspace can calculate the proper scaling factor.
>>>>>> 
>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>> scanning the DT file or tree?
>>>>> 
>>>>> Set input_abs_set_res() from kernel. And in userspace call
>>>>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
>>>>> you should have all needed information here. This is generic
>>>>> input interface, no DT is needed.
>>>> 
>>>> This assumes that I can and want to write a graphics system
>>>> myself.
>>> 
>>> Not only. There are already existing graphics systems. And you need
>>> to provide needed information from kernel, so they can start using
>>> it.
>>> 
>>> So input_abs_set_res() is needed to use in your kernel driver.
>> 
>> I didn't know about this feature and obviously nobody else has
>> implemented it in the tsc2007 driver.
> 
> So... before doing other things, can you deeply look at it and check if
> it really fixes this problem? Because I think that yes.
> 
> You can probably set it from DT and in your DT file you can have stored
> screen size (or resolution factor).
> 
> Also for testing, you can set it even via userspace (ioctl which I wrote
> in previous email).

Interesting thing. It does not seem to be well known because nobody else
brought it up during several months of lenghty discussions.

I have seen it is in use for scaling topics, e.g. https://lkml.org/lkml/2015/7/9/749

> 
>>>> And if it does, it does it in a
>>>> plethora of different implementation states. That is the reason
>>>> why we want to solve it once for all userlands in the kernel and
>>>> not rely on user-space help.
>>> 
>>> For me this looks like "we are going to fix userspace bugs in
>>> kernel".
>> 
>> Such things are system bugs and it is neither necessarily a userspace
>> or kernel bug.
> 
> In case kernel defines stable API/ABI and correctly provides information
> via that API/ABI and application does not work correctly, then I would
> say it is bug in application. Not in kernel.

So a kernel can simply add a new interface and declare bugs for userland?

> 
> We can say that some kernel API/ABI is wrong too. And in this case it
> could be bug in kernel.
> 
> So is current stable kernel API/ABI for input device wrong? I do not
> thing.

Difficult to judge because there is scarce documentation of this.

> But if you think that yes, please show us what exactly and we can
> start discussing how to fix such problem which you see/have. I know that
> no application is without bugs, but in my opinion problem which you are
> describing is already solved and defined by current stable kernel ABI.
> 
>>> Really! Not a good idea. Plus I still see this as abusing kernel
>>> API/ABI as resolution should be handled differently as you are
>>> proposing.
>> 
>> I don't understand what you say here. Where are we abusing kernel
>> API/ABI?
> 
> I mean that we already have stable API/ABI how to export size of input
> screen from kernel to userspace. And you want to rescale event data
> directly in kernel to workaround problem of screen size. So I think this
> is abusing API/ABI as kernel already have API for it.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
>> 
>> User-Space can also easily do it. Either the driver should provide
>> raw data only or if it does pre-processing (scaling by +/-1), why
>> exclude pre-scaling by other factors?
> 
> Via resolution property which is in that EVIOCSABS ioctl() you specify
> value which represent unit per mm. So you cannot do full rescaling like
> via affine transformation. Specially you cannot swap axes or invert it.
> 
> As such thing is not supported by current kernel <--> userspace API it
> needs to be done in kernel.

Then, this what you asked for to be missing in the ABI and should be added
to clean upt the kernel drivers.

> 
> Moreover I see that this is already handled by kernel's of_touchscreen.c
> code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

Should be removed IMHO because user-space can do it equally well.
By setting the affine transform to negative values or use something
like ((0 -1) (1 0))

Or it should be processed as a generic value by the input core and should
not need to be implemented in every driver again and again.

If input core would handle these properties in a generic way, this patch
is no longer necessary (wrt flipping and rotation).

So please fix the input core so that it makes life of device driver developers
easier.

> 
> And... I'm not sure but I think that linux exports absolute input
> devices with coordinates where point (0,0) is mapped as left upper
> corner.
> 
>>>> and should not do any other
>>>> normalization or integer/floating-point
>>>> re-calibration/re-calculation. If it correctly exports minimum
>>>> value, maximum value and resolution then userspace can correctly
>>>> re-scale input events to units which userspace needs (e.g. mapping
>>>> into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
>> 
>> User-Space can also easily do it. Either the driver should provide
>> raw data only or if it does pre-processing (scaling by +/-1), why
>> exclude pre-scaling by other factors?
> 
> Via resolution property which is in that EVIOCSABS ioctl() you specify
> value which represent unit per mm. So you cannot do full rescaling like
> via affine transformation. Specially you cannot swap axes or invert it.
> 
> As such thing is not supported by current kernel <--> userspace API it
> needs to be done in kernel.

Then, this what you asked for to be missing in the ABI and should be added
to clean upt the kernel drivers.

> 
> Moreover I see that this is already handled by kernel's of_touchscreen.c
> code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

Should be removed IMHO because user-space can do it equally well.
By setting the affine transform to negative values or use something
like ((0 -1) (1 0))

Or it should be processed as a generic value by the input core and should
not need to be implemented in every driver again and again.

If input core would handle these properties in a generic way, this patch
is no longer necessary (wrt flipping and rotation).

So please fix the input core so that it makes life of device driver developers
easier.

> 
> And... I'm not sure but I think that linux exports absolute input
> devices with coordinates where point (0,0) is mapped as left upper
> corner.
> 
>>>> and should not do any other
>>>> normalization or integer/floating-point
>>>> re-calibration/re-calculation. If it correctly exports minimum
>>>> value, maximum value and resolution then userspace can correctly
>>>> re-scale input events to units which userspace needs (e.g. mapping
>>>> into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
>> Hi,
>> 
>> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>> 
>>>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>>> 
>>>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>>>> Hi Nikolaus!
>>>>>> 
>>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>>> Hi Dmitry,
>>>>>>> 
>>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>>>> entire touch surface and set resolution from it so that
>>>>>>>> userspace can calculate the proper scaling factor.
>>>>>>> 
>>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>>> scanning the DT file or tree?
>>>>>> 
>>>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>>>> have all needed information here. This is generic input interface,
>>>>>> no DT is needed.
>>>>> 
>>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>>> resolution from userspace for specified input device.
>>>>> 
>>>>> So this could be potentially used for calibrating input device from
>>>>> userspace? (In case DT data will not fully match current HW)
>>>>> 
>>>>>> I hope that XServer is already using it for evdev devices...
>>>>>> 
>>>>>> For whole implementation look at evtest program. That should be good
>>>>>> starting point for your userspace implementation.
>>>>>> 
>>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>>> just invert input axes (when needed)
>>>> 
>>>> It is questionable why it should do that at all then.
>>> 
>>> Because the task of the kernel is to provide unified view of the
>>> hardware. Axis swapping and inversion is needed to that "up" is always
>>> "up" and "right" is always "right".
>> 
>> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).
> 
> Yes, you can make it work for your touchscreen as long as you know
> that it inverted somehow. How you gain this knowledge is the question.

I think by letting the user calibrate the touch (calib tools can detect
inversion and rotation by the tap gesture sequence). I got the impression
that this step is wanted anyways for getting maximum precision.

Or the user-space configuration for a specific device model knows that because
the developer has gained this knowledge once and predefined the rotation matrix
for e.g. X11 correctly. If he didn't e.g. for Replicant it is Replicant's bug...

So you do not need this knowledge passed to user-space at all. Hence my proposal
to get rid of touch inversion and flipping properties and code from the touch
screen drivers.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
>> Hi,
>> 
>> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>> 
>>>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>>> 
>>>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>>>> Hi Nikolaus!
>>>>>> 
>>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>>> Hi Dmitry,
>>>>>>> 
>>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>>>>>>>> entire touch surface and set resolution from it so that
>>>>>>>> userspace can calculate the proper scaling factor.
>>>>>>> 
>>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>>> scanning the DT file or tree?
>>>>>> 
>>>>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>>>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>>>> have all needed information here. This is generic input interface,
>>>>>> no DT is needed.
>>>>> 
>>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>>> resolution from userspace for specified input device.
>>>>> 
>>>>> So this could be potentially used for calibrating input device from
>>>>> userspace? (In case DT data will not fully match current HW)
>>>>> 
>>>>>> I hope that XServer is already using it for evdev devices...
>>>>>> 
>>>>>> For whole implementation look at evtest program. That should be good
>>>>>> starting point for your userspace implementation.
>>>>>> 
>>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>>> just invert input axes (when needed)
>>>> 
>>>> It is questionable why it should do that at all then.
>>> 
>>> Because the task of the kernel is to provide unified view of the
>>> hardware. Axis swapping and inversion is needed to that "up" is always
>>> "up" and "right" is always "right".
>> 
>> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).
> 
> Yes, you can make it work for your touchscreen as long as you know
> that it inverted somehow. How you gain this knowledge is the question.

I think by letting the user calibrate the touch (calib tools can detect
inversion and rotation by the tap gesture sequence). I got the impression
that this step is wanted anyways for getting maximum precision.

Or the user-space configuration for a specific device model knows that because
the developer has gained this knowledge once and predefined the rotation matrix
for e.g. X11 correctly. If he didn't e.g. for Replicant it is Replicant's bug...

So you do not need this knowledge passed to user-space at all. Hence my proposal
to get rid of touch inversion and flipping properties and code from the touch
screen drivers.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov =
<dmitry.torokhov@gmail.com>:
>=20
> On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
>> Hi,
>>=20
>> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller =
<hns@goldelico.com> wrote:
>>>>=20
>>>>> Am 20.02.2017 um 22:08 schrieb Pali Roh=C3=A1r =
<pali.rohar@gmail.com>:
>>>>>=20
>>>>> On Monday 20 February 2017 20:42:15 Pali Roh=C3=A1r wrote:
>>>>>> Hi Nikolaus!
>>>>>>=20
>>>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>>>>>> Hi Dmitry,
>>>>>>>=20
>>>>>>>> Input driver may set resolution for given axis in units per mm
>>>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>>>>>>> ABS_RZ), and if you check the binding, you can use
>>>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size =
of
>>>>>>>> entire touch surface and set resolution from it so that
>>>>>>>> userspace can calculate the proper scaling factor.
>>>>>>>=20
>>>>>>> How is this information exposed by the kernel to user-space? By
>>>>>>> scanning the DT file or tree?
>>>>>>=20
>>>>>> Set input_abs_set_res() from kernel. And in userspace call =
EVIOCGABS
>>>>>> ioctl() on input device. Look at struct input_absinfo, you should
>>>>>> have all needed information here. This is generic input =
interface,
>>>>>> no DT is needed.
>>>>>=20
>>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>>> resolution from userspace for specified input device.
>>>>>=20
>>>>> So this could be potentially used for calibrating input device =
from
>>>>> userspace? (In case DT data will not fully match current HW)
>>>>>=20
>>>>>> I hope that XServer is already using it for evdev devices...
>>>>>>=20
>>>>>> For whole implementation look at evtest program. That should be =
good
>>>>>> starting point for your userspace implementation.
>>>>>>=20
>>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>>> just invert input axes (when needed)
>>>>=20
>>>> It is questionable why it should do that at all then.
>>>=20
>>> Because the task of the kernel is to provide unified view of the
>>> hardware. Axis swapping and inversion is needed to that "up" is =
always
>>> "up" and "right" is always "right".
>>=20
>> Actually my Xorg calibration 3x3 matrix is fine with both axis =
inverted (on TSC2046).
>=20
> Yes, you can make it work for your touchscreen as long as you know
> that it inverted somehow. How you gain this knowledge is the question.

I think by letting the user calibrate the touch (calib tools can detect
inversion and rotation by the tap gesture sequence). I got the =
impression
that this step is wanted anyways for getting maximum precision.

Or the user-space configuration for a specific device model knows that =
because
the developer has gained this knowledge once and predefined the rotation =
matrix
for e.g. X11 correctly. If he didn't e.g. for Replicant it is =
Replicant's bug...

So you do not need this knowledge passed to user-space at all. Hence my =
proposal
to get rid of touch inversion and flipping properties and code from the =
touch
screen drivers.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm (or
>>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
>>> if you check the binding, you can use "touchscreen-x-mm" and
>>> "touchscreen-y-mm" to specify the size of entire touch surface and
>>> set resolution from it so that userspace can calculate the proper
>>> scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel.

I can't find this function defined anywhere but used in 101 LOC.
LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res

What is going on here?

> And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should have
> all needed information here. This is generic input interface, no DT is
> needed.

Ok, if this is not set by a driver it is indeed a driver bug.

But we have to define it's value in DT because the tsc2007 does not know
anything about the panel dimensions.

IMHO something that should be done by generic of_touchscreen.c

If of_touchscreen would simply pass the touchscreen-size parameters
to input_abs_set_res() and the bindings would define it to be units/mm
it might have saved us all a lot of work and discussion.

> 
> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> While I'm watching this discussion... in my opinion kernel should just
> invert input axes (when needed) and should not do any other
> normalization or integer/floating-point re-calibration/re-calculation.
> If it correctly exports minimum value, maximum value and resolution then
> userspace can correctly re-scale input events to units which userspace
> needs (e.g. mapping into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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

Hi Pali,

> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm (or
>>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
>>> if you check the binding, you can use "touchscreen-x-mm" and
>>> "touchscreen-y-mm" to specify the size of entire touch surface and
>>> set resolution from it so that userspace can calculate the proper
>>> scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel.

I can't find this function defined anywhere but used in 101 LOC.
LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res

What is going on here?

> And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should have
> all needed information here. This is generic input interface, no DT is
> needed.

Ok, if this is not set by a driver it is indeed a driver bug.

But we have to define it's value in DT because the tsc2007 does not know
anything about the panel dimensions.

IMHO something that should be done by generic of_touchscreen.c

If of_touchscreen would simply pass the touchscreen-size parameters
to input_abs_set_res() and the bindings would define it to be units/mm
it might have saved us all a lot of work and discussion.

> 
> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> While I'm watching this discussion... in my opinion kernel should just
> invert input axes (when needed) and should not do any other
> normalization or integer/floating-point re-calibration/re-calculation.
> If it correctly exports minimum value, maximum value and resolution then
> userspace can correctly re-scale input events to units which userspace
> needs (e.g. mapping into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Petr and all,

> Am 20.02.2017 um 23:26 schrieb Petr Cvek <petr.cvek@tul.cz>:
> 
> Hi
> 
> Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a):
>> Hi Pavel,
>> 
>>> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> hi!
>>> 
>>>>>> But as said I don't think we need float or fixed point for practical systems
>>>>>> at all.
>>>>> 
>>>>> So you are going to loose precision. And if userspace decides to
>>>>> calibrate it slightly differently from kernel, lost precision will
>>>>> matter.
>>>> 
>>>> Really?
>>> 
>>> Really.
>>> 
>>>> Example:
>>>> 
>>>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
>>>> 
>>>> This is scaled to let's say 0..640.
>>> 
>>> Ok. Now userspace realizes that kernel alignemnt is off, and it would
>>> want to scale it to 1..642.
>> 
>> Screen coordinates are still 0..639.
>> 
>>> That will mean that single pixel will be
>>> inaccessible, right?
>> 
>> Yes, that can happen if the additional user-space scale is > 1.0.
>> 
>> As long as it is small (I expect <1.01 = 1% error in scale) it is
>> barely noticeable.
>> 
>> Therefore, I asked before: how big in pixels is your finger or stylus?
>> Does this effect matter?
>> 
>> A resistive touch is a man-machine-interface where people press buttons of at
>> least 12x12 pixels size (or they are no longer visually recognizable).
> 
> Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I would like
> to be able to select a single letter in the console.

So you probably have exceptionally good eyes and reading a terminal on a touch
screen is not a typical use case (except for us hard-core programmers).

Anyways, if there is only a single pixel is not accessible due do rescaling and integer
truncation effects (which is what Pavel complained) you can still select single letters
in a 4x6 font.

---

So, let's close commenting this patch here since in my opinion everything is said
and the maintainers have decided not to accept it.

I hope that I have not forgotten anyone to answer.

Thank you very much to all participants for this discussion, because it was
really enlightening to me and contains a lot of new perspectives.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Petr and all,

> Am 20.02.2017 um 23:26 schrieb Petr Cvek <petr.cvek-qphu/3gb4gc@public.gmane.org>:
> 
> Hi
> 
> Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a):
>> Hi Pavel,
>> 
>>> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
>>> 
>>> hi!
>>> 
>>>>>> But as said I don't think we need float or fixed point for practical systems
>>>>>> at all.
>>>>> 
>>>>> So you are going to loose precision. And if userspace decides to
>>>>> calibrate it slightly differently from kernel, lost precision will
>>>>> matter.
>>>> 
>>>> Really?
>>> 
>>> Really.
>>> 
>>>> Example:
>>>> 
>>>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in pre-calibration)
>>>> 
>>>> This is scaled to let's say 0..640.
>>> 
>>> Ok. Now userspace realizes that kernel alignemnt is off, and it would
>>> want to scale it to 1..642.
>> 
>> Screen coordinates are still 0..639.
>> 
>>> That will mean that single pixel will be
>>> inaccessible, right?
>> 
>> Yes, that can happen if the additional user-space scale is > 1.0.
>> 
>> As long as it is small (I expect <1.01 = 1% error in scale) it is
>> barely noticeable.
>> 
>> Therefore, I asked before: how big in pixels is your finger or stylus?
>> Does this effect matter?
>> 
>> A resistive touch is a man-machine-interface where people press buttons of at
>> least 12x12 pixels size (or they are no longer visually recognizable).
> 
> Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I would like
> to be able to select a single letter in the console.

So you probably have exceptionally good eyes and reading a terminal on a touch
screen is not a typical use case (except for us hard-core programmers).

Anyways, if there is only a single pixel is not accessible due do rescaling and integer
truncation effects (which is what Pavel complained) you can still select single letters
in a 4x6 font.

---

So, let's close commenting this patch here since in my opinion everything is said
and the maintainers have decided not to accept it.

I hope that I have not forgotten anyone to answer.

Thank you very much to all participants for this discussion, because it was
really enlightening to me and contains a lot of new perspectives.

BR and thanks,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Petr and all,

> Am 20.02.2017 um 23:26 schrieb Petr Cvek <petr.cvek@tul.cz>:
>=20
> Hi
>=20
> Dne 20.2.2017 v 17:50 H. Nikolaus Schaller napsal(a):
>> Hi Pavel,
>>=20
>>> Am 19.02.2017 um 23:19 schrieb Pavel Machek <pavel@ucw.cz>:
>>>=20
>>> hi!
>>>=20
>>>>>> But as said I don't think we need float or fixed point for =
practical systems
>>>>>> at all.
>>>>>=20
>>>>> So you are going to loose precision. And if userspace decides to
>>>>> calibrate it slightly differently from kernel, lost precision will
>>>>> matter.
>>>>=20
>>>> Really?
>>>=20
>>> Really.
>>>=20
>>>> Example:
>>>>=20
>>>> ADC values go 100 .. 3995 (i.e. touch margin is 100 steps in =
pre-calibration)
>>>>=20
>>>> This is scaled to let's say 0..640.
>>>=20
>>> Ok. Now userspace realizes that kernel alignemnt is off, and it =
would
>>> want to scale it to 1..642.
>>=20
>> Screen coordinates are still 0..639.
>>=20
>>> That will mean that single pixel will be
>>> inaccessible, right?
>>=20
>> Yes, that can happen if the additional user-space scale is > 1.0.
>>=20
>> As long as it is small (I expect <1.01 =3D 1% error in scale) it is
>> barely noticeable.
>>=20
>> Therefore, I asked before: how big in pixels is your finger or =
stylus?
>> Does this effect matter?
>>=20
>> A resistive touch is a man-machine-interface where people press =
buttons of at
>> least 12x12 pixels size (or they are no longer visually =
recognizable).
>=20
> Smallest kernel font is 4x6 (i think) and I'm regularly using 8x8. I =
would like
> to be able to select a single letter in the console.

So you probably have exceptionally good eyes and reading a terminal on a =
touch
screen is not a typical use case (except for us hard-core programmers).

Anyways, if there is only a single pixel is not accessible due do =
rescaling and integer
truncation effects (which is what Pavel complained) you can still select =
single letters
in a 4x6 font.

---

So, let's close commenting this patch here since in my opinion =
everything is said
and the maintainers have decided not to accept it.

I hope that I have not forgotten anyone to answer.

Thank you very much to all participants for this discussion, because it =
was
really enlightening to me and contains a lot of new perspectives.

BR and thanks,
Nikolaus=

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

Hi!

On Tuesday 21 February 2017 08:14:09 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > Hi Nikolaus!
> > 
> > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >> 
> >>> Input driver may set resolution for given axis in units per mm (or
> >>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
> >>> if you check the binding, you can use "touchscreen-x-mm" and
> >>> "touchscreen-y-mm" to specify the size of entire touch surface and
> >>> set resolution from it so that userspace can calculate the proper
> >>> scaling factor.
> >> 
> >> How is this information exposed by the kernel to user-space? By
> >> scanning the DT file or tree?
> > 
> > Set input_abs_set_res() from kernel.
> 
> I can't find this function defined anywhere but used in 101 LOC.
> LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res
> 
> What is going on here?

It is inline function defined by preprocessor. This should help you:

git grep INPUT_GENERATE_ABS_ACCESSORS
git grep input_abs_set_res

> > And in userspace call EVIOCGABS
> > ioctl() on input device. Look at struct input_absinfo, you should have
> > all needed information here. This is generic input interface, no DT is
> > needed.
> 
> Ok, if this is not set by a driver it is indeed a driver bug.

Zero value is special and means "driver does not know it". In case
driver really does not know it, then it is not a driver bug.

> But we have to define it's value in DT because the tsc2007 does not know
> anything about the panel dimensions.

Yes, driver itself does not know it and DT seems to be correct place.

> IMHO something that should be done by generic of_touchscreen.c

I agree. DT for specific hardware can pass these information into
touchscreen driver (which does not have to know these parameters) and it
exports it to userspace.

> If of_touchscreen would simply pass the touchscreen-size parameters
> to input_abs_set_res() and the bindings would define it to be units/mm
> it might have saved us all a lot of work and discussion.

Seem that nobody until now needed such thing and everybody is (probably)
using Xorg userspace with userspace calibration.

But it really make sense to set input_abs_set_res() from DT.

> > 
> > I hope that XServer is already using it for evdev devices...
> > 
> > For whole implementation look at evtest program. That should be good
> > starting point for your userspace implementation.
> > 
> > While I'm watching this discussion... in my opinion kernel should just
> > invert input axes (when needed) and should not do any other
> > normalization or integer/floating-point re-calibration/re-calculation.
> > If it correctly exports minimum value, maximum value and resolution then
> > userspace can correctly re-scale input events to units which userspace
> > needs (e.g. mapping into LCD screen pixels or whatever is needed).
> 
> BR and thanks,
> Nikolaus
> 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

Hi!

On Tuesday 21 February 2017 08:14:09 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > Hi Nikolaus!
> > 
> > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >> Hi Dmitry,
> >> 
> >>> Input driver may set resolution for given axis in units per mm (or
> >>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
> >>> if you check the binding, you can use "touchscreen-x-mm" and
> >>> "touchscreen-y-mm" to specify the size of entire touch surface and
> >>> set resolution from it so that userspace can calculate the proper
> >>> scaling factor.
> >> 
> >> How is this information exposed by the kernel to user-space? By
> >> scanning the DT file or tree?
> > 
> > Set input_abs_set_res() from kernel.
> 
> I can't find this function defined anywhere but used in 101 LOC.
> LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res
> 
> What is going on here?

It is inline function defined by preprocessor. This should help you:

git grep INPUT_GENERATE_ABS_ACCESSORS
git grep input_abs_set_res

> > And in userspace call EVIOCGABS
> > ioctl() on input device. Look at struct input_absinfo, you should have
> > all needed information here. This is generic input interface, no DT is
> > needed.
> 
> Ok, if this is not set by a driver it is indeed a driver bug.

Zero value is special and means "driver does not know it". In case
driver really does not know it, then it is not a driver bug.

> But we have to define it's value in DT because the tsc2007 does not know
> anything about the panel dimensions.

Yes, driver itself does not know it and DT seems to be correct place.

> IMHO something that should be done by generic of_touchscreen.c

I agree. DT for specific hardware can pass these information into
touchscreen driver (which does not have to know these parameters) and it
exports it to userspace.

> If of_touchscreen would simply pass the touchscreen-size parameters
> to input_abs_set_res() and the bindings would define it to be units/mm
> it might have saved us all a lot of work and discussion.

Seem that nobody until now needed such thing and everybody is (probably)
using Xorg userspace with userspace calibration.

But it really make sense to set input_abs_set_res() from DT.

> > 
> > I hope that XServer is already using it for evdev devices...
> > 
> > For whole implementation look at evtest program. That should be good
> > starting point for your userspace implementation.
> > 
> > While I'm watching this discussion... in my opinion kernel should just
> > invert input axes (when needed) and should not do any other
> > normalization or integer/floating-point re-calibration/re-calculation.
> > If it correctly exports minimum value, maximum value and resolution then
> > userspace can correctly re-scale input events to units which userspace
> > needs (e.g. mapping into LCD screen pixels or whatever is needed).
> 
> BR and thanks,
> Nikolaus
> 

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

On Tuesday 21 February 2017 07:42:17 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
> >> Hi Pali,
> >> 
> >>> Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
> >>>> Hi Pali,
> >>>> 
> >>>>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>>>> 
> >>>>> Hi Nikolaus!
> >>>>> 
> >>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>>> Hi Dmitry,
> >>>>>> 
> >>>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>>>> of entire touch surface and set resolution from it so that
> >>>>>>> userspace can calculate the proper scaling factor.
> >>>>>> 
> >>>>>> How is this information exposed by the kernel to user-space? By
> >>>>>> scanning the DT file or tree?
> >>>>> 
> >>>>> Set input_abs_set_res() from kernel. And in userspace call
> >>>>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> >>>>> you should have all needed information here. This is generic
> >>>>> input interface, no DT is needed.
> >>>> 
> >>>> This assumes that I can and want to write a graphics system
> >>>> myself.
> >>> 
> >>> Not only. There are already existing graphics systems. And you need
> >>> to provide needed information from kernel, so they can start using
> >>> it.
> >>> 
> >>> So input_abs_set_res() is needed to use in your kernel driver.
> >> 
> >> I didn't know about this feature and obviously nobody else has
> >> implemented it in the tsc2007 driver.
> > 
> > So... before doing other things, can you deeply look at it and check if
> > it really fixes this problem? Because I think that yes.
> > 
> > You can probably set it from DT and in your DT file you can have stored
> > screen size (or resolution factor).
> > 
> > Also for testing, you can set it even via userspace (ioctl which I wrote
> > in previous email).
> 
> Interesting thing. It does not seem to be well known because nobody else
> brought it up during several months of lenghty discussions.
> 
> I have seen it is in use for scaling topics, e.g. https://lkml.org/lkml/2015/7/9/749

E.g. my touchpad (ALPS) exports this information. It is not touchscreen
device, but still it is absolute positioned device. And looking into
kernel tree it is used by more input drivers...

> > 
> >>>> And if it does, it does it in a
> >>>> plethora of different implementation states. That is the reason
> >>>> why we want to solve it once for all userlands in the kernel and
> >>>> not rely on user-space help.
> >>> 
> >>> For me this looks like "we are going to fix userspace bugs in
> >>> kernel".
> >> 
> >> Such things are system bugs and it is neither necessarily a userspace
> >> or kernel bug.
> > 
> > In case kernel defines stable API/ABI and correctly provides information
> > via that API/ABI and application does not work correctly, then I would
> > say it is bug in application. Not in kernel.
> 
> So a kernel can simply add a new interface and declare bugs for userland?

That is something different. But yes it could be problematic if you
create userspace and immediately after that kernel define some API which
is against usage of your userspace. So something like this would depend
on situation.

But I hope right now it is clear. That resolution property is there for
a long time and new code (which is your case) should use it.

> > 
> > We can say that some kernel API/ABI is wrong too. And in this case it
> > could be bug in kernel.
> > 
> > So is current stable kernel API/ABI for input device wrong? I do not
> > thing.
> 
> Difficult to judge because there is scarce documentation of this.
> 
> > But if you think that yes, please show us what exactly and we can
> > start discussing how to fix such problem which you see/have. I know that
> > no application is without bugs, but in my opinion problem which you are
> > describing is already solved and defined by current stable kernel ABI.
> > 
> >>> Really! Not a good idea. Plus I still see this as abusing kernel
> >>> API/ABI as resolution should be handled differently as you are
> >>> proposing.
> >> 
> >> I don't understand what you say here. Where are we abusing kernel
> >> API/ABI?
> > 
> > I mean that we already have stable API/ABI how to export size of input
> > screen from kernel to userspace. And you want to rescale event data
> > directly in kernel to workaround problem of screen size. So I think this
> > is abusing API/ABI as kernel already have API for it.
> 
> BR and thanks,
> Nikolaus
> 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

On Tuesday 21 February 2017 07:42:17 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
> >> Hi Pali,
> >> 
> >>> Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>> 
> >>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
> >>>> Hi Pali,
> >>>> 
> >>>>> Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>>>> 
> >>>>> Hi Nikolaus!
> >>>>> 
> >>>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>>> Hi Dmitry,
> >>>>>> 
> >>>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>>>> of entire touch surface and set resolution from it so that
> >>>>>>> userspace can calculate the proper scaling factor.
> >>>>>> 
> >>>>>> How is this information exposed by the kernel to user-space? By
> >>>>>> scanning the DT file or tree?
> >>>>> 
> >>>>> Set input_abs_set_res() from kernel. And in userspace call
> >>>>> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> >>>>> you should have all needed information here. This is generic
> >>>>> input interface, no DT is needed.
> >>>> 
> >>>> This assumes that I can and want to write a graphics system
> >>>> myself.
> >>> 
> >>> Not only. There are already existing graphics systems. And you need
> >>> to provide needed information from kernel, so they can start using
> >>> it.
> >>> 
> >>> So input_abs_set_res() is needed to use in your kernel driver.
> >> 
> >> I didn't know about this feature and obviously nobody else has
> >> implemented it in the tsc2007 driver.
> > 
> > So... before doing other things, can you deeply look at it and check if
> > it really fixes this problem? Because I think that yes.
> > 
> > You can probably set it from DT and in your DT file you can have stored
> > screen size (or resolution factor).
> > 
> > Also for testing, you can set it even via userspace (ioctl which I wrote
> > in previous email).
> 
> Interesting thing. It does not seem to be well known because nobody else
> brought it up during several months of lenghty discussions.
> 
> I have seen it is in use for scaling topics, e.g. https://lkml.org/lkml/2015/7/9/749

E.g. my touchpad (ALPS) exports this information. It is not touchscreen
device, but still it is absolute positioned device. And looking into
kernel tree it is used by more input drivers...

> > 
> >>>> And if it does, it does it in a
> >>>> plethora of different implementation states. That is the reason
> >>>> why we want to solve it once for all userlands in the kernel and
> >>>> not rely on user-space help.
> >>> 
> >>> For me this looks like "we are going to fix userspace bugs in
> >>> kernel".
> >> 
> >> Such things are system bugs and it is neither necessarily a userspace
> >> or kernel bug.
> > 
> > In case kernel defines stable API/ABI and correctly provides information
> > via that API/ABI and application does not work correctly, then I would
> > say it is bug in application. Not in kernel.
> 
> So a kernel can simply add a new interface and declare bugs for userland?

That is something different. But yes it could be problematic if you
create userspace and immediately after that kernel define some API which
is against usage of your userspace. So something like this would depend
on situation.

But I hope right now it is clear. That resolution property is there for
a long time and new code (which is your case) should use it.

> > 
> > We can say that some kernel API/ABI is wrong too. And in this case it
> > could be bug in kernel.
> > 
> > So is current stable kernel API/ABI for input device wrong? I do not
> > thing.
> 
> Difficult to judge because there is scarce documentation of this.
> 
> > But if you think that yes, please show us what exactly and we can
> > start discussing how to fix such problem which you see/have. I know that
> > no application is without bugs, but in my opinion problem which you are
> > describing is already solved and defined by current stable kernel ABI.
> > 
> >>> Really! Not a good idea. Plus I still see this as abusing kernel
> >>> API/ABI as resolution should be handled differently as you are
> >>> proposing.
> >> 
> >> I don't understand what you say here. Where are we abusing kernel
> >> API/ABI?
> > 
> > I mean that we already have stable API/ABI how to export size of input
> > screen from kernel to userspace. And you want to rescale event data
> > directly in kernel to workaround problem of screen size. So I think this
> > is abusing API/ABI as kernel already have API for it.
> 
> BR and thanks,
> Nikolaus
> 

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Christ van Willegen]

Hi all,

On Tue, Feb 21, 2017 at 9:47 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> But it really make sense to set input_abs_set_res() from DT.

And _not_ add the 1 or two lines of code that checks some DT variable,
and then fixes _everybody's_ userland?

That means those lines of code need to go into _every_ userland, which
makes maintenance sooo much harder. And the kernel knows about this
and doesn't care??

Weird...

Christ van Willegen

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Christ van Willegen]

Hi all,

On Tue, Feb 21, 2017 at 9:47 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> But it really make sense to set input_abs_set_res() from DT.

And _not_ add the 1 or two lines of code that checks some DT variable,
and then fixes _everybody's_ userland?

That means those lines of code need to go into _every_ userland, which
makes maintenance sooo much harder. And the kernel knows about this
and doesn't care??

Weird...

Christ van Willegen

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Christ van Willegen]

Hi all,

On Tue, Feb 21, 2017 at 9:47 AM, Pali Roh=C3=A1r <pali.rohar@gmail.com> wro=
te:
> But it really make sense to set input_abs_set_res() from DT.

And _not_ add the 1 or two lines of code that checks some DT variable,
and then fixes _everybody's_ userland?

That means those lines of code need to go into _every_ userland, which
makes maintenance sooo much harder. And the kernel knows about this
and doesn't care??

Weird...

Christ van Willegen

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

On Tuesday 21 February 2017 07:36:17 H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >> 
> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >>>> Hi Nikolaus!
> >>>> 
> >>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>> Hi Dmitry,
> >>>>> 
> >>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
> >>>>>> entire touch surface and set resolution from it so that
> >>>>>> userspace can calculate the proper scaling factor.
> >>>>> 
> >>>>> How is this information exposed by the kernel to user-space? By
> >>>>> scanning the DT file or tree?
> >>>> 
> >>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
> >>>> ioctl() on input device. Look at struct input_absinfo, you should
> >>>> have all needed information here. This is generic input interface,
> >>>> no DT is needed.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device from
> >>> userspace? (In case DT data will not fully match current HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be good
> >>>> starting point for your userspace implementation.
> >>>> 
> >>>> While I'm watching this discussion... in my opinion kernel should
> >>>> just invert input axes (when needed)
> >> 
> >> It is questionable why it should do that at all then.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is always
> > "up" and "right" is always "right".
> 
> Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
> screen and touching pixel (639,479) is always (639,479)?

Important is that there is no 1:1 mapping between input evdev device and
drm/fb output device. These are two independent devices. There is no
connection between screen and touch. So such presumption should not be
done in kernel. You can do that in userspace.

Lets take e.g. touchpad. It acts similarly as touchscreen input device
(both reports absolute positioned touch events), but touchpad is not
connected with screen. And from kernel point of view these devices are
both input and absolute positioned.

It looks like the whole problem is there that you wanted to do this
mapping for your hardware in kernel. And this is not what is kernel
doing or should do. Moreover I know people who are using integrated
touchscreen on laptop as (touch) input device for external monitor. And
in this configuration it does not make any sense to map touchscreen
input to pixels of integrated LCD touchscreen (as external monitor could
have different resolution as integrated LCD touchcreen).

> I think it is time to end this discussion.
> 
> It has show me how much a mess and half-baked area this is, which I did
> not expect. I read contradicting messages from different people:
> 
> * don't break user space because it is carved in stone
> * fix users space if you want to do it properly
> * scaling by +/-1 and shifting by full range is ok
> * scaling by ts-size/adc-range and shifting by adc_min is not ok
> * full numeric ADC resolution is required but subpixel coordinates is not acceptable
> 
> I will monitor this to see if this becomes sorted out before submitting anything
> new.
> 
> BR and thanks,
> Nikolaus

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pali Rohár]

On Tuesday 21 February 2017 07:36:17 H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
> >> 
> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> >>> 
> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >>>> Hi Nikolaus!
> >>>> 
> >>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>> Hi Dmitry,
> >>>>> 
> >>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
> >>>>>> entire touch surface and set resolution from it so that
> >>>>>> userspace can calculate the proper scaling factor.
> >>>>> 
> >>>>> How is this information exposed by the kernel to user-space? By
> >>>>> scanning the DT file or tree?
> >>>> 
> >>>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
> >>>> ioctl() on input device. Look at struct input_absinfo, you should
> >>>> have all needed information here. This is generic input interface,
> >>>> no DT is needed.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device from
> >>> userspace? (In case DT data will not fully match current HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be good
> >>>> starting point for your userspace implementation.
> >>>> 
> >>>> While I'm watching this discussion... in my opinion kernel should
> >>>> just invert input axes (when needed)
> >> 
> >> It is questionable why it should do that at all then.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is always
> > "up" and "right" is always "right".
> 
> Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
> screen and touching pixel (639,479) is always (639,479)?

Important is that there is no 1:1 mapping between input evdev device and
drm/fb output device. These are two independent devices. There is no
connection between screen and touch. So such presumption should not be
done in kernel. You can do that in userspace.

Lets take e.g. touchpad. It acts similarly as touchscreen input device
(both reports absolute positioned touch events), but touchpad is not
connected with screen. And from kernel point of view these devices are
both input and absolute positioned.

It looks like the whole problem is there that you wanted to do this
mapping for your hardware in kernel. And this is not what is kernel
doing or should do. Moreover I know people who are using integrated
touchscreen on laptop as (touch) input device for external monitor. And
in this configuration it does not make any sense to map touchscreen
input to pixels of integrated LCD touchscreen (as external monitor could
have different resolution as integrated LCD touchcreen).

> I think it is time to end this discussion.
> 
> It has show me how much a mess and half-baked area this is, which I did
> not expect. I read contradicting messages from different people:
> 
> * don't break user space because it is carved in stone
> * fix users space if you want to do it properly
> * scaling by +/-1 and shifting by full range is ok
> * scaling by ts-size/adc-range and shifting by adc_min is not ok
> * full numeric ADC resolution is required but subpixel coordinates is not acceptable
> 
> I will monitor this to see if this becomes sorted out before submitting anything
> new.
> 
> BR and thanks,
> Nikolaus

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > They are "pixels" or the touch controller, i.e. native unites in which
> > device reports coordinates, as opposed to points per inch, or
> > millimeters, or whatever. These "pixels" do not have to have 1:1
> > relation to the LCD pixels; in fact they rarely do.
> 
> I wouldn't call this "pixels". Rather "ADC steps" or something.

Submit a patch.

> > Why? Nothing stops you from querying the device and figure out scaling.
> 
> What stops me is that I have no (and do not want to have) that level of control over
> user-space code.

Umm. Then perhaps you should not be submitting kernel patches.

> > And still, according to DT folks, device tree forms an ABI and thus we
> > are not to change it, even if it is easy.
> 
> I think this needs a more differentiated view.
> 
> In my view the names of the binding properties and what they influence form indeed
> an ABI. It should be stable and interpreted in the same way.
> 
> But it allows to load different firmware for different requirements. Like the user
> application ABI is stable but you can still load different software.

No. You can't expect people to konfigure kernel by modifying dts.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

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

Hi!

> > They are "pixels" or the touch controller, i.e. native unites in which
> > device reports coordinates, as opposed to points per inch, or
> > millimeters, or whatever. These "pixels" do not have to have 1:1
> > relation to the LCD pixels; in fact they rarely do.
> 
> I wouldn't call this "pixels". Rather "ADC steps" or something.

Submit a patch.

> > Why? Nothing stops you from querying the device and figure out scaling.
> 
> What stops me is that I have no (and do not want to have) that level of control over
> user-space code.

Umm. Then perhaps you should not be submitting kernel patches.

> > And still, according to DT folks, device tree forms an ABI and thus we
> > are not to change it, even if it is easy.
> 
> I think this needs a more differentiated view.
> 
> In my view the names of the binding properties and what they influence form indeed
> an ABI. It should be stable and interpreted in the same way.
> 
> But it allows to load different firmware for different requirements. Like the user
> application ABI is stable but you can still load different software.

No. You can't expect people to konfigure kernel by modifying dts.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Andreas Kemnade]

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

Hi,

[...]
> > Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0)
> > on the screen and touching pixel (639,479) is always (639,479)?
> 
> Important is that there is no 1:1 mapping between input evdev device
> and drm/fb output device. These are two independent devices. There is
> no connection between screen and touch. So such presumption should
> not be done in kernel. You can do that in userspace.
> 
But at least it can be told to userspace that these two devices are
connected. That information should be specified in devicetree because
it is not auto-detectable.

> Lets take e.g. touchpad. It acts similarly as touchscreen input device
> (both reports absolute positioned touch events), but touchpad is not
> connected with screen. And from kernel point of view these devices are
> both input and absolute positioned.
> 
> It looks like the whole problem is there that you wanted to do this
> mapping for your hardware in kernel. And this is not what is kernel
> doing or should do. Moreover I know people who are using integrated
> touchscreen on laptop as (touch) input device for external monitor.
> And in this configuration it does not make any sense to map
> touchscreen input to pixels of integrated LCD touchscreen (as
> external monitor could have different resolution as integrated LCD
> touchcreen).
>   
Interesting example. But then you also do not need flipping/rotation
because the angle between your screen and your absolute position device
is not fixed.

Regards,
Andreas

>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Andreas Kemnade]

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

Hi,

[...]
> > Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0)
> > on the screen and touching pixel (639,479) is always (639,479)?
> 
> Important is that there is no 1:1 mapping between input evdev device
> and drm/fb output device. These are two independent devices. There is
> no connection between screen and touch. So such presumption should
> not be done in kernel. You can do that in userspace.
> 
But at least it can be told to userspace that these two devices are
connected. That information should be specified in devicetree because
it is not auto-detectable.

> Lets take e.g. touchpad. It acts similarly as touchscreen input device
> (both reports absolute positioned touch events), but touchpad is not
> connected with screen. And from kernel point of view these devices are
> both input and absolute positioned.
> 
> It looks like the whole problem is there that you wanted to do this
> mapping for your hardware in kernel. And this is not what is kernel
> doing or should do. Moreover I know people who are using integrated
> touchscreen on laptop as (touch) input device for external monitor.
> And in this configuration it does not make any sense to map
> touchscreen input to pixels of integrated LCD touchscreen (as
> external monitor could have different resolution as integrated LCD
> touchcreen).
>   
Interesting example. But then you also do not need flipping/rotation
because the angle between your screen and your absolute position device
is not fixed.

Regards,
Andreas

>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v9 5/8] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory

[H. Nikolaus Schaller]

Hi Dmitry,
this patch from the series seems to have been lost in the other discussions.
It is just moving a bindings document to where it should be.
I don't know if it should go through your git.
BR and thanks,
Nikolaus

> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (100%)
> 
> diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/input/ads7846.txt
> rename to Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> -- 
> 2.7.3
> 

Re: [PATCH v9 5/8] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory

[H. Nikolaus Schaller]

Hi Dmitry,
this patch from the series seems to have been lost in the other discussions.
It is just moving a bindings document to where it should be.
I don't know if it should go through your git.
BR and thanks,
Nikolaus

> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (100%)
> 
> diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/input/ads7846.txt
> rename to Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> -- 
> 2.7.3
> 

Re: [PATCH v9 5/8] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory

[H. Nikolaus Schaller]

Hi Dmitry,
this patch from the series seems to have been lost in the other =
discussions.
It is just moving a bindings document to where it should be.
I don't know if it should go through your git.
BR and thanks,
Nikolaus

> Am 28.12.2016 um 15:53 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>=20
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/input/{ =3D> =
touchscreen}/ads7846.txt | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/input/{ =3D> =
touchscreen}/ads7846.txt (100%)
>=20
> diff --git a/Documentation/devicetree/bindings/input/ads7846.txt =
b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/input/ads7846.txt
> rename to =
Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> --=20
> 2.7.3
>=20