[PATCH] Input: pixcir_i2c_ts: remove wakeirq related code from pixcir driver

2015-10-13 Thread Vignesh R
With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
interrupt in device tree") wakeirq is managed by i2c-core, so remove
wakeirq related code from pixcir_i2c_ts driver.

Signed-off-by: Vignesh R 
---
 drivers/input/touchscreen/pixcir_i2c_ts.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c 
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 91621725bfb5..4b961ad9f0b5 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -377,8 +377,6 @@ static int __maybe_unused pixcir_i2c_ts_suspend(struct 
device *dev)
goto unlock;
}
}
-
-   enable_irq_wake(client->irq);
} else if (input->users) {
ret = pixcir_stop(ts);
}
@@ -399,7 +397,6 @@ static int __maybe_unused pixcir_i2c_ts_resume(struct 
device *dev)
mutex_lock(>mutex);
 
if (device_may_wakeup(>dev)) {
-   disable_irq_wake(client->irq);
 
if (!input->users) {
ret = pixcir_stop(ts);
@@ -564,14 +561,6 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
return error;
 
i2c_set_clientdata(client, tsdata);
-   device_init_wakeup(>dev, 1);
-
-   return 0;
-}
-
-static int pixcir_i2c_ts_remove(struct i2c_client *client)
-{
-   device_init_wakeup(>dev, 0);
 
return 0;
 }
@@ -609,7 +598,6 @@ static struct i2c_driver pixcir_i2c_ts_driver = {
.of_match_table = of_match_ptr(pixcir_of_match),
},
.probe  = pixcir_i2c_ts_probe,
-   .remove = pixcir_i2c_ts_remove,
.id_table   = pixcir_i2c_ts_id,
 };
 
-- 
2.6.1

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


RE: [PATCH RFC V2 1/3] Input: goodix - add dt axis swapping and axis inversion support

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: linux-input-ow...@vger.kernel.org 
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Karsten Merker
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin; 
> linux-input@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; Chen-Yu Tsai; 
> Karsten Merker
> Subject: [PATCH RFC V2 1/3] Input: goodix - add dt axis swapping and axis 
> inversion support
> 
> Implement support for the following device-tree properties
> in the goodix touchscreen driver:
> 
>  - touchscreen-inverted-x:  X axis is inverted (boolean)
>  - touchscreen-inverted-y:  Y axis is inverted (boolean)
>  - touchscreen-swapped-x-y: X and Y axis are swapped (boolean)
> 
> These are necessary on tablets which have a display in portrait
> format while the touchscreen is in landscape format, such as e.g.
> the MSI Primo 81.
> 
> Signed-off-by: Karsten Merker 
> ---
>  drivers/input/touchscreen/goodix.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/input/touchscreen/goodix.c 
> b/drivers/input/touchscreen/goodix.c
> index 22bfc4b..a05bdad 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -2,6 +2,7 @@
>   *  Driver for Goodix Touchscreens
>   *
>   *  Copyright (c) 2014 Red Hat Inc.
> + *  Copyright (c) 2015 K. Merker 
>   *
>   *  This code is based on gt9xx.c authored by and...@goodix.com:
>   *
> @@ -53,6 +54,9 @@ struct goodix_ts_data {
>   atomic_t open_count;
>   /* Protects power management calls and access to suspended flag */
>   struct mutex mutex;
> + bool swapped_x_y;
> + bool inverted_x;
> + bool inverted_y;
>  };
> 
>  #define GOODIX_GPIO_INT_NAME "irq"
> @@ -271,6 +275,14 @@ static void goodix_ts_report_touch(struct goodix_ts_data 
> *ts, u8 *coor_data)
>   input_y = ts->abs_y_max - input_y;
>   }
> 
> + /* Inversions have to happen before axis swapping */
> + if (ts->inverted_x)
> + input_x = ts->abs_x_max - input_x;
> + if (ts->inverted_y)
> + input_y = ts->abs_y_max - input_y;
> + if (ts->swapped_x_y)
> + swap(input_x, input_y);
> +
>   input_mt_slot(ts->input_dev, id);
>   input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER, true);
>   input_report_abs(ts->input_dev, ABS_MT_POSITION_X, input_x);
> @@ -666,6 +678,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>error);
>   ts->abs_x_max = GOODIX_MAX_WIDTH;
>   ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
>   ts->int_trigger_type = GOODIX_INT_TRIGGER;
>   ts->max_touch_num = GOODIX_MAX_CONTACTS;
>   return;
> @@ -673,6 +687,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
> 
>   ts->abs_x_max = get_unaligned_le16([RESOLUTION_LOC]);
>   ts->abs_y_max = get_unaligned_le16([RESOLUTION_LOC + 2]);
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
>   ts->int_trigger_type = config[TRIGGER_LOC] & 0x03;
>   ts->max_touch_num = config[MAX_CONTACTS_LOC] & 0x0f;
>   if (!ts->abs_x_max || !ts->abs_y_max || !ts->max_touch_num) {
> @@ -680,6 +696,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>   "Invalid config, using defaults\n");
>   ts->abs_x_max = GOODIX_MAX_WIDTH;
>   ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
>   ts->max_touch_num = GOODIX_MAX_CONTACTS;
>   }
> 
> @@ -950,6 +968,15 @@ static int goodix_ts_probe(struct i2c_client *client,
>   return 0;
>   }
> 
> +#ifdef CONFIG_OF
> + ts->swapped_x_y = of_property_read_bool(client->dev.of_node,
> + "touchscreen-swapped-x-y");
> + ts->inverted_x = of_property_read_bool(client->dev.of_node,
> +"touchscreen-inverted-x");
> + ts->inverted_y = of_property_read_bool(client->dev.of_node,
> +"touchscreen-inverted-y");
> +#endif
> +

If interrupt and reset gpio pins are declared in the DT configuration, this 
code will not
be executed.  To make the properties available for all configurations 
(with/without
gpio pins declared), you should read the properties inside 
goodix_configure_dev().

You could also use device_property_read_bool() instead, so that these 
properties can
be used with ACPI 5.1. as well.

Thanks,
Irina

>   return goodix_configure_dev(ts);
> 
>  err_free_cfg_name:
> --
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message 

[PATCH] Add support for SiS i2c touch driver

2015-10-13 Thread Ko-Hao, Yu
Hi, This patch is to add support for SiS i2c touch panel.
Thanks a lot.

Signed-off-by: Ko-Hao, Yu 
---
 drivers/input/touchscreen/Kconfig   |  11 +
 drivers/input/touchscreen/Makefile  |   1 +
 drivers/input/touchscreen/sis_i2c.c | 525 
 3 files changed, 537 insertions(+)
 create mode 100644 drivers/input/touchscreen/sis_i2c.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 600dcce..5782dd5 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1064,4 +1064,15 @@ config TOUCHSCREEN_COLIBRI_VF50
  To compile this driver as a module, choose M here: the
  module will be called colibri_vf50_ts.
 
+config TOUCHSCREEN_SIS_I2C
+   tristate "SiS 9200 family I2C touchscreen driver"
+   depends on I2C && CRC_ITU_T
+   help
+ Say Y here to enable support for I2C connected SiS touch panels.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sis_i2c.
+
 endif
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 1b79cc0..360b577 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -87,3 +87,4 @@ obj-$(CONFIG_TOUCHSCREEN_SX8654)  += sx8654.o
 obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
 obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
 obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
+obj-$(CONFIG_TOUCHSCREEN_SIS_I2C)   += sis_i2c.o
diff --git a/drivers/input/touchscreen/sis_i2c.c 
b/drivers/input/touchscreen/sis_i2c.c
new file mode 100644
index 000..f7b6ac5
--- /dev/null
+++ b/drivers/input/touchscreen/sis_i2c.c
@@ -0,0 +1,525 @@
+/*
+ * Touch Screen driver for SiS 9200 family I2C Touch panels
+ *
+ * Copyright (C) 2015 SiS, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include /*For Type-B Slot function*/
+#include/*For CRC Check*/
+
+#define SIS_I2C_NAME   "sis_i2c_ts"
+#define SIS_SLAVE_ADDR 0x5c
+#define MAX_FINGERS10
+
+/*Resolution mode*/
+/*Constant value*/
+#define SIS_MAX_X  4095
+#define SIS_MAX_Y  4095
+
+#define PACKET_BUFFER_SIZE 128
+
+#define SIS_CMD_NORMAL 0x0
+
+/* for new i2c format */
+#define TOUCHDOWN  0x3
+#define TOUCHUP0x0
+#define MAX_BYTE   64
+#define PRESSURE_MAX   255
+
+/*Resolution diagonal */
+#define AREA_LENGTH_LONGER 5792
+/*((SIS_MAX_X^2) + (SIS_MAX_Y^2))^0.5*/
+#define AREA_LENGTH_SHORT  5792
+#define AREA_UNIT  (5792/32)
+
+#define P_BYTECOUNT0
+#define ALL_IN_ONE_PACKAGE 0x10
+#define IS_TOUCH(x)(x & 0x1)
+#define IS_HIDI2C(x)   ((x & 0xF) == 0x06)
+#define IS_AREA(x) ((x >> 4) & 0x1)
+#define IS_PRESSURE(x) ((x >> 5) & 0x1)
+#define IS_SCANTIME(x) ((x >> 6) & 0x1)
+#define NORMAL_LEN_PER_POINT   6
+#define AREA_LEN_PER_POINT 2
+#define PRESSURE_LEN_PER_POINT 1
+
+#define TOUCH_FORMAT   0x1
+#define HIDI2C_FORMAT  0x6
+#define P_REPORT_ID2
+#define BYTE_BYTECOUNT 2
+#define BYTE_ReportID  1
+#define BYTE_CRC_HIDI2C0
+#define BYTE_CRC_I2C   2
+#define BYTE_SCANTIME  2
+
+#define MAX_SLOTS  15
+
+struct sis_slot {
+   int check_id;
+   int id;
+   unsigned short x, y;
+   u16 pressure;
+   u16 width;
+   u16 height;

Re: [PATCH v9 2/9] Input: goodix - reset device at init

2015-10-13 Thread Dmitry Torokhov
On Tue, Oct 13, 2015 at 06:38:23AM +, Tirdea, Irina wrote:
> 
> 
> > -Original Message-
> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > Sent: 12 October, 2015 19:48
> > To: Tirdea, Irina
> > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> > linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> > 
> > On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > > After power on, it is recommended that the driver resets the device.
> > > The reset procedure timing is described in the datasheet and is used
> > > at device init (before writing device configuration) and
> > > for power management. It is a sequence of setting the interrupt
> > > and reset pins high/low at specific timing intervals. This procedure
> > > also includes setting the slave address to the one specified in the
> > > ACPI/device tree.
> > >
> > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > driver gt9xx.c for Android (publicly available in Android kernel
> > > trees for various devices).
> > >
> > > For reset the driver needs to control the interrupt and
> > > reset gpio pins (configured through ACPI/device tree). For devices
> > > that do not have the gpio pins properly declared, the functionality
> > > depending on these pins will not be available, but the device can still
> > > be used with basic functionality.
> > >
> > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > read from the "irq-gpio" property and the reset pin configuration is
> > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > can be specified using the _DSD section. This functionality will not be
> > > available for devices that use indexed gpio pins declared in the _CRS
> > > section (we need to provide backward compatibility with devices
> > > that do not support using the interrupt gpio pin as output).
> > >
> > > For ACPI, the pins can be specified using ACPI 5.1:
> > > Device (STAC)
> > > {
> > > Name (_HID, "GDIX1001")
> > > ...
> > >
> > > Method (_CRS, 0, Serialized)
> > > {
> > > Name (RBUF, ResourceTemplate ()
> > > {
> > > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > > AddressingMode7Bit, "\\I2C0",
> > > 0x00, ResourceConsumer, ,
> > > )
> > >
> > > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > > "\\I2C0", 0x00, ResourceConsumer, ,
> > >  )
> > >  {   // Pin list
> > >  0
> > >  }
> > >
> > > GpioIo (Exclusive, PullDown, 0x, 0x,
> > > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > > ResourceConsumer, ,
> > > )
> > > {
> > >  1
> > > }
> > > })
> > > Return (RBUF)
> > > }
> > >
> > > Name (_DSD,  Package ()
> > > {
> > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > Package ()
> > > {
> > > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > > ...
> > > }
> > > }
> > >
> > > Signed-off-by: Octavian Purdila 
> > > Signed-off-by: Irina Tirdea 
> > > Acked-by: Bastien Nocera 
> > > Tested-by: Bastien Nocera 
> > > Tested-by: Aleksei Mamlin 
> > > ---
> > >  .../bindings/input/touchscreen/goodix.txt  |   5 +
> > >  drivers/input/touchscreen/Kconfig  |   1 +
> > >  drivers/input/touchscreen/goodix.c | 101 
> > > +
> > >  3 files changed, 107 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > index 8ba98ee..7137881 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > @@ -12,6 +12,8 @@ Required properties:
> > >   - reg   : I2C address of the chip. Should be 0x5d or 
> > > 0x14
> > >   - interrupt-parent  : Interrupt controller to which the chip is 
> > > connected
> > >   - interrupts: Interrupt to which the chip is connected
> > > + - irq-gpio  : GPIO pin used for IRQ
> > > + - reset-gpio: GPIO pin used for reset
> > >
> > >  Example:
> > >
> > > @@ -23,6 +25,9 @@ Example:
> > >   reg = <0x5d>;
> > >   interrupt-parent = <>;
> > >   interrupts = <0 0>;
> > > +
> > > + irq-gpio 

RE: [PATCH v9 2/9] Input: goodix - reset device at init

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 12 October, 2015 19:48
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> 
> On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > After power on, it is recommended that the driver resets the device.
> > The reset procedure timing is described in the datasheet and is used
> > at device init (before writing device configuration) and
> > for power management. It is a sequence of setting the interrupt
> > and reset pins high/low at specific timing intervals. This procedure
> > also includes setting the slave address to the one specified in the
> > ACPI/device tree.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > For reset the driver needs to control the interrupt and
> > reset gpio pins (configured through ACPI/device tree). For devices
> > that do not have the gpio pins properly declared, the functionality
> > depending on these pins will not be available, but the device can still
> > be used with basic functionality.
> >
> > For both device tree and ACPI, the interrupt gpio pin configuration is
> > read from the "irq-gpio" property and the reset pin configuration is
> > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > can be specified using the _DSD section. This functionality will not be
> > available for devices that use indexed gpio pins declared in the _CRS
> > section (we need to provide backward compatibility with devices
> > that do not support using the interrupt gpio pin as output).
> >
> > For ACPI, the pins can be specified using ACPI 5.1:
> > Device (STAC)
> > {
> > Name (_HID, "GDIX1001")
> > ...
> >
> > Method (_CRS, 0, Serialized)
> > {
> > Name (RBUF, ResourceTemplate ()
> > {
> > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > AddressingMode7Bit, "\\I2C0",
> > 0x00, ResourceConsumer, ,
> > )
> >
> > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > "\\I2C0", 0x00, ResourceConsumer, ,
> >  )
> >  {   // Pin list
> >  0
> >  }
> >
> > GpioIo (Exclusive, PullDown, 0x, 0x,
> > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > ResourceConsumer, ,
> > )
> > {
> >  1
> > }
> > })
> > Return (RBUF)
> > }
> >
> > Name (_DSD,  Package ()
> > {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package ()
> > {
> > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > ...
> > }
> > }
> >
> > Signed-off-by: Octavian Purdila 
> > Signed-off-by: Irina Tirdea 
> > Acked-by: Bastien Nocera 
> > Tested-by: Bastien Nocera 
> > Tested-by: Aleksei Mamlin 
> > ---
> >  .../bindings/input/touchscreen/goodix.txt  |   5 +
> >  drivers/input/touchscreen/Kconfig  |   1 +
> >  drivers/input/touchscreen/goodix.c | 101 
> > +
> >  3 files changed, 107 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > index 8ba98ee..7137881 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > @@ -12,6 +12,8 @@ Required properties:
> >   - reg : I2C address of the chip. Should be 0x5d or 
> > 0x14
> >   - interrupt-parent: Interrupt controller to which the chip is 
> > connected
> >   - interrupts  : Interrupt to which the chip is connected
> > + - irq-gpio: GPIO pin used for IRQ
> > + - reset-gpio  : GPIO pin used for reset
> >
> >  Example:
> >
> > @@ -23,6 +25,9 @@ Example:
> > reg = <0x5d>;
> > interrupt-parent = <>;
> > interrupts = <0 0>;
> > +
> > +   irq-gpio = < 0 0>;
> > +   reset-gpio = < 1 0>;
> > };
> >
> > /* ... */
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 771d95c..76f5a9d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ 

RE: [PATCH RFC V2 2/3] Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen"

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: Karsten Merker [mailto:mer...@debian.org]
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin; 
> linux-input@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; Chen-Yu Tsai; 
> Karsten Merker
> Subject: [PATCH RFC V2 2/3] Input: goodix - use "inverted_[xy]" flags instead 
> of "rotated_screen"
> 
> The goodix touchscreen driver uses a "rotated_screen" flag for
> systems on which the touchscreen is mounted rotated by 180
> degrees with respect to the display.  With the addition of
> support for the dt properties "touchscreen-inverted-x" and
> "touchscreen-inverted-y", a separate "rotated_screen" flag
> is not necessary any more. This patch replaces it by setting
> the inverted_x and inverted_y flags instead.
> 
> Signed-off-by: Karsten Merker 
> ---

Reviewed-by: Irina Tirdea 

>  drivers/input/touchscreen/goodix.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/goodix.c 
> b/drivers/input/touchscreen/goodix.c
> index a05bdad..d910b27 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -40,7 +40,6 @@ struct goodix_ts_data {
>   int abs_y_max;
>   unsigned int max_touch_num;
>   unsigned int int_trigger_type;
> - bool rotated_screen;
>   int cfg_len;
>   struct gpio_desc *gpiod_int;
>   struct gpio_desc *gpiod_rst;
> @@ -270,11 +269,6 @@ static void goodix_ts_report_touch(struct goodix_ts_data 
> *ts, u8 *coor_data)
>   int input_y = get_unaligned_le16(_data[3]);
>   int input_w = get_unaligned_le16(_data[5]);
> 
> - if (ts->rotated_screen) {
> - input_x = ts->abs_x_max - input_x;
> - input_y = ts->abs_y_max - input_y;
> - }
> -
>   /* Inversions have to happen before axis swapping */
>   if (ts->inverted_x)
>   input_x = ts->abs_x_max - input_x;
> @@ -701,10 +695,12 @@ static void goodix_read_config(struct goodix_ts_data 
> *ts)
>   ts->max_touch_num = GOODIX_MAX_CONTACTS;
>   }
> 
> - ts->rotated_screen = dmi_check_system(rotated_screen);
> - if (ts->rotated_screen)
> + if (dmi_check_system(rotated_screen)) {
> + ts->inverted_x = true;
> + ts->inverted_y = true;
>   dev_dbg(>client->dev,
>"Applying '180 degrees rotated screen' quirk\n");
> + }
>  }
> 
>  /**
> --
> 2.1.4

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


RE: [PATCH RFC V2 0/3] Input: goodix - add axis swapping and axis inversion support

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: Karsten Merker [mailto:mer...@debian.org]
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin; 
> linux-input@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; Chen-Yu Tsai; 
> Karsten Merker
> Subject: [PATCH RFC V2 0/3] Input: goodix - add axis swapping and axis 
> inversion support
> 
> Hello,
> 
> this is v2 of my "Input: goodix - add axis swapping and axis inversion
> support" patchset.
> The goodix touchscreen driver has gained device-tree support in kernel
> 4.1, but doesn't currently support the touchscreen-swapped-x-y,
> touchscreen-inverted-x and touchscreen-inverted-y properties.
> 
> On systems which combine a portrait-mode display with a landscape-mode
> touchscreen, such as e.g. the MSI Primo 81 tablet, support for these
> features is necessary to have the touchscreen and the display use the
> same coordinate system.
> 
> With support for axis inversion, the "rotated_screen" flag in the
> driver can also be removed, as "rotated_screen" is just a special case
> of x/y axis inversion.
> 
> This patchset sits on top of the "[PATCH v8 0/9] Goodix touchscreen
> enhancements" series by Irina Tirdea:
> https://www.spinics.net/lists/linux-input/msg41437.html
> 
> I have successfully tested the axis swapping on an (arm-based) MSI
> Primo 81 tablet, but I lack appropriate hardware to do a real-world
> test of the "rotated_screen" code path, so I would appreciate very
> much if somebody with appropriate hardware (WinBook TW100 or TW700)
> could give it a try.
> 
> Regards,
> Karsten
> 

Hi Karsten,

I took a look at your patches and also did a quick test on my setup.
Code looks good, I have just one comment I've mentioned on the
first patch in the series.

Thanks,
Irina

> Changelog:
> 
> v1: * Initial version (based von v6 of Irina Tirdea's "Goodix
>   touchscreen enhancements" series).
>   Reviewed-by: Bastien Nocera 
> 
> v2: * Rebase against v8 of Irina Tirdea's "Goodix touchscreen
>   enhancements" series.
> * Fix a typo in the commit message.
> * Add an update for the goodix dt bindings documentation
>   (patch No. 3).
> 
> 
> Karsten Merker (3):
>   Input: goodix - add dt axis swapping and axis inversion support
>   Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen"
>   Input: goodix - update dt bindings documentation (axis
> swapping/inversion)
> 
>  .../bindings/input/touchscreen/goodix.txt  |  6 
>  drivers/input/touchscreen/goodix.c | 33 
> ++
>  2 files changed, 34 insertions(+), 5 deletions(-)
> 
> --
> 2.1.4

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


RE: [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas tree order

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 12 October, 2015 19:31
> To: Bastien Nocera
> Cc: Mark Rutland; Tirdea, Irina; Aleksei Mamlin; Karsten Merker; 
> linux-input@vger.kernel.org; Purdila, Octavian; lkml;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas 
> tree order
> 
> On Mon, Oct 12, 2015 at 8:53 AM, Bastien Nocera  wrote:
> > On Mon, 2015-10-12 at 16:51 +0100, Mark Rutland wrote:
> >> On Mon, Oct 12, 2015 at 05:40:37PM +0200, Bastien Nocera wrote:
> >> > On Mon, 2015-10-12 at 16:39 +0100, Mark Rutland wrote:
> >> > > Why?
> >> >
> >> > It was already discussed in the thread for a previous version,
> >> > please
> >> > refer to that.
> >>
> >> Fine, but surely that should be in the commit message, to prevent
> >> others
> >> like myself repeatedly asking the same question?
> >
> > Fair point. Irina?
> 
> No, let's just leave poor includes alone.
> 

OK, will drop this :)

Thanks,
Irina

> --
> Dmitry


RE: [PATCH v9 2/9] Input: goodix - reset device at init

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 13 October, 2015 10:08
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> 
> On Tue, Oct 13, 2015 at 06:38:23AM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > Sent: 12 October, 2015 19:48
> > > To: Tirdea, Irina
> > > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> > > linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> > >
> > > On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > > > After power on, it is recommended that the driver resets the device.
> > > > The reset procedure timing is described in the datasheet and is used
> > > > at device init (before writing device configuration) and
> > > > for power management. It is a sequence of setting the interrupt
> > > > and reset pins high/low at specific timing intervals. This procedure
> > > > also includes setting the slave address to the one specified in the
> > > > ACPI/device tree.
> > > >
> > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > > driver gt9xx.c for Android (publicly available in Android kernel
> > > > trees for various devices).
> > > >
> > > > For reset the driver needs to control the interrupt and
> > > > reset gpio pins (configured through ACPI/device tree). For devices
> > > > that do not have the gpio pins properly declared, the functionality
> > > > depending on these pins will not be available, but the device can still
> > > > be used with basic functionality.
> > > >
> > > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > > read from the "irq-gpio" property and the reset pin configuration is
> > > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > > can be specified using the _DSD section. This functionality will not be
> > > > available for devices that use indexed gpio pins declared in the _CRS
> > > > section (we need to provide backward compatibility with devices
> > > > that do not support using the interrupt gpio pin as output).
> > > >
> > > > For ACPI, the pins can be specified using ACPI 5.1:
> > > > Device (STAC)
> > > > {
> > > > Name (_HID, "GDIX1001")
> > > > ...
> > > >
> > > > Method (_CRS, 0, Serialized)
> > > > {
> > > > Name (RBUF, ResourceTemplate ()
> > > > {
> > > > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > > > AddressingMode7Bit, "\\I2C0",
> > > > 0x00, ResourceConsumer, ,
> > > > )
> > > >
> > > > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > > > "\\I2C0", 0x00, ResourceConsumer, ,
> > > >  )
> > > >  {   // Pin list
> > > >  0
> > > >  }
> > > >
> > > > GpioIo (Exclusive, PullDown, 0x, 0x,
> > > > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > > > ResourceConsumer, ,
> > > > )
> > > > {
> > > >  1
> > > > }
> > > > })
> > > > Return (RBUF)
> > > > }
> > > >
> > > > Name (_DSD,  Package ()
> > > > {
> > > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > Package ()
> > > > {
> > > > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > > > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > > > ...
> > > > }
> > > > }
> > > >
> > > > Signed-off-by: Octavian Purdila 
> > > > Signed-off-by: Irina Tirdea 
> > > > Acked-by: Bastien Nocera 
> > > > Tested-by: Bastien Nocera 
> > > > Tested-by: Aleksei Mamlin 
> > > > ---
> > > >  .../bindings/input/touchscreen/goodix.txt  |   5 +
> > > >  drivers/input/touchscreen/Kconfig  |   1 +
> > > >  drivers/input/touchscreen/goodix.c | 101 
> > > > +
> > > >  3 files changed, 107 insertions(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > index 8ba98ee..7137881 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > @@ -12,6 +12,8 @@ Required properties:
> > > >   

RE: [PATCH RFC V2 3/3] Input: goodix - update dt bindings documentation (axis swapping/inversion)

2015-10-13 Thread Tirdea, Irina


> -Original Message-
> From: linux-input-ow...@vger.kernel.org 
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Karsten Merker
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin; 
> linux-input@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; Chen-Yu Tsai; 
> Karsten Merker
> Subject: [PATCH RFC V2 3/3] Input: goodix - update dt bindings documentation 
> (axis swapping/inversion)
> 
> The goodix touchscreen driver has gained support for the
> optional touchscreen-inverted-x, touchscreen-inverted-y
> and touchscreen-swapped-x-y properties as described in
> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt.
> 
> Document these properties in the goodix bindings description.
> 
> Signed-off-by: Karsten Merker 

Reviewed-by: Irina Tirdea 

> ---
>  Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> index 4db3393..4ecd0e1 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> @@ -14,6 +14,7 @@ Required properties:
>   - interrupts: Interrupt to which the chip is connected
>   - irq-gpio  : GPIO pin used for IRQ
>   - reset-gpio: GPIO pin used for reset
> +
>  Optional properties:
> 
>   - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the driver 
> to
> @@ -21,6 +22,11 @@ Optional properties:
>  device. ESD is disabled if this property is not 
> set
>  or is set to 0.
> 
> + - touchscreen-inverted-x  : X axis is inverted (boolean)
> + - touchscreen-inverted-y  : Y axis is inverted (boolean)
> + - touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
> + (swapping is done after inverting the axis)
> +
>  Example:
> 
>   i2c@ {
> --
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v9 2/9] Input: goodix - reset device at init

2015-10-13 Thread mika.westerb...@linux.intel.com
On Tue, Oct 13, 2015 at 08:54:12AM +, Tirdea, Irina wrote:
> > > I did not use devm_gpiod_get_optional() in order to ignore more errors
> > > than -ENOENT. This is needed because the ACPI gpio core will fall back
> > > to indexed gpios if named gpios are not found. In the common case of
> > > having 2 indexed gpio pins declared in the ACPI table, the first
> > > devm_gpiod_get() will successfully get indexed gpio pin 0 and the
> > > second devm_gpiod_get() will try to get the same gpio pin 0 and return
> > > -EBUSY. Considering this, I thought it is better to just ignore all 
> > > errors in
> > > order not to break any platforms currently using this driver.
> > 
> > This seems like issue with ACPI gpio lookup implementation. If I am
> > requesting named gpio and it is not present then I definitely do not
> > need to be returned some random gpio. Doing so breaks all other drivers
> > that use several names to retrieve GPIOs. We basically can't trust GPIO
> > API on ACPI systems.
> > 
> 
> I'm not sure there is a way to avoid fall back to indexed gpios when 
> requesting
> named gpios.
> Adding Mika to this thread as he might help answer this.

Before ACPI 5.1 _DSD device properties were introduced all we had was an
array of GPIOs returned by _CRS ACPI method. Ordering of those GPIOs
could change from one vendor to another :-(

We can (and do) use acpi_dev_add_driver_gpios() to pass correct mappings
where _DSD is not present based on the device ACPI ID for instance. Not
all drivers do that, though.

I would like to get rid of the fallback completely at some point. We
have had already problems with the API because then some ACPI only
drivers did this:

reset_gpio = gpiod_get_index(dev, NULL, 0);
power_gpio = gpiod_get_index(dev, NULL, 1);

which might not do what is expected on DT systems. That's why
acpi_dev_add_driver_gpios() was added in the first place IIRC.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/2] input: rotary encoder: Add wake up support

2015-10-13 Thread Sylvain Rochet
Hi Johan,


On Tue, Oct 13, 2015 at 02:39:48PM +0200, Johan Hovold wrote:
> On Mon, Oct 12, 2015 at 09:13:32PM +0200, Sylvain Rochet wrote:
> > This patch adds wake up support to GPIO rotary encoders.
> > 
> > Signed-off-by: Sylvain Rochet 
> > Reviewed-by: Johan Hovold 
> 
> Hmm. I have not yet reviewed the changes you did in v4.

Woops, sorry, I forgot to remove it while rebasing.


> > ---
> >  drivers/input/misc/rotary_encoder.c | 39 
> > +
> >  include/linux/rotary_encoder.h  |  1 +
> >  2 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/input/misc/rotary_encoder.c 
> > b/drivers/input/misc/rotary_encoder.c
> > index f27f81e..0d86dc4 100644
> > --- a/drivers/input/misc/rotary_encoder.c
> > +++ b/drivers/input/misc/rotary_encoder.c
> 
> > @@ -280,6 +283,10 @@ static int rotary_encoder_probe(struct platform_device 
> > *pdev)
> > goto exit_free_irq_b;
> > }
> >  
> > +   device_set_wakeup_capable(>dev, true);
> 
> You should continue to use the platform data to determine whether the
> device is capable of wakeup or not.
> 
> > +   if (pdata->wakeup_source)
> > +   device_wakeup_enable(>dev);
> > +
> 
> Just stick to
> 
>   device_init_wakeup(>dev, pdata->wakeup_source);

There is unfortunately no or poor documentation on how "wakeup-source" 
DT property should behave. We have no clue if wake up should be enabled 
by default, which is what device_init_wakeup() is doing. If 
"wakeup-source" is just a flag to determine whether the device is 
capable of wakeup or not then it should probably not change the behavior 
and wake up should probably be off by default, thus the right way would 
be to call device_set_wakeup_capable(>dev, pdata->wakeup_source);

device_init_wakeup() is a bit confusing, its introductory comment says 
that "By default, most devices should leave wakeup disabled." but it 
actually enables it by default. In this case we are the exception "The 
exceptions are devices that everyone expects to be wakeup sources: 
keyboards, …" but it only adds more confusion, we are the exception, but 
by default we are not.

Anyway, I don't really care and I will resend with device_init_wakeup() 
because wakeup support enabled by default is what I need.

Thank you very much :-)

Cheers,
Sylvain
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] HID: update PenMount USB report descriptor so that only one button is reported

2015-10-13 Thread Benjamin Tissoires
Hi Andrew,

[resurrecting this following a ping from Andrew]

On Thu, Jul 23, 2015 at 12:20 PM, Andrew Shadura
 wrote:
> PenMount USB resistive touchscreen reports it has three buttons, while in 
> reality
> it doesn't have any and doesn't support active styli, and only generates touch
> events.
>
> Signed-off-by: Andrew Shadura 
> ---
>  drivers/hid/hid-penmount.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/hid/hid-penmount.c b/drivers/hid/hid-penmount.c
> index c11dce8..98ea1c12 100644
> --- a/drivers/hid/hid-penmount.c
> +++ b/drivers/hid/hid-penmount.c
> @@ -30,6 +30,23 @@ static int penmount_input_mapping(struct hid_device *hdev,
> return 0;
>  }
>
> +static __u8 *penmount_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> +unsigned int *rsize)
> +{
> +   if (*rsize == 76 &&
> +   rdesc[2] == 0x09 && rdesc[3] == 0x02 /* mouse */ &&
> +   rdesc[22] == 0x05 && rdesc[23] == 0x09 /* button */ &&
> +   rdesc[26] == 0x29 && rdesc[27] == 0x03 /* maximum */ &&
> +   rdesc[32] == 0x95 && rdesc[33] == 0x02 /* report count */) {
> +   hid_info(hdev,
> +   "fixing up PenMount USB touchscreen report 
> descriptor\n");
> +
> +   rdesc[27] = 0x01; /* just one button */
> +   rdesc[33] = 0x01; /* just one report */

This is wrong. Changing this value shifts all the parsing of the rest
of the report descriptor. So if this is the last field in the current
report, then it might work. If not, then you are screwing the rest of
the report.

You can have 2 solutions to fix that:
- either you still use a report fixup and you add an extra const field
with a vendor usage page after this one (but that means allocating a
new report descriptor slightly larger)
- either you don't use a report fixup at all and ignore the extra
buttons in .input_mapping().

Cheers,
Benjamin

> +   }
> +   return rdesc;
> +}
> +
>  static const struct hid_device_id penmount_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_6000) 
> },
> { }
> @@ -39,6 +56,7 @@ MODULE_DEVICE_TABLE(hid, penmount_devices);
>  static struct hid_driver penmount_driver = {
> .name = "hid-penmount",
> .id_table = penmount_devices,
> +   .report_fixup = penmount_report_fixup,
> .input_mapping = penmount_input_mapping,
>  };
>
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/2] input: rotary encoder: Add wake up support

2015-10-13 Thread Johan Hovold
On Mon, Oct 12, 2015 at 09:13:32PM +0200, Sylvain Rochet wrote:
> This patch adds wake up support to GPIO rotary encoders.
> 
> Signed-off-by: Sylvain Rochet 
> Reviewed-by: Johan Hovold 

Hmm. I have not yet reviewed the changes you did in v4.

> ---
>  drivers/input/misc/rotary_encoder.c | 39 
> +
>  include/linux/rotary_encoder.h  |  1 +
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/input/misc/rotary_encoder.c 
> b/drivers/input/misc/rotary_encoder.c
> index f27f81e..0d86dc4 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c

> @@ -280,6 +283,10 @@ static int rotary_encoder_probe(struct platform_device 
> *pdev)
>   goto exit_free_irq_b;
>   }
>  
> + device_set_wakeup_capable(>dev, true);

You should continue to use the platform data to determine whether the
device is capable of wakeup or not.

> + if (pdata->wakeup_source)
> + device_wakeup_enable(>dev);
> +

Just stick to

device_init_wakeup(>dev, pdata->wakeup_source);

as in v3.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Chromebook Pixel 1 atmel_mxt_ts doesn't work

2015-10-13 Thread Zooko Wilcox-O'Hearn
I'm running Linux 4.1.10 on a Chromebook Pixel 1 and my touchpad and
touchscreen don't work. Guided by Dmitry Torokhov on G+
(https://plus.google.com/u/0/+BensonLeung/posts/8zum4U7Aztg), I've
gotten as far as thinking that maybe these /var/log/syslog messages
are indicating the problem:

Oct 13 17:35:56 spark kernel: [ 2767.471569] atmel_mxt_ts 3-004a:
Direct firmware load for maxtouch.cfg failed with error -2
Oct 13 17:35:56 spark kernel: [ 2767.509568] input: Atmel maXTouch
Touchscreen as /devices/pci:00/:00:02.0/i2c-3/3-004a/input/input14
Oct 13 17:35:56 spark kernel: [ 2767.510569] atmel_mxt_ts 2-004b:
Direct firmware load for maxtouch.cfg failed with error -2
Oct 13 17:35:56 spark kernel: [ 2767.513378] atmel_mxt_ts 3-004a:
Family: 162 Variant: 0 Firmware V1.1.AA Objects: 27
Oct 13 17:35:56 spark kernel: [ 2767.515044] input: Atmel maXTouch
Touchpad as /devices/pci:00/:00:02.0/i2c-2/2-004b/input/input15
Oct 13 17:35:56 spark kernel: [ 2767.515304] atmel_mxt_ts 2-004b:
Family: 130 Variant: 1 Firmware V1.0.AA Objects: 22

These get posted whenever I modprobe atmel_mxt_ts, although the module
is subsequently listed in lsmod.

Here are some of my kernel config options:

$ zgrep -i i2c /proc/config.gz  | grep -v ^#
CONFIG_REGMAP_I2C=y
CONFIG_TCG_TIS_I2C_ATMEL=m
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_MUX=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_I801=y
CONFIG_I2C_ISCH=m
CONFIG_I2C_SCMI=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_I2C_STUB=m
CONFIG_MFD_CROS_EC_I2C=y
CONFIG_SND_SOC_I2C_AND_SPI=m

Here is the result of evtest:

zooko@spark~ $ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  Lid Switch
/dev/input/event1:  Power Button
/dev/input/event2:  Sleep Button
/dev/input/event3:  Sleep Button
/dev/input/event4:  Power Button
/dev/input/event5:  AT Translated Set 2 keyboard
/dev/input/event6:  Video Bus
/dev/input/event7:  Chromebook HD WebCam
/dev/input/event8:  Samsung S Action Mouse ET-MP900D
/dev/input/event9:  Jabra BIZ 2400 USB
/dev/input/event10: Lite-On Technology Corp. Goldtouch USB Keyboard
/dev/input/event11: Atmel maXTouch Touchpad
/dev/input/event12: Atmel maXTouch Touchscreen
/dev/input/event13: Lite-On Technology Corp. Goldtouch USB Keyboard
Select the device event number [0-13]: 11
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "Atmel maXTouch Touchpad"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 325 (BTN_TOOL_FINGER)
Event code 328 (BTN_TOOL_QUINTTAP)
Event code 330 (BTN_TOUCH)
Event code 333 (BTN_TOOL_DOUBLETAP)
Event code 334 (BTN_TOOL_TRIPLETAP)
Event code 335 (BTN_TOOL_QUADTAP)
  Event type 3 (EV_ABS)
Event code 0 (ABS_X)
  Value  0
  Min0
  Max 2039
  Resolution  20
Event code 1 (ABS_Y)
  Value  0
  Min0
  Max 1359
  Resolution  20
Event code 24 (ABS_PRESSURE)
  Value  0
  Min0
  Max  255
Event code 47 (ABS_MT_SLOT)
  Value  0
  Min0
  Max9
Event code 48 (ABS_MT_TOUCH_MAJOR)
  Value  0
  Min0
  Max  255
Event code 53 (ABS_MT_POSITION_X)
  Value  0
  Min0
  Max 2039
  Resolution  20
Event code 54 (ABS_MT_POSITION_Y)
  Value  0
  Min0
  Max 1359
  Resolution  20
Event code 57 (ABS_MT_TRACKING_ID)
  Value  0
  Min0
  Max65535
Event code 58 (ABS_MT_PRESSURE)
  Value  0
  Min0
  Max  255
Properties:
  Property type 0 (INPUT_PROP_POINTER)
  Property type 2 (INPUT_PROP_BUTTONPAD)

Thanks, folks!

--Zooko
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] HID: wacom: Add support for Cintiq Companion 2

2015-10-13 Thread Jason Gerecke
Adds support for the EMR (pen+pad) and touchscreen devices used by the
Wacom Cintiq Companion 2. This applies both to using the device as a
standalone system, as well as when operating in "Cintiq mode" (where
the EMR/touchscreen are simply exposed as USB devices to the system
its connected to).

Signed-off-by: Jason Gerecke 
Signed-off-by: Clifford Jolly 
---
Changes from v2:
 * The switch in wacom_setup_pen_input_capabilities now only contains the
   first CINTIQ_COMPANION_2 case. The second case has been moved to the
   switch in wacom_setup_pad_input_capabilities where it belongs.

 * The second CINTIQ_COMPANION_2 case mentioned above no longer explicitly
   sets up the pad buttons since wacom_setup_numbered_buttons is now
   (70ee06c) in charge of this initialization.

 drivers/hid/wacom_sys.c |  2 +-
 drivers/hid/wacom_wac.c | 36 +++-
 drivers/hid/wacom_wac.h |  1 +
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 5f6e48e..2e7a1c7 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -420,7 +420,7 @@ static int wacom_query_tablet_data(struct hid_device *hdev,
/* MT Tablet PC touch */
return wacom_set_device_mode(hdev, 3, 4, 4);
}
-   else if (features->type == WACOM_24HDT || features->type == 
CINTIQ_HYBRID) {
+   else if (features->type == WACOM_24HDT || features->type == 
CINTIQ_HYBRID || features->type == CINTIQ_COMPANION_2) {
return wacom_set_device_mode(hdev, 18, 3, 2);
}
else if (features->type == WACOM_27QHDT) {
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 46bd02b..e0b9320 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -765,7 +765,7 @@ static void wacom_intuos_general(struct wacom_wac *wacom)
/* general pen packet */
if ((data[1] & 0xb8) == 0xa0) {
t = (data[6] << 2) | ((data[7] >> 6) & 3);
-   if (features->type >= INTUOS4S && features->type <= 
CINTIQ_HYBRID) {
+   if (features->type >= INTUOS4S && features->type <= 
CINTIQ_COMPANION_2) {
t = (t << 1) | (data[1] & 1);
}
input_report_abs(input, ABS_PRESSURE, t);
@@ -948,6 +948,27 @@ static int wacom_intuos_irq(struct wacom_wac *wacom)
} else {
input_report_abs(input, ABS_MISC, 0);
}
+
+   } else if (features->type == CINTIQ_COMPANION_2) {
+   input_report_key(input, BTN_1, (data[1] & 0x02));
+   input_report_key(input, BTN_2, (data[2] & 0x01));
+   input_report_key(input, BTN_3, (data[2] & 0x02));
+   input_report_key(input, BTN_4, (data[2] & 0x04));
+   input_report_key(input, BTN_5, (data[2] & 0x08));
+   input_report_key(input, BTN_6, (data[1] & 0x04));
+
+   input_report_key(input, BTN_7, (data[2] & 0x10));  /* 
Right  */
+   input_report_key(input, BTN_8, (data[2] & 0x20));  /* 
Up */
+   input_report_key(input, BTN_9, (data[2] & 0x40));  /* 
Left   */
+   input_report_key(input, BTN_A, (data[2] & 0x80));  /* 
Down   */
+   input_report_key(input, BTN_0, (data[1] & 0x01));  /* 
Center */
+
+   if (data[4] | (data[3] & 0x01)) {
+   input_report_abs(input, ABS_MISC, 
PAD_DEVICE_ID);
+   } else {
+   input_report_abs(input, ABS_MISC, 0);
+   }
+
} else if (features->type >= INTUOS5S && features->type <= 
INTUOSPL) {
int i;
 
@@ -2290,6 +2311,7 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t 
len)
case WACOM_27QHD:
case DTK:
case CINTIQ_HYBRID:
+   case CINTIQ_COMPANION_2:
sync = wacom_intuos_irq(wacom_wac);
break;
 
@@ -2543,6 +2565,7 @@ int wacom_setup_pen_input_capabilities(struct input_dev 
*input_dev,
case CINTIQ:
case WACOM_13HD:
case CINTIQ_HYBRID:
+   case CINTIQ_COMPANION_2:
input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
input_abs_set_res(input_dev, ABS_Z, 287);
__set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
@@ -2775,6 +2798,7 @@ int wacom_setup_pad_input_capabilities(struct input_dev 
*input_dev,
switch (features->type) {
 
case CINTIQ_HYBRID:
+   case CINTIQ_COMPANION_2:
case DTK:
case DTUS:
case GRAPHIRE_BT:
@@ -3347,6 +3371,14 @@ static const struct wacom_features wacom_features_0x318 =
 static 

Re: Chromebook Pixel 1 atmel_mxt_ts doesn't work

2015-10-13 Thread Zooko Wilcox-O'Hearn
This is the complete output of running evtest and choosing option 10,
from the console (while X is running, but I'm not running evtest under
X).

zooko@spark ~ $ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  Lid Switch
/dev/input/event1:  Power Button
/dev/input/event2:  Sleep Button
/dev/input/event3:  Sleep Button
/dev/input/event4:  Power Button
/dev/input/event5:  AT Translated Set 2 keyboard
/dev/input/event6:  Chromebook HD WebCam
/dev/input/event7:  Video Bus
/dev/input/event8:  Logitech M325
/dev/input/event9:  Atmel maXTouch Touchscreen
/dev/input/event10: Atmel maXTouch Touchpad
Select the device event number [0-10]: 10
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "Atmel maXTouch Touchpad"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 325 (BTN_TOOL_FINGER)
Event code 328 (BTN_TOOL_QUINTTAP)
Event code 330 (BTN_TOUCH)
Event code 333 (BTN_TOOL_DOUBLETAP)
Event code 334 (BTN_TOOL_TRIPLETAP)
Event code 335 (BTN_TOOL_QUADTAP)
  Event type 3 (EV_ABS)
Event code 0 (ABS_X)
  Value  0
  Min0
  Max 2039
  Resolution  20
Event code 1 (ABS_Y)
  Value  0
  Min0
  Max 1359
  Resolution  20
Event code 24 (ABS_PRESSURE)
  Value  0
  Min0
  Max  255
Event code 47 (ABS_MT_SLOT)
  Value  0
  Min0
  Max9
Event code 48 (ABS_MT_TOUCH_MAJOR)
  Value  0
  Min0
  Max  255
Event code 53 (ABS_MT_POSITION_X)
  Value  0
  Min0
  Max 2039
  Resolution  20
Event code 54 (ABS_MT_POSITION_Y)
  Value  0
  Min0
  Max 1359
  Resolution  20
Event code 57 (ABS_MT_TRACKING_ID)
  Value  0
  Min0
  Max65535
Event code 58 (ABS_MT_PRESSURE)
  Value  0
  Min0
  Max  255
Properties:
  Property type 0 (INPUT_PROP_POINTER)
  Property type 2 (INPUT_PROP_BUTTONPAD)
Testing ... (interrupt to exit)
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v5 0/2] input: rotary encoder: Add wake up support

2015-10-13 Thread Sylvain Rochet
Changes since v4:
  * As suggested by Johan, Reverted the 
device_set_wakeup_capable()/device_wakeup_enable() change,
stick to device_init_wakeup()

Changes since v3:
  * Stick to the "wakeup-source" DT property, we are standardizing on it.
  * Improved wake-up support: This driver is always supporting wake up
support, thus it is now calling device_set_wakeup_capable(dev, true)
followed by device_wakeup_enable(dev) if wake up is enabled at boot
time. This way the wakeup sysfs tree is always available to the user.
Only calling device_init_wakeup(dev, false) totally disable wake up  
support at boot tine with no way to enable wake up support furtherly,
which isn't nice.

Changes since v2:
  * Using false instead of 0 on boolean
  * Splitted DT documentation in a separate patch

Changes since v1:
  * Using DT property wakeup-source instead of rotary-encoder,wakeup
  * Renamed int wakeup to bool wakeup_source
  * Patch cleanup (checkpatch.pl)

Sylvain Rochet (2):
  Documentation: input: rotary encoder: Add wakeup-source property
  input: rotary encoder: Add wake up support

 .../devicetree/bindings/input/rotary-encoder.txt   |  1 +
 Documentation/input/rotary-encoder.txt |  1 +
 drivers/input/misc/rotary_encoder.c| 37 ++
 include/linux/rotary_encoder.h |  1 +
 4 files changed, 40 insertions(+)

-- 
2.5.1

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


[PATCH v5 2/2] input: rotary encoder: Add wake up support

2015-10-13 Thread Sylvain Rochet
This patch adds wake up support to GPIO rotary encoders.

Signed-off-by: Sylvain Rochet 
Reviewed-by: Johan Hovold 
---
 drivers/input/misc/rotary_encoder.c | 37 +
 include/linux/rotary_encoder.h  |  1 +
 2 files changed, 38 insertions(+)

diff --git a/drivers/input/misc/rotary_encoder.c 
b/drivers/input/misc/rotary_encoder.c
index f27f81e..d166554 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRV_NAME "rotary-encoder"
 
@@ -180,6 +181,8 @@ static struct rotary_encoder_platform_data 
*rotary_encoder_parse_dt(struct devic
"rotary-encoder,rollover", NULL);
pdata->half_period = !!of_get_property(np,
"rotary-encoder,half-period", NULL);
+   pdata->wakeup_source = !!of_get_property(np,
+   "wakeup-source", NULL);
 
return pdata;
 }
@@ -280,6 +283,8 @@ static int rotary_encoder_probe(struct platform_device 
*pdev)
goto exit_free_irq_b;
}
 
+   device_init_wakeup(>dev, pdata->wakeup_source);
+
platform_set_drvdata(pdev, encoder);
 
return 0;
@@ -306,6 +311,8 @@ static int rotary_encoder_remove(struct platform_device 
*pdev)
struct rotary_encoder *encoder = platform_get_drvdata(pdev);
const struct rotary_encoder_platform_data *pdata = encoder->pdata;
 
+   device_init_wakeup(>dev, false);
+
free_irq(encoder->irq_a, encoder);
free_irq(encoder->irq_b, encoder);
gpio_free(pdata->gpio_a);
@@ -320,11 +327,41 @@ static int rotary_encoder_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int rotary_encoder_suspend(struct device *dev)
+{
+   struct rotary_encoder *encoder = dev_get_drvdata(dev);
+
+   if (device_may_wakeup(dev)) {
+   enable_irq_wake(encoder->irq_a);
+   enable_irq_wake(encoder->irq_b);
+   }
+
+   return 0;
+}
+
+static int rotary_encoder_resume(struct device *dev)
+{
+   struct rotary_encoder *encoder = dev_get_drvdata(dev);
+
+   if (device_may_wakeup(dev)) {
+   disable_irq_wake(encoder->irq_a);
+   disable_irq_wake(encoder->irq_b);
+   }
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(rotary_encoder_pm_ops,
+rotary_encoder_suspend, rotary_encoder_resume);
+
 static struct platform_driver rotary_encoder_driver = {
.probe  = rotary_encoder_probe,
.remove = rotary_encoder_remove,
.driver = {
.name   = DRV_NAME,
+   .pm = _encoder_pm_ops,
.of_match_table = of_match_ptr(rotary_encoder_of_match),
}
 };
diff --git a/include/linux/rotary_encoder.h b/include/linux/rotary_encoder.h
index 3f594dc..b33f2d2 100644
--- a/include/linux/rotary_encoder.h
+++ b/include/linux/rotary_encoder.h
@@ -11,6 +11,7 @@ struct rotary_encoder_platform_data {
bool relative_axis;
bool rollover;
bool half_period;
+   bool wakeup_source;
 };
 
 #endif /* __ROTARY_ENCODER_H__ */
-- 
2.5.1

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


[PATCH v5 1/2] Documentation: input: rotary encoder: Add wakeup-source property

2015-10-13 Thread Sylvain Rochet
This patch adds property wakeup-source to GPIO rotary encoders.

Signed-off-by: Sylvain Rochet 
Reviewed-by: Johan Hovold 
Cc: 
---
 Documentation/devicetree/bindings/input/rotary-encoder.txt | 1 +
 Documentation/input/rotary-encoder.txt | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt 
b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index 3315495..2c643a3 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -15,6 +15,7 @@ Optional properties:
 - rotary-encoder,rollover: Automatic rollove when the rotary value becomes
   greater than the specified steps or smaller than 0. For absolute axis only.
 - rotary-encoder,half-period: Makes the driver work on half-period mode.
+- wakeup-source: Boolean, rotary encoder can wake-up the system.
 
 See Documentation/input/rotary-encoder.txt for more information.
 
diff --git a/Documentation/input/rotary-encoder.txt 
b/Documentation/input/rotary-encoder.txt
index 5737e35..bddbee1 100644
--- a/Documentation/input/rotary-encoder.txt
+++ b/Documentation/input/rotary-encoder.txt
@@ -109,6 +109,7 @@ static struct rotary_encoder_platform_data 
my_rotary_encoder_info = {
.inverted_a = 0,
.inverted_b = 0,
.half_period= false,
+   .wakeup_source  = false,
 };
 
 static struct platform_device rotary_encoder_device = {
-- 
2.5.1

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


Re: Chromebook Pixel 1 atmel_mxt_ts doesn't work

2015-10-13 Thread Dmitry Torokhov
Hi Zooko,

On Tue, Oct 13, 2015 at 10:39 AM, Zooko Wilcox-O'Hearn  wrote:
> I'm running Linux 4.1.10 on a Chromebook Pixel 1 and my touchpad and
> touchscreen don't work. Guided by Dmitry Torokhov on G+
> (https://plus.google.com/u/0/+BensonLeung/posts/8zum4U7Aztg), I've
> gotten as far as thinking that maybe these /var/log/syslog messages
> are indicating the problem:
>
> Oct 13 17:35:56 spark kernel: [ 2767.471569] atmel_mxt_ts 3-004a:
> Direct firmware load for maxtouch.cfg failed with error -2
> Oct 13 17:35:56 spark kernel: [ 2767.509568] input: Atmel maXTouch
> Touchscreen as /devices/pci:00/:00:02.0/i2c-3/3-004a/input/input14
> Oct 13 17:35:56 spark kernel: [ 2767.510569] atmel_mxt_ts 2-004b:
> Direct firmware load for maxtouch.cfg failed with error -2
> Oct 13 17:35:56 spark kernel: [ 2767.513378] atmel_mxt_ts 3-004a:
> Family: 162 Variant: 0 Firmware V1.1.AA Objects: 27
> Oct 13 17:35:56 spark kernel: [ 2767.515044] input: Atmel maXTouch
> Touchpad as /devices/pci:00/:00:02.0/i2c-2/2-004b/input/input15
> Oct 13 17:35:56 spark kernel: [ 2767.515304] atmel_mxt_ts 2-004b:
> Family: 130 Variant: 1 Firmware V1.0.AA Objects: 22
>
> These get posted whenever I modprobe atmel_mxt_ts, although the module
> is subsequently listed in lsmod.
>
> Here are some of my kernel config options:
>
> $ zgrep -i i2c /proc/config.gz  | grep -v ^#
> CONFIG_REGMAP_I2C=y
> CONFIG_TCG_TIS_I2C_ATMEL=m
> CONFIG_I2C=y
> CONFIG_ACPI_I2C_OPREGION=y
> CONFIG_I2C_BOARDINFO=y
> CONFIG_I2C_COMPAT=y
> CONFIG_I2C_CHARDEV=m
> CONFIG_I2C_MUX=m
> CONFIG_I2C_HELPER_AUTO=y
> CONFIG_I2C_ALGOBIT=m
> CONFIG_I2C_I801=y
> CONFIG_I2C_ISCH=m
> CONFIG_I2C_SCMI=y
> CONFIG_I2C_CROS_EC_TUNNEL=y
> CONFIG_I2C_STUB=m
> CONFIG_MFD_CROS_EC_I2C=y
> CONFIG_SND_SOC_I2C_AND_SPI=m
>
> Here is the result of evtest:
>
> zooko@spark~ $ sudo evtest
> No device specified, trying to scan all of /dev/input/event*
> Available devices:
> /dev/input/event0:  Lid Switch
> /dev/input/event1:  Power Button
> /dev/input/event2:  Sleep Button
> /dev/input/event3:  Sleep Button
> /dev/input/event4:  Power Button
> /dev/input/event5:  AT Translated Set 2 keyboard
> /dev/input/event6:  Video Bus
> /dev/input/event7:  Chromebook HD WebCam
> /dev/input/event8:  Samsung S Action Mouse ET-MP900D
> /dev/input/event9:  Jabra BIZ 2400 USB
> /dev/input/event10: Lite-On Technology Corp. Goldtouch USB Keyboard
> /dev/input/event11: Atmel maXTouch Touchpad
> /dev/input/event12: Atmel maXTouch Touchscreen
> /dev/input/event13: Lite-On Technology Corp. Goldtouch USB Keyboard
> Select the device event number [0-13]: 11
> Input driver version is 1.0.1
> Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
> Input device name: "Atmel maXTouch Touchpad"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 1 (EV_KEY)
> Event code 272 (BTN_LEFT)
> Event code 325 (BTN_TOOL_FINGER)
> Event code 328 (BTN_TOOL_QUINTTAP)
> Event code 330 (BTN_TOUCH)
> Event code 333 (BTN_TOOL_DOUBLETAP)
> Event code 334 (BTN_TOOL_TRIPLETAP)
> Event code 335 (BTN_TOOL_QUADTAP)
>   Event type 3 (EV_ABS)
> Event code 0 (ABS_X)
>   Value  0
>   Min0
>   Max 2039
>   Resolution  20
> Event code 1 (ABS_Y)
>   Value  0
>   Min0
>   Max 1359
>   Resolution  20
> Event code 24 (ABS_PRESSURE)
>   Value  0
>   Min0
>   Max  255
> Event code 47 (ABS_MT_SLOT)
>   Value  0
>   Min0
>   Max9
> Event code 48 (ABS_MT_TOUCH_MAJOR)
>   Value  0
>   Min0
>   Max  255
> Event code 53 (ABS_MT_POSITION_X)
>   Value  0
>   Min0
>   Max 2039
>   Resolution  20
> Event code 54 (ABS_MT_POSITION_Y)
>   Value  0
>   Min0
>   Max 1359
>   Resolution  20
> Event code 57 (ABS_MT_TRACKING_ID)
>   Value  0
>   Min0
>   Max65535
> Event code 58 (ABS_MT_PRESSURE)
>   Value  0
>   Min0
>   Max  255
> Properties:
>   Property type 0 (INPUT_PROP_POINTER)
>   Property type 2 (INPUT_PROP_BUTTONPAD)
>

Just to confirm: when you run evtest on the text console (i.e. not in
X) and touch the device, do you see any additional output besides the
properties?

Thanks.

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


Re: [PATCHv9 07/15] cec: add HDMI CEC framework

2015-10-13 Thread Russell King - ARM Linux
On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
> On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> > Surely you aren't proposing that drivers should write directly to
> > adap->phys_addr without calling some notification function that the
> > physical address has changed?
> 
> Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is
> enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is
> not set (i.e. the kernel takes care of this), then calling 
> CEC_ADAP_G_PHYS_ADDR
> returns the new physical address.

Okay, so when I see the EDID arrive, I should be doing:

phys = parse_hdmi_addr(block->edid);
cec->adap->phys_addr = phys;
cec_enable(cec->adap, true);

IOW, you _are_ expecting adap->phys_addr to be written, but only while
the adapter is disabled?

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] Input: improve autorepeat initialization

2015-10-13 Thread Petri Gynther
Hi Dmitry,

On Mon, Oct 12, 2015 at 12:04 PM, Petri Gynther  wrote:
> Allow driver to initialize its own values for input_dev->rep[REP_DELAY]
> and input_dev->rep[REP_PERIOD], but also use the software autorepeat
> functionality from input.c.
>
> For example, a HID driver could do:
>
> static void xyz_input_configured(struct hid_device *hid,
>  struct hid_input *hidinput)
> {
> hidinput->input->rep[REP_DELAY] = 400;
> hidinput->input->rep[REP_PERIOD] = 100;
> hidinput->input->softrepeat = true;
> }
>
> static struct hid_driver xyz_driver = {
> .input_configured = xyz_input_configured,
> }
>
> Signed-off-by: Petri Gynther 
> ---
>  drivers/input/input.c | 9 +++--
>  include/linux/input.h | 1 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 5391abd..a6f65c7 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -2106,13 +2106,18 @@ int input_register_device(struct input_dev *dev)
>
> /*
>  * If delay and period are pre-set by the driver, then autorepeating
> -* is handled by the driver itself and we don't do it in input.c.
> +* is handled by the driver itself and we don't do it in input.c
> +* unless the driver also requests softrepeat.
>  */
> if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
> -   dev->timer.data = (long) dev;
> +   dev->softrepeat = true;
> +   dev->timer.data = (unsigned long) dev;
> dev->timer.function = input_repeat_key;
> dev->rep[REP_DELAY] = 250;
> dev->rep[REP_PERIOD] = 33;

Please ignore this patch v2.
Better solution is to move the code from if-statement to an exported
function and call it here and from drivers when desired.
Sending patch v3 shortly.

> +   } else if (dev->softrepeat) {
> +   dev->timer.data = (unsigned long) dev;
> +   dev->timer.function = input_repeat_key;
> }
>
> if (!dev->getkeycode)
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 82ce323..2535948 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -150,6 +150,7 @@ struct input_dev {
>
> struct ff_device *ff;
>
> +   bool softrepeat;
> unsigned int repeat_key;
> struct timer_list timer;
>
> --
> 2.6.0.rc2.230.g3dd15c0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling

2015-10-13 Thread Russell King - ARM Linux
On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote:
> On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> > On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> >> From: Kamil Debski 
> >>
> >> Add handling of remote control events coming from the HDMI CEC bus.
> >> This patch includes a new keymap that maps values found in the CEC
> >> messages to the keys pressed and released. Also, a new protocol has
> >> been added to the core.
> >>
> >> Signed-off-by: Kamil Debski 
> >> Signed-off-by: Hans Verkuil 
> > 
> > (Added Mauro)
> > 
> > Hmm, how is rc-cec supposed to be loaded?
> 
> Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure 
> you've done
> that, just checking...)

CONFIG_RC_MAP=m

and yes, if depmod hadn't have been run, modprobing rc-cec would not
have worked - modprobe always looks up in the depmod information to
find out where the module is located, and also to determine any
dependencies.

> It's optional as I understand it, since you could configure the keytable from
> userspace instead of using this module.
> 
> For the record (just tried it), it does load fine on my setup.

Immediately after boot, I have:

# lsmod
Module  Size  Used by
...
coda   54685  0
v4l2_mem2mem   14517  1 coda
videobuf2_dma_contig 9478  1 coda
videobuf2_vmalloc   5529  1 coda
videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
cecd_dw_hdmi3129  0
# modprobe rc-cec
# lsmod
Module  Size  Used by
rc_cec  1785  0
...
coda   54685  0
v4l2_mem2mem   14517  1 coda
videobuf2_dma_contig 9478  1 coda
videobuf2_vmalloc   5529  1 coda
videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
cecd_dw_hdmi3129  0

So, rc-cec is perfectly loadable, it just doesn't get loaded at boot.
Manually loading it like this is useless though - I have to unload
cecd_dw_hdmi and then re-load it after rc-cec is loaded for rc-cec to
be seen.  At that point, (and with the help of a userspace program)
things start working as expected.

> BTW, I am still on the fence whether using the kernel RC subsystem is
> the right thing to do. There are a number of CEC RC commands that use
> extra parameters that cannot be mapped to the RC API, so you still
> need to handle those manually.

Even though it is a remote control which is being forwarded for the
most part, but there are operation codes which aren't related to
key presses specified by the standard.  I don't think there's anything
wrong with having a RC interface present, but allowing other interfaces
as a possibility is a good thing too - it allows a certain amount of
flexibility.

For example, with rc-cec loaded and properly bound, I can control at
least rhythmbox within gnome using the TVs remote control with no
modifications - and that happens because the X server passes on the
events it receives via the event device.

Given the range of media applications, I think that's key - it needs
to at least have the capability to plug into the existing ways of doing
things, even if those ways are not perfect.

> Perhaps I should split it off into a separate patch and keep it out
> from the initial pull request once we're ready for that.

I'm biased because it is an enablement feature - it allows CEC to work
out of the box with at least some existing media apps. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-13 Thread Russell King - ARM Linux
On Mon, Oct 12, 2015 at 02:39:42PM +0200, Hans Verkuil wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
> > The possible status values that are implemented in the CEC framework
> > are following:
> > 
> > +/* cec status field */
> > +#define CEC_TX_STATUS_OK   (0)
> > +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> > +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> > +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> > +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> > +#define CEC_RX_STATUS_READY(0)
> > 
> > The only two ones I could match with the Exynos CEC module status bits are
> > CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> > 
> > The status bits in Exynos HW are:
> > - Tx_Error
> > - Tx_Done
> > - Tx_Transferring
> > - Tx_Running
> > - Tx_Bytes_Transferred
> > 
> > - Tx_Wait
> > - Tx_Sending_Status_Bit
> > - Tx_Sending_Hdr_Blk
> > - Tx_Sending_Data_Blk
> > - Tx_Latest_Initiator
> > 
> > - Tx_Wait_SFT_Succ
> > - Tx_Wait_SFT_New
> > - Tx_Wait_SFT_Retran
> > - Tx_Retrans_Cnt
> > - Tx_ACK_Failed
> 
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?
> 
> It does look that way...

For the Synopsis DW CEC, I have:

Bit Field   Description
4   ERROR_INIT  An error is detected on cec line (for initiator only).
3   ARB_LOSTThe initiator losses the CEC line arbitration to a second
initiator. (specification CEC 9).
2   NACKA frame is not acknowledged in a directly addressed message.
Or a frame is negatively acknowledged in a broadcast message
(for initiator only).
0   DONEThe current transmission is successful (for initiator only).

That's about as much of a description that there is for this hardware.
Quite what comprises an "ERROR_INIT", I don't know.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] Input: improve autorepeat initialization

2015-10-13 Thread Petri Gynther
Add new function input_enable_softrepeat() that allows drivers to
initialize their own values for input_dev->rep[REP_DELAY] and
input_dev->rep[REP_PERIOD], but also use the software autorepeat
functionality from input.c.

For example, a HID driver could do:

static void xyz_input_configured(struct hid_device *hid,
 struct hid_input *hidinput)
{
input_enable_softrepeat(hidinput->input, 400, 100);
}

static struct hid_driver xyz_driver = {
.input_configured = xyz_input_configured,
}

Signed-off-by: Petri Gynther 
---
 drivers/input/input.c | 25 +++--
 include/linux/input.h |  2 ++
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 5391abd..8806059 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -2045,6 +2045,23 @@ static void devm_input_device_unregister(struct device 
*dev, void *res)
 }
 
 /**
+ * input_enable_softrepeat - enable software autorepeat
+ * @dev: input device
+ * @delay: repeat delay
+ * @period: repeat period
+ *
+ * Enable software autorepeat on the input device.
+ */
+void input_enable_softrepeat(struct input_dev *dev, int delay, int period)
+{
+   dev->timer.data = (unsigned long) dev;
+   dev->timer.function = input_repeat_key;
+   dev->rep[REP_DELAY] = delay;
+   dev->rep[REP_PERIOD] = period;
+}
+EXPORT_SYMBOL(input_enable_softrepeat);
+
+/**
  * input_register_device - register device with input core
  * @dev: device to be registered
  *
@@ -2108,12 +2125,8 @@ int input_register_device(struct input_dev *dev)
 * If delay and period are pre-set by the driver, then autorepeating
 * is handled by the driver itself and we don't do it in input.c.
 */
-   if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
-   dev->timer.data = (long) dev;
-   dev->timer.function = input_repeat_key;
-   dev->rep[REP_DELAY] = 250;
-   dev->rep[REP_PERIOD] = 33;
-   }
+   if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD])
+   input_enable_softrepeat(dev, 250, 33);
 
if (!dev->getkeycode)
dev->getkeycode = input_default_getkeycode;
diff --git a/include/linux/input.h b/include/linux/input.h
index 82ce323..1e96769 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -469,6 +469,8 @@ int input_get_keycode(struct input_dev *dev, struct 
input_keymap_entry *ke);
 int input_set_keycode(struct input_dev *dev,
  const struct input_keymap_entry *ke);
 
+void input_enable_softrepeat(struct input_dev *dev, int delay, int period);
+
 extern struct class input_class;
 
 /**
-- 
2.6.0.rc2.230.g3dd15c0

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


[PATCH] HID: reject input outside logical range only if null state is set

2015-10-13 Thread rnd
Kernel 3.19.0 one-line fix for an issue in drivers/hid/hid-input.c where 
USB HID control null state flag is not checked when rejecting inputs 
outside logical minimum-maximum range. The check should be made as per 
USB HID specification 1.11, section 6.2.2.5, p.31. I have no resources 
for large-scale testing, but this fixes problems with the game 
controller I have (INNEX NES Controller USB).


More details: https://bugzilla.kernel.org/show_bug.cgi?id=68621


Signed-Off-by: Valtteri Heikkilä 
--- a/drivers/hid/hid-input.c 2015-05-25 09:58:49.743527141 +0800
+++ b/drivers/hid/hid-input.c 2015-05-25 11:04:13.201191432 +0800
@@ -1097,6 +1097,7 @@
* don't specify logical min and max.
*/
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
+ (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
(field->logical_minimum < field->logical_maximum) &&
(value < field->logical_minimum ||
value > field->logical_maximum)) {



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