[PATCH] Input: pixcir_i2c_ts: remove wakeirq related code from pixcir driver
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
> -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
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
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
> -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"
> -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
> -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
> -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 Nocerawrote: > > 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
> -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)
> -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 MerkerReviewed-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
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
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
Hi Andrew, [resurrecting this following a ping from Andrew] On Thu, Jul 23, 2015 at 12:20 PM, Andrew Shadurawrote: > 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
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
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
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 GereckeSigned-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
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
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
This patch adds wake up support to GPIO rotary encoders. Signed-off-by: Sylvain RochetReviewed-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
This patch adds property wakeup-source to GPIO rotary encoders. Signed-off-by: Sylvain RochetReviewed-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
Hi Zooko, On Tue, Oct 13, 2015 at 10:39 AM, Zooko Wilcox-O'Hearnwrote: > 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
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
Hi Dmitry, On Mon, Oct 12, 2015 at 12:04 PM, Petri Gyntherwrote: > 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
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
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
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
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