* Re: [PATCH] HID: add keyboard input assist hid usages
From: Olivier Gay @ 2014-10-18 15:55 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Jiri Kosina, Mathieu Meisser
In-Reply-To: <20141017235937.GB22238@dtor-ws>
Hi Dmitry,
a potential consumer could be Android and Android IMEs, this would add
the ability for a HID device to select and control the suggested words
in the word prediction system when typing.
Olivier
On Fri, Oct 17, 2014 at 4:59 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sat, Oct 18, 2014 at 01:53:39AM +0200, Olivier Gay wrote:
>> Add keyboard input assist controls usages from approved
>> hid usage table request HUTTR42:
>> http://www.usb.org/developers/hidpage/HUTRR42c.pdf
>>
>> Signed-off-by: Olivier Gay <ogay@logitech.com>
>> ---
>>
>> Hi all,
>>
>> this patch adds some currently missing hid usages to the
>> hid system.
>
> Who is going to be using these codes? Do we have userspace consumers?
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH 3/3] input: stmpe: bias keypad columns properly
From: Linus Walleij @ 2014-10-18 12:56 UTC (permalink / raw)
To: Samuel Ortiz, Lee Jones, Dmitry Torokhov, linux-kernel,
linux-input
Cc: Linus Walleij
All keypad column pins used as inputs should be pulled up
on the STMPE24xx, but this is not done by the current driver.
Add some logic that will do this properly. The STMPE1601 also
has a keypad controller, but explicitly does *NOT* require
you to set up any pull-ups.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/input/keyboard/stmpe-keypad.c | 37 +++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/stmpe-keypad.c b/drivers/input/keyboard/stmpe-keypad.c
index d46391f48310..fe6e3f22eed7 100644
--- a/drivers/input/keyboard/stmpe-keypad.c
+++ b/drivers/input/keyboard/stmpe-keypad.c
@@ -52,6 +52,7 @@
* struct stmpe_keypad_variant - model-specific attributes
* @auto_increment: whether the KPC_DATA_BYTE register address
* auto-increments on multiple read
+ * @set_pullup: whether the pins need to have their pull-ups set
* @num_data: number of data bytes
* @num_normal_data: number of normal keys' data bytes
* @max_cols: maximum number of columns supported
@@ -61,6 +62,7 @@
*/
struct stmpe_keypad_variant {
bool auto_increment;
+ bool set_pullup;
int num_data;
int num_normal_data;
int max_cols;
@@ -81,6 +83,7 @@ static const struct stmpe_keypad_variant stmpe_keypad_variants[] = {
},
[STMPE2401] = {
.auto_increment = false,
+ .set_pullup = true,
.num_data = 3,
.num_normal_data = 2,
.max_cols = 8,
@@ -90,6 +93,7 @@ static const struct stmpe_keypad_variant stmpe_keypad_variants[] = {
},
[STMPE2403] = {
.auto_increment = true,
+ .set_pullup = true,
.num_data = 5,
.num_normal_data = 3,
.max_cols = 8,
@@ -185,7 +189,10 @@ static int stmpe_keypad_altfunc_init(struct stmpe_keypad *keypad)
unsigned int col_gpios = variant->col_gpios;
unsigned int row_gpios = variant->row_gpios;
struct stmpe *stmpe = keypad->stmpe;
+ u8 pureg = stmpe->regs[STMPE_IDX_GPPUR_LSB];
unsigned int pins = 0;
+ unsigned int pu_pins = 0;
+ int ret;
int i;
/*
@@ -202,8 +209,10 @@ static int stmpe_keypad_altfunc_init(struct stmpe_keypad *keypad)
for (i = 0; i < variant->max_cols; i++) {
int num = __ffs(col_gpios);
- if (keypad->cols & (1 << i))
+ if (keypad->cols & (1 << i)) {
pins |= 1 << num;
+ pu_pins |= 1 << num;
+ }
col_gpios &= ~(1 << num);
}
@@ -217,7 +226,31 @@ static int stmpe_keypad_altfunc_init(struct stmpe_keypad *keypad)
row_gpios &= ~(1 << num);
}
- return stmpe_set_altfunc(stmpe, pins, STMPE_BLOCK_KEYPAD);
+ ret = stmpe_set_altfunc(stmpe, pins, STMPE_BLOCK_KEYPAD);
+ if (ret)
+ return ret;
+
+ /*
+ * On STMPE24xx, set pin bias to pull-up on all keypad input
+ * pins (columns), this incidentally happen to be maximum 8 pins
+ * and placed at GPIO0-7 so only the LSB of the pull up register
+ * ever needs to be written.
+ */
+ if (variant->set_pullup) {
+ u8 val;
+
+ ret = stmpe_reg_read(stmpe, pureg);
+ if (ret)
+ return ret;
+
+ /* Do not touch unused pins, may be used for GPIO */
+ val = ret & ~pu_pins;
+ val |= pu_pins;
+
+ ret = stmpe_reg_write(stmpe, pureg, val);
+ }
+
+ return 0;
}
static int stmpe_keypad_chip_init(struct stmpe_keypad *keypad)
--
1.9.3
^ permalink raw reply related
* [PATCH 2/3] input: stmpe: enforce device tree only mode
From: Linus Walleij @ 2014-10-18 12:56 UTC (permalink / raw)
To: Samuel Ortiz, Lee Jones, Dmitry Torokhov, linux-kernel,
linux-input
Cc: Linus Walleij
The STMPE keypad controller is only used with device tree
configured systems, so force the configuration to come from
device tree only, and now actually get the rows and cols from
the device tree too.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/input/stmpe-keypad.txt | 2 +
drivers/input/keyboard/Kconfig | 1 +
drivers/input/keyboard/stmpe-keypad.c | 104 +++++++++------------
include/linux/mfd/stmpe.h | 20 ----
4 files changed, 48 insertions(+), 79 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
index 1b97222e8a0b..12bb771d66d4 100644
--- a/Documentation/devicetree/bindings/input/stmpe-keypad.txt
+++ b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
@@ -8,6 +8,8 @@ Optional properties:
- debounce-interval : Debouncing interval time in milliseconds
- st,scan-count : Scanning cycles elapsed before key data is updated
- st,no-autorepeat : If specified device will not autorepeat
+ - keypad,num-rows : See ./matrix-keymap.txt
+ - keypad,num-columns : See ./matrix-keymap.txt
Example:
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a3958c63d7d5..753d61c0a3a9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -559,6 +559,7 @@ config KEYBOARD_SH_KEYSC
config KEYBOARD_STMPE
tristate "STMPE keypad support"
depends on MFD_STMPE
+ depends on OF
select INPUT_MATRIXKMAP
help
Say Y here if you want to use the keypad controller on STMPE I/O
diff --git a/drivers/input/keyboard/stmpe-keypad.c b/drivers/input/keyboard/stmpe-keypad.c
index ef5e67fb567e..d46391f48310 100644
--- a/drivers/input/keyboard/stmpe-keypad.c
+++ b/drivers/input/keyboard/stmpe-keypad.c
@@ -45,7 +45,7 @@
#define STMPE_KEYPAD_MAX_ROWS 8
#define STMPE_KEYPAD_MAX_COLS 8
#define STMPE_KEYPAD_ROW_SHIFT 3
-#define STMPE_KEYPAD_KEYMAP_SIZE \
+#define STMPE_KEYPAD_KEYMAP_MAX_SIZE \
(STMPE_KEYPAD_MAX_ROWS * STMPE_KEYPAD_MAX_COLS)
/**
@@ -99,16 +99,30 @@ static const struct stmpe_keypad_variant stmpe_keypad_variants[] = {
},
};
+/**
+ * struct stmpe_keypad - STMPE keypad state container
+ * @stmpe: pointer to parent STMPE device
+ * @input: spawned input device
+ * @variant: STMPE variant
+ * @debounce_ms: debounce interval, in ms. Maximum is
+ * %STMPE_KEYPAD_MAX_DEBOUNCE.
+ * @scan_count: number of key scanning cycles to confirm key data.
+ * Maximum is %STMPE_KEYPAD_MAX_SCAN_COUNT.
+ * @no_autorepeat: disable key autorepeat
+ * @rows: bitmask for the rows
+ * @cols: bitmask for the columns
+ * @keymap: the keymap
+ */
struct stmpe_keypad {
struct stmpe *stmpe;
struct input_dev *input;
const struct stmpe_keypad_variant *variant;
- const struct stmpe_keypad_platform_data *plat;
-
+ unsigned int debounce_ms;
+ unsigned int scan_count;
+ bool no_autorepeat;
unsigned int rows;
unsigned int cols;
-
- unsigned short keymap[STMPE_KEYPAD_KEYMAP_SIZE];
+ unsigned short keymap[STMPE_KEYPAD_KEYMAP_MAX_SIZE];
};
static int stmpe_keypad_read_data(struct stmpe_keypad *keypad, u8 *data)
@@ -208,15 +222,14 @@ static int stmpe_keypad_altfunc_init(struct stmpe_keypad *keypad)
static int stmpe_keypad_chip_init(struct stmpe_keypad *keypad)
{
- const struct stmpe_keypad_platform_data *plat = keypad->plat;
const struct stmpe_keypad_variant *variant = keypad->variant;
struct stmpe *stmpe = keypad->stmpe;
int ret;
- if (plat->debounce_ms > STMPE_KEYPAD_MAX_DEBOUNCE)
+ if (keypad->debounce_ms > STMPE_KEYPAD_MAX_DEBOUNCE)
return -EINVAL;
- if (plat->scan_count > STMPE_KEYPAD_MAX_SCAN_COUNT)
+ if (keypad->scan_count > STMPE_KEYPAD_MAX_SCAN_COUNT)
return -EINVAL;
ret = stmpe_enable(stmpe, STMPE_BLOCK_KEYPAD);
@@ -245,7 +258,7 @@ static int stmpe_keypad_chip_init(struct stmpe_keypad *keypad)
ret = stmpe_set_bits(stmpe, STMPE_KPC_CTRL_MSB,
STMPE_KPC_CTRL_MSB_SCAN_COUNT,
- plat->scan_count << 4);
+ keypad->scan_count << 4);
if (ret < 0)
return ret;
@@ -253,17 +266,18 @@ static int stmpe_keypad_chip_init(struct stmpe_keypad *keypad)
STMPE_KPC_CTRL_LSB_SCAN |
STMPE_KPC_CTRL_LSB_DEBOUNCE,
STMPE_KPC_CTRL_LSB_SCAN |
- (plat->debounce_ms << 1));
+ (keypad->debounce_ms << 1));
}
-static void stmpe_keypad_fill_used_pins(struct stmpe_keypad *keypad)
+static void stmpe_keypad_fill_used_pins(struct stmpe_keypad *keypad,
+ u32 used_rows, u32 used_cols)
{
int row, col;
- for (row = 0; row < STMPE_KEYPAD_MAX_ROWS; row++) {
- for (col = 0; col < STMPE_KEYPAD_MAX_COLS; col++) {
+ for (row = 0; row < used_rows; row++) {
+ for (col = 0; col < used_cols; col++) {
int code = MATRIX_SCAN_CODE(row, col,
- STMPE_KEYPAD_ROW_SHIFT);
+ STMPE_KEYPAD_ROW_SHIFT);
if (keypad->keymap[code] != KEY_RESERVED) {
keypad->rows |= 1 << row;
keypad->cols |= 1 << col;
@@ -272,51 +286,17 @@ static void stmpe_keypad_fill_used_pins(struct stmpe_keypad *keypad)
}
}
-#ifdef CONFIG_OF
-static const struct stmpe_keypad_platform_data *
-stmpe_keypad_of_probe(struct device *dev)
-{
- struct device_node *np = dev->of_node;
- struct stmpe_keypad_platform_data *plat;
-
- if (!np)
- return ERR_PTR(-ENODEV);
-
- plat = devm_kzalloc(dev, sizeof(*plat), GFP_KERNEL);
- if (!plat)
- return ERR_PTR(-ENOMEM);
-
- of_property_read_u32(np, "debounce-interval", &plat->debounce_ms);
- of_property_read_u32(np, "st,scan-count", &plat->scan_count);
-
- plat->no_autorepeat = of_property_read_bool(np, "st,no-autorepeat");
-
- return plat;
-}
-#else
-static inline const struct stmpe_keypad_platform_data *
-stmpe_keypad_of_probe(struct device *dev)
-{
- return ERR_PTR(-EINVAL);
-}
-#endif
-
static int stmpe_keypad_probe(struct platform_device *pdev)
{
struct stmpe *stmpe = dev_get_drvdata(pdev->dev.parent);
- const struct stmpe_keypad_platform_data *plat;
+ struct device_node *np = pdev->dev.of_node;
struct stmpe_keypad *keypad;
struct input_dev *input;
+ u32 rows;
+ u32 cols;
int error;
int irq;
- plat = stmpe->pdata->keypad;
- if (!plat) {
- plat = stmpe_keypad_of_probe(&pdev->dev);
- if (IS_ERR(plat))
- return PTR_ERR(plat);
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
@@ -326,6 +306,13 @@ static int stmpe_keypad_probe(struct platform_device *pdev)
if (!keypad)
return -ENOMEM;
+ keypad->stmpe = stmpe;
+ keypad->variant = &stmpe_keypad_variants[stmpe->partnum];
+
+ of_property_read_u32(np, "debounce-interval", &keypad->debounce_ms);
+ of_property_read_u32(np, "st,scan-count", &keypad->scan_count);
+ keypad->no_autorepeat = of_property_read_bool(np, "st,no-autorepeat");
+
input = devm_input_allocate_device(&pdev->dev);
if (!input)
return -ENOMEM;
@@ -334,23 +321,22 @@ static int stmpe_keypad_probe(struct platform_device *pdev)
input->id.bustype = BUS_I2C;
input->dev.parent = &pdev->dev;
- error = matrix_keypad_build_keymap(plat->keymap_data, NULL,
- STMPE_KEYPAD_MAX_ROWS,
- STMPE_KEYPAD_MAX_COLS,
+ error = matrix_keypad_parse_of_params(&pdev->dev, &rows, &cols);
+ if (error)
+ return error;
+
+ error = matrix_keypad_build_keymap(NULL, NULL, rows, cols,
keypad->keymap, input);
if (error)
return error;
input_set_capability(input, EV_MSC, MSC_SCAN);
- if (!plat->no_autorepeat)
+ if (!keypad->no_autorepeat)
__set_bit(EV_REP, input->evbit);
- stmpe_keypad_fill_used_pins(keypad);
+ stmpe_keypad_fill_used_pins(keypad, rows, cols);
- keypad->stmpe = stmpe;
- keypad->plat = plat;
keypad->input = input;
- keypad->variant = &stmpe_keypad_variants[stmpe->partnum];
error = stmpe_keypad_chip_init(keypad);
if (error < 0)
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index 976e1a390177..dd908fea8c5b 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -116,24 +116,6 @@ extern int stmpe_set_altfunc(struct stmpe *stmpe, u32 pins,
extern int stmpe_enable(struct stmpe *stmpe, unsigned int blocks);
extern int stmpe_disable(struct stmpe *stmpe, unsigned int blocks);
-struct matrix_keymap_data;
-
-/**
- * struct stmpe_keypad_platform_data - STMPE keypad platform data
- * @keymap_data: key map table and size
- * @debounce_ms: debounce interval, in ms. Maximum is
- * %STMPE_KEYPAD_MAX_DEBOUNCE.
- * @scan_count: number of key scanning cycles to confirm key data.
- * Maximum is %STMPE_KEYPAD_MAX_SCAN_COUNT.
- * @no_autorepeat: disable key autorepeat
- */
-struct stmpe_keypad_platform_data {
- const struct matrix_keymap_data *keymap_data;
- unsigned int debounce_ms;
- unsigned int scan_count;
- bool no_autorepeat;
-};
-
#define STMPE_GPIO_NOREQ_811_TOUCH (0xf0)
/**
@@ -202,7 +184,6 @@ struct stmpe_ts_platform_data {
* @irq_gpio: gpio number over which irq will be requested (significant only if
* irq_over_gpio is true)
* @gpio: GPIO-specific platform data
- * @keypad: keypad-specific platform data
* @ts: touchscreen-specific platform data
*/
struct stmpe_platform_data {
@@ -215,7 +196,6 @@ struct stmpe_platform_data {
int autosleep_timeout;
struct stmpe_gpio_platform_data *gpio;
- struct stmpe_keypad_platform_data *keypad;
struct stmpe_ts_platform_data *ts;
};
--
1.9.3
^ permalink raw reply related
* [PATCH 1/3] mfd: stmpe: add pull up/down register offsets for STMPE
From: Linus Walleij @ 2014-10-18 12:56 UTC (permalink / raw)
To: Samuel Ortiz, Lee Jones, Dmitry Torokhov, linux-kernel,
linux-input
Cc: Linus Walleij
This adds the register offsets for pull up/down for the STMPE
1601, 1801 and 24xx expanders. This is used to bias GPIO lines
and keypad lines.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Hi Sam, Lee: I think you should just ACK this so Dmitry can take the
patch series through the input tree, where the registers need to be
used to enable the keypad on the STMPE2401.
---
drivers/mfd/stmpe.c | 4 ++++
drivers/mfd/stmpe.h | 3 +++
include/linux/mfd/stmpe.h | 2 ++
3 files changed, 9 insertions(+)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index 3004d5ba0b82..497505bad4c4 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -547,6 +547,7 @@ static const u8 stmpe1601_regs[] = {
[STMPE_IDX_GPDR_LSB] = STMPE1601_REG_GPIO_SET_DIR_LSB,
[STMPE_IDX_GPRER_LSB] = STMPE1601_REG_GPIO_RE_LSB,
[STMPE_IDX_GPFER_LSB] = STMPE1601_REG_GPIO_FE_LSB,
+ [STMPE_IDX_GPPUR_LSB] = STMPE1601_REG_GPIO_PU_LSB,
[STMPE_IDX_GPAFR_U_MSB] = STMPE1601_REG_GPIO_AF_U_MSB,
[STMPE_IDX_IEGPIOR_LSB] = STMPE1601_REG_INT_EN_GPIO_MASK_LSB,
[STMPE_IDX_ISGPIOR_MSB] = STMPE1601_REG_INT_STA_GPIO_MSB,
@@ -695,6 +696,7 @@ static const u8 stmpe1801_regs[] = {
[STMPE_IDX_GPDR_LSB] = STMPE1801_REG_GPIO_SET_DIR_LOW,
[STMPE_IDX_GPRER_LSB] = STMPE1801_REG_GPIO_RE_LOW,
[STMPE_IDX_GPFER_LSB] = STMPE1801_REG_GPIO_FE_LOW,
+ [STMPE_IDX_GPPUR_LSB] = STMPE1801_REG_GPIO_PULL_UP_LOW,
[STMPE_IDX_IEGPIOR_LSB] = STMPE1801_REG_INT_EN_GPIO_MASK_LOW,
[STMPE_IDX_ISGPIOR_LSB] = STMPE1801_REG_INT_STA_GPIO_LOW,
};
@@ -778,6 +780,8 @@ static const u8 stmpe24xx_regs[] = {
[STMPE_IDX_GPDR_LSB] = STMPE24XX_REG_GPDR_LSB,
[STMPE_IDX_GPRER_LSB] = STMPE24XX_REG_GPRER_LSB,
[STMPE_IDX_GPFER_LSB] = STMPE24XX_REG_GPFER_LSB,
+ [STMPE_IDX_GPPUR_LSB] = STMPE24XX_REG_GPPUR_LSB,
+ [STMPE_IDX_GPPDR_LSB] = STMPE24XX_REG_GPPDR_LSB,
[STMPE_IDX_GPAFR_U_MSB] = STMPE24XX_REG_GPAFR_U_MSB,
[STMPE_IDX_IEGPIOR_LSB] = STMPE24XX_REG_IEGPIOR_LSB,
[STMPE_IDX_ISGPIOR_MSB] = STMPE24XX_REG_ISGPIOR_MSB,
diff --git a/drivers/mfd/stmpe.h b/drivers/mfd/stmpe.h
index bee0abf82040..84adb46b3e2f 100644
--- a/drivers/mfd/stmpe.h
+++ b/drivers/mfd/stmpe.h
@@ -188,6 +188,7 @@ int stmpe_remove(struct stmpe *stmpe);
#define STMPE1601_REG_GPIO_ED_MSB 0x8A
#define STMPE1601_REG_GPIO_RE_LSB 0x8D
#define STMPE1601_REG_GPIO_FE_LSB 0x8F
+#define STMPE1601_REG_GPIO_PU_LSB 0x91
#define STMPE1601_REG_GPIO_AF_U_MSB 0x92
#define STMPE1601_SYS_CTRL_ENABLE_GPIO (1 << 3)
@@ -276,6 +277,8 @@ int stmpe_remove(struct stmpe *stmpe);
#define STMPE24XX_REG_GPEDR_MSB 0x8C
#define STMPE24XX_REG_GPRER_LSB 0x91
#define STMPE24XX_REG_GPFER_LSB 0x94
+#define STMPE24XX_REG_GPPUR_LSB 0x97
+#define STMPE24XX_REG_GPPDR_LSB 0x9a
#define STMPE24XX_REG_GPAFR_U_MSB 0x9B
#define STMPE24XX_SYS_CTRL_ENABLE_GPIO (1 << 3)
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index af9e1b07a630..976e1a390177 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -50,6 +50,8 @@ enum {
STMPE_IDX_GPEDR_MSB,
STMPE_IDX_GPRER_LSB,
STMPE_IDX_GPFER_LSB,
+ STMPE_IDX_GPPUR_LSB,
+ STMPE_IDX_GPPDR_LSB,
STMPE_IDX_GPAFR_U_MSB,
STMPE_IDX_IEGPIOR_LSB,
STMPE_IDX_ISGPIOR_LSB,
--
1.9.3
^ permalink raw reply related
* [PATCH] input: stmpe: fix valid key line bitmask
From: Linus Walleij @ 2014-10-18 12:52 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Linus Walleij
The bitmask comment says it will enable GPIO 8-14 and 16-20
for keypad use, but it actually enables GPIO 8-11 and 13-20
due to a bit error.
Instead of masking of the "hole" at GPIO 12 (which is used
for keypad output 4) mask of the proper "hole" at GPIO 15.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Hi Dmitry, this is for fixes I think.
---
drivers/input/keyboard/stmpe-keypad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/stmpe-keypad.c b/drivers/input/keyboard/stmpe-keypad.c
index c6727dda68f2..ef5e67fb567e 100644
--- a/drivers/input/keyboard/stmpe-keypad.c
+++ b/drivers/input/keyboard/stmpe-keypad.c
@@ -86,7 +86,7 @@ static const struct stmpe_keypad_variant stmpe_keypad_variants[] = {
.max_cols = 8,
.max_rows = 12,
.col_gpios = 0x0000ff, /* GPIO 0 - 7*/
- .row_gpios = 0x1fef00, /* GPIO 8-14, 16-20 */
+ .row_gpios = 0x1f7f00, /* GPIO 8-14, 16-20 */
},
[STMPE2403] = {
.auto_increment = true,
--
1.9.3
^ permalink raw reply related
* Problems with Wacom Intuos PT M (CTH680) on FreeBSD
From: Denis Akiyakov @ 2014-10-18 10:56 UTC (permalink / raw)
To: linux-input
Hello,
I'm using FreeBSD 10.1 and FreeBSD use webcamd witch contain linux wacom
driver to provide wacom tablets support. More info here:
http://www.selasky.org/hans_petter/video4bsd/ or
http://www.freshports.org/multimedia/webcamd/
I've got latest version of webcamd and Wacom device CTH680, but device
isn't working correct.
dmesg:
ugen2.3: <Wacom Co.,Ltd.> at usbus2
ums0: <Wacom Co.,Ltd. Intuos PTM, class 0/0, rev 2.00/1.00, addr 3> on
usbus2
uhid2: <Wacom Co.,Ltd. Intuos PTM, class 0/0, rev 2.00/1.00, addr 3> on
usbus2
uhid3: <Wacom Co.,Ltd. Intuos PTM, class 0/0, rev 2.00/1.00, addr 3> on
usbus2
here are two outputs from webcamd:
first (/usr/local/sbin/webcamd -i 0 -d ugen2.3 -U webcamd -G webcamd -H):
: USB HID core driver
Linux video capture interface: v2.00
lirc_dev: IR Remote Control driver registered, major 14
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR LIRC bridge handler initialized
IR XMP protocol handler initialized
uvcvideo: Unable to create debugfs directory
USB Video Class driver (1.1.1)
cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
au0828 driver loaded
pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
pvrusb2: Debug mask is 31 (0x1f)
USBVision USB Video Device Driver for Linux : 0.9.11
em28xx: Registered (Em28xx v4l2 Extension) extension
em28xx: Registered (Em28xx dvb Extension) extension
Attached to ugen2.3[0]
DBG: 0003:056A:0303.0001: Kicking head 1 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 2 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 3 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 4 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 5 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 6 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 7 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 8 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 9 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 10 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 11 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 12 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 13 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 14 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 15 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 16 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 17 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 18 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 19 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 20 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 21 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
INFO: 0003:056A:0303.0001: П│F: USB HID v1.10 Device [Wacom Co.,Ltd.
Intuos PTM] on usb-/dev/usb-/dev/usb/input0
Waiting for HAL USB device.
Creating /dev/input/event0
#------------------------------------------
second (/usr/local/sbin/webcamd -i 1 -d ugen2.3 -U webcamd -G webcamd -H):
#------------------------------------------
: USB HID core driver
Linux video capture interface: v2.00
lirc_dev: IR Remote Control driver registered, major 14
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR LIRC bridge handler initialized
IR XMP protocol handler initialized
uvcvideo: Unable to create debugfs directory
USB Video Class driver (1.1.1)
cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
au0828 driver loaded
pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
pvrusb2: Debug mask is 31 (0x1f)
USBVision USB Video Device Driver for Linux : 0.9.11
em28xx: Registered (Em28xx v4l2 Extension) extension
em28xx: Registered (Em28xx dvb Extension) extension
Attached to ugen2.3[1]
DBG: 0003:056A:0303.0001: Kicking head 1 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
DBG: 0003:056A:0303.0001: Kicking head 2 tail 0
ERR: 0003:056A:0303.0001: usb_submit_urb(ctrl) failed: -32
INFO: 0003:056A:0303.0001: П│F: USB HID v1.10 Device [Wacom Co.,Ltd.
Intuos PTM] on usb-/dev/usb-/dev/usb/input1
Waiting for HAL USB device.
Creating /dev/input/event1
Creating /dev/input/event2
Creating /dev/input/js0
At the end, sometimes after few manipulations the touch by fingers
starts working. Pen never works.
Can anyone help to resolve this problem? If you need other logs, please ask.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] HID: add keyboard input assist hid usages
From: Olivier Gay @ 2014-10-17 23:53 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, Dmitry Torokhov, Mathieu Meisser, Olivier Gay
Add keyboard input assist controls usages from approved
hid usage table request HUTTR42:
http://www.usb.org/developers/hidpage/HUTRR42c.pdf
Signed-off-by: Olivier Gay <ogay@logitech.com>
---
Hi all,
this patch adds some currently missing hid usages to the
hid system.
Best regards,
Olivier
drivers/hid/hid-debug.c | 6 ++++++
drivers/hid/hid-input.c | 7 +++++++
include/uapi/linux/input.h | 7 +++++++
3 files changed, 20 insertions(+)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 84c3cb1..8bf61d2 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -946,6 +946,12 @@ static const char *keys[KEY_MAX + 1] = {
[KEY_BRIGHTNESS_MIN] = "BrightnessMin",
[KEY_BRIGHTNESS_MAX] = "BrightnessMax",
[KEY_BRIGHTNESS_AUTO] = "BrightnessAuto",
+ [KEY_KBDINPUTASSIST_PREV] = "KbdInputAssistPrev",
+ [KEY_KBDINPUTASSIST_NEXT] = "KbdInputAssistNext",
+ [KEY_KBDINPUTASSIST_PREVGROUP] = "KbdInputAssistPrevGroup",
+ [KEY_KBDINPUTASSIST_NEXTGROUP] = "KbdInputAssistNextGroup",
+ [KEY_KBDINPUTASSIST_ACCEPT] = "KbdInputAssistAccept",
+ [KEY_KBDINPUTASSIST_CANCEL] = "KbdInputAssistCancel",
};
static const char *relatives[REL_MAX + 1] = {
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 2df7fdd..56c6c30 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -862,6 +862,13 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
case 0x28b: map_key_clear(KEY_FORWARDMAIL); break;
case 0x28c: map_key_clear(KEY_SEND); break;
+ case 0x2c7: map_key_clear(KEY_KBDINPUTASSIST_PREV); break;
+ case 0x2c8: map_key_clear(KEY_KBDINPUTASSIST_NEXT); break;
+ case 0x2c9: map_key_clear(KEY_KBDINPUTASSIST_PREVGROUP); break;
+ case 0x2ca: map_key_clear(KEY_KBDINPUTASSIST_NEXTGROUP); break;
+ case 0x2cb: map_key_clear(KEY_KBDINPUTASSIST_ACCEPT); break;
+ case 0x2cc: map_key_clear(KEY_KBDINPUTASSIST_CANCEL); break;
+
default: goto ignore;
}
break;
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 19df18c..9be8c13 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -738,6 +738,13 @@ struct input_keymap_entry {
#define KEY_BRIGHTNESS_MIN 0x250 /* Set Brightness to Minimum */
#define KEY_BRIGHTNESS_MAX 0x251 /* Set Brightness to Maximum */
+#define KEY_KBDINPUTASSIST_PREV 0x260
+#define KEY_KBDINPUTASSIST_NEXT 0x261
+#define KEY_KBDINPUTASSIST_PREVGROUP 0x262
+#define KEY_KBDINPUTASSIST_NEXTGROUP 0x263
+#define KEY_KBDINPUTASSIST_ACCEPT 0x264
+#define KEY_KBDINPUTASSIST_CANCEL 0x265
+
#define BTN_TRIGGER_HAPPY 0x2c0
#define BTN_TRIGGER_HAPPY1 0x2c0
#define BTN_TRIGGER_HAPPY2 0x2c1
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] HID: add keyboard input assist hid usages
From: Dmitry Torokhov @ 2014-10-17 23:59 UTC (permalink / raw)
To: Olivier Gay; +Cc: linux-input, Jiri Kosina, Mathieu Meisser
In-Reply-To: <1413590019-1829-1-git-send-email-ogay@logitech.com>
On Sat, Oct 18, 2014 at 01:53:39AM +0200, Olivier Gay wrote:
> Add keyboard input assist controls usages from approved
> hid usage table request HUTTR42:
> http://www.usb.org/developers/hidpage/HUTRR42c.pdf
>
> Signed-off-by: Olivier Gay <ogay@logitech.com>
> ---
>
> Hi all,
>
> this patch adds some currently missing hid usages to the
> hid system.
Who is going to be using these codes? Do we have userspace consumers?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: atkbd - correct MSC_SCAN events for force_release keys
From: Stefan Brüns @ 2014-10-17 22:48 UTC (permalink / raw)
To: linux-input
In-Reply-To: <2075303.cGkXBhvpNe@pebbles.site>
On Sunday, September 28, 2014 11:13:24 PM you wrote:
> Without the change either no scancode would be reported on release
> of force_release keys, or - if the key is marked as force_release
> erroneously - the release event and the scancode would be reported
> in separate reports to the input layer.
>
> Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> ---
> drivers/input/keyboard/atkbd.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 2dd1d0d..6375ae6 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -456,8 +456,9 @@ static irqreturn_t atkbd_interrupt(struct serio *serio, unsigned char data,
>
> keycode = atkbd->keycode[code];
>
> - if (keycode != ATKBD_KEY_NULL)
> - input_event(dev, EV_MSC, MSC_SCAN, code);
> + if (!(atkbd->release && test_bit(code, atkbd->force_release_mask)))
> + if (keycode != ATKBD_KEY_NULL)
> + input_event(dev, EV_MSC, MSC_SCAN, code);
>
> switch (keycode) {
> case ATKBD_KEY_NULL:
> @@ -511,6 +512,7 @@ static irqreturn_t atkbd_interrupt(struct serio *serio, unsigned char data,
> input_sync(dev);
>
> if (value && test_bit(code, atkbd->force_release_mask)) {
> + input_event(dev, EV_MSC, MSC_SCAN, code);
> input_report_key(dev, keycode, 0);
> input_sync(dev);
> }
>
Ping!
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Touch processing on host CPU
From: Dmitry Torokhov @ 2014-10-17 17:17 UTC (permalink / raw)
To: Nick Dyer
Cc: Greg KH, Jonathan Cameron, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5440F282.8040306@itdev.co.uk>
Hi Nick,
On Fri, Oct 17, 2014 at 11:42:10AM +0100, Nick Dyer wrote:
> Hi-
>
> I'm trying to find out which subsystem maintainer I should be talking to -
> apologies if I'm addressing the wrong people.
>
> There is a model for doing touch processing where the touch controller
> becomes a much simpler device which sends out raw acquisitions (over SPI
> at up to 1Mbps + protocol overheads). All touch processing is then done in
> user space by the host CPU. An example of this is NVIDIA DirectTouch - see:
> http://blogs.nvidia.com/blog/2012/02/24/industry-adopts-nvidia-directtouch/
>
> In the spirit of "upstream first", I'm trying to figure out how to get a
> driver accepted. Obviously it's not an input device in the normal sense. Is
> it acceptable just to send the raw touch data out via a char device? Is
> there another subsystem which is a good match (eg IIO)? Does the protocol
> (there is ancillary/control data as well) need to be documented?
I'd really think *long* and *hard* about this. Even if you will have the
touch process open source you have 2 options: route it back into the
kernel through uinput, thus adding latency (which might be OK, need to
measure and decide), or go back about 10 years where we had
device-specific drivers in XFree86 and re-create them again, and also do
the same for Wayland, Chrome, Android, etc.
If you will have touch processing in a binary blob, you'll also be going
to ages "Works with Ubuntu 12.04 on x86_32!" (and nothing else), or
"Android 5.1.2 on Tegra Blah (build 78912KT)" (and nothing else).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Touch processing on host CPU
From: Jonathan Cameron @ 2014-10-17 16:33 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Greg KH
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5440F282.8040306@itdev.co.uk>
On October 17, 2014 11:42:10 AM GMT+01:00, Nick Dyer <nick.dyer@itdev.co.uk> wrote:
>Hi-
>
>I'm trying to find out which subsystem maintainer I should be talking
>to -
>apologies if I'm addressing the wrong people.
>
>There is a model for doing touch processing where the touch controller
>becomes a much simpler device which sends out raw acquisitions (over
>SPI
>at up to 1Mbps + protocol overheads). All touch processing is then done
>in
>user space by the host CPU. An example of this is NVIDIA DirectTouch -
>see:
>http://blogs.nvidia.com/blog/2012/02/24/industry-adopts-nvidia-directtouch/
>
>In the spirit of "upstream first", I'm trying to figure out how to get
>a
>driver accepted. Obviously it's not an input device in the normal
>sense. Is
>it acceptable just to send the raw touch data out via a char device? Is
>there another subsystem which is a good match (eg IIO)?
Possibly...
> Does the
>protocol
>(there is ancillary/control data as well) need to be documented?
Do you know of a suitable ADC frontend? Preferably with docs. Interesting bit is the
data format and these ancillary parts.
>
>cheers
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH 1/1] input: Expose states of gpio keypad
From: Dmitry Torokhov @ 2014-10-17 16:22 UTC (permalink / raw)
To: Clark Li; +Cc: linux-input
In-Reply-To: <1413540646-8455-2-git-send-email-clark.li86@gmail.com>
Hi Clark,
On Fri, Oct 17, 2014 at 08:40:46PM +1030, Clark Li wrote:
> Allow user to poll the gpio keypad states in sysfs
The justification for the change is missing from the description.
Anyway, all this data is accessible through /dev/input/eventX, so Id;
rather not add new driver-specific interface for that.
Thanks.
--
Dmitry
^ permalink raw reply
* Touch processing on host CPU
From: Nick Dyer @ 2014-10-17 10:42 UTC (permalink / raw)
To: Dmitry Torokhov, Greg KH, Jonathan Cameron
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Hi-
I'm trying to find out which subsystem maintainer I should be talking to -
apologies if I'm addressing the wrong people.
There is a model for doing touch processing where the touch controller
becomes a much simpler device which sends out raw acquisitions (over SPI
at up to 1Mbps + protocol overheads). All touch processing is then done in
user space by the host CPU. An example of this is NVIDIA DirectTouch - see:
http://blogs.nvidia.com/blog/2012/02/24/industry-adopts-nvidia-directtouch/
In the spirit of "upstream first", I'm trying to figure out how to get a
driver accepted. Obviously it's not an input device in the normal sense. Is
it acceptable just to send the raw touch data out via a char device? Is
there another subsystem which is a good match (eg IIO)? Does the protocol
(there is ancillary/control data as well) need to be documented?
cheers
--
Nick Dyer
Senior Software Engineer, ITDev
Fully Managed Technology Design Services
+44 (0)23 80988855 - http://www.itdev.co.uk
^ permalink raw reply
* [PATCH 1/1] input: Expose states of gpio keypad
From: Clark Li @ 2014-10-17 10:10 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: clark.li86
In-Reply-To: <1413540646-8455-1-git-send-email-clark.li86@gmail.com>
Allow user to poll the gpio keypad states in sysfs
Signed-off-by: Clark Li <clark.li86@gmail.com>
---
drivers/input/keyboard/gpio_keys.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index b29ca65..d3a0536 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -3,6 +3,7 @@
*
* Copyright 2005 Phil Blundell
* Copyright 2010, 2011 David Jander <david@protonic.nl>
+ * Copyright 2014 Clark Li <clark.li86@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -49,6 +50,12 @@ struct gpio_keys_drvdata {
struct gpio_button_data data[0];
};
+/** What to display in sysfs attributes */
+enum gpio_attr_display {
+ gpio_attr_display_key,
+ gpio_attr_display_state
+};
+
/*
* SYSFS interface for enabling/disabling keys and switches:
*
@@ -150,6 +157,7 @@ static void gpio_keys_enable_button(struct gpio_button_data *bdata)
* @only_disabled: does caller want only those buttons that are
* currently disabled or all buttons that can be
* disabled
+ * @display: display the key or key state
*
* This function writes buttons that can be disabled to @buf. If
* @only_disabled is true, then @buf contains only those buttons
@@ -158,12 +166,14 @@ static void gpio_keys_enable_button(struct gpio_button_data *bdata)
*/
static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
char *buf, unsigned int type,
- bool only_disabled)
+ bool only_disabled,
+ enum gpio_attr_display display)
{
int n_events = get_n_events_by_type(type);
unsigned long *bits;
ssize_t ret;
int i;
+ int state;
bits = kcalloc(BITS_TO_LONGS(n_events), sizeof(*bits), GFP_KERNEL);
if (!bits)
@@ -178,7 +188,15 @@ static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
if (only_disabled && !bdata->disabled)
continue;
- __set_bit(bdata->button->code, bits);
+ if (display == gpio_attr_display_key)
+ __set_bit(bdata->button->code, bits);
+ else if (display == gpio_attr_display_state) {
+ state = gpio_get_value_cansleep(bdata->button->gpio)
+ ? 1 : 0;
+ state ^= bdata->button->active_low;
+ if (state)
+ __set_bit(bdata->button->code, bits);
+ }
}
ret = bitmap_scnlistprintf(buf, PAGE_SIZE - 2, bits, n_events);
@@ -251,7 +269,7 @@ out:
return error;
}
-#define ATTR_SHOW_FN(name, type, only_disabled) \
+#define ATTR_SHOW_FN(name, type, only_disabled, display) \
static ssize_t gpio_keys_show_##name(struct device *dev, \
struct device_attribute *attr, \
char *buf) \
@@ -260,22 +278,25 @@ static ssize_t gpio_keys_show_##name(struct device *dev, \
struct gpio_keys_drvdata *ddata = platform_get_drvdata(pdev); \
\
return gpio_keys_attr_show_helper(ddata, buf, \
- type, only_disabled); \
+ type, only_disabled, display); \
}
-ATTR_SHOW_FN(keys, EV_KEY, false);
-ATTR_SHOW_FN(switches, EV_SW, false);
-ATTR_SHOW_FN(disabled_keys, EV_KEY, true);
-ATTR_SHOW_FN(disabled_switches, EV_SW, true);
+ATTR_SHOW_FN(keys, EV_KEY, false, gpio_attr_display_key);
+ATTR_SHOW_FN(switches, EV_SW, false, gpio_attr_display_key);
+ATTR_SHOW_FN(states, EV_KEY, false, gpio_attr_display_state);
+ATTR_SHOW_FN(disabled_keys, EV_KEY, true, gpio_attr_display_key);
+ATTR_SHOW_FN(disabled_switches, EV_SW, true, gpio_attr_display_key);
/*
* ATTRIBUTES:
*
* /sys/devices/platform/gpio-keys/keys [ro]
* /sys/devices/platform/gpio-keys/switches [ro]
+ * /sys/devices/platform/gpio-keys/states [ro]
*/
static DEVICE_ATTR(keys, S_IRUGO, gpio_keys_show_keys, NULL);
static DEVICE_ATTR(switches, S_IRUGO, gpio_keys_show_switches, NULL);
+static DEVICE_ATTR(states, S_IRUGO, gpio_keys_show_states, NULL);
#define ATTR_STORE_FN(name, type) \
static ssize_t gpio_keys_store_##name(struct device *dev, \
@@ -313,6 +334,7 @@ static DEVICE_ATTR(disabled_switches, S_IWUSR | S_IRUGO,
static struct attribute *gpio_keys_attrs[] = {
&dev_attr_keys.attr,
&dev_attr_switches.attr,
+ &dev_attr_states.attr,
&dev_attr_disabled_keys.attr,
&dev_attr_disabled_switches.attr,
NULL,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/1] input: Expose states of gpio keypad
From: Clark Li @ 2014-10-17 10:10 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: clark.li86
Allow user to poll the gpio keypad states in sysfs
Signed-off-by: Clark Li <clark.li86@gmail.com>
---
drivers/input/keyboard/gpio_keys.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index b29ca65..d3a0536 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -3,6 +3,7 @@
*
* Copyright 2005 Phil Blundell
* Copyright 2010, 2011 David Jander <david@protonic.nl>
+ * Copyright 2014 Clark Li <clark.li86@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -49,6 +50,12 @@ struct gpio_keys_drvdata {
struct gpio_button_data data[0];
};
+/** What to display in sysfs attributes */
+enum gpio_attr_display {
+ gpio_attr_display_key,
+ gpio_attr_display_state
+};
+
/*
* SYSFS interface for enabling/disabling keys and switches:
*
@@ -150,6 +157,7 @@ static void gpio_keys_enable_button(struct gpio_button_data *bdata)
* @only_disabled: does caller want only those buttons that are
* currently disabled or all buttons that can be
* disabled
+ * @display: display the key or key state
*
* This function writes buttons that can be disabled to @buf. If
* @only_disabled is true, then @buf contains only those buttons
@@ -158,12 +166,14 @@ static void gpio_keys_enable_button(struct gpio_button_data *bdata)
*/
static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
char *buf, unsigned int type,
- bool only_disabled)
+ bool only_disabled,
+ enum gpio_attr_display display)
{
int n_events = get_n_events_by_type(type);
unsigned long *bits;
ssize_t ret;
int i;
+ int state;
bits = kcalloc(BITS_TO_LONGS(n_events), sizeof(*bits), GFP_KERNEL);
if (!bits)
@@ -178,7 +188,15 @@ static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
if (only_disabled && !bdata->disabled)
continue;
- __set_bit(bdata->button->code, bits);
+ if (display == gpio_attr_display_key)
+ __set_bit(bdata->button->code, bits);
+ else if (display == gpio_attr_display_state) {
+ state = gpio_get_value_cansleep(bdata->button->gpio)
+ ? 1 : 0;
+ state ^= bdata->button->active_low;
+ if (state)
+ __set_bit(bdata->button->code, bits);
+ }
}
ret = bitmap_scnlistprintf(buf, PAGE_SIZE - 2, bits, n_events);
@@ -251,7 +269,7 @@ out:
return error;
}
-#define ATTR_SHOW_FN(name, type, only_disabled) \
+#define ATTR_SHOW_FN(name, type, only_disabled, display) \
static ssize_t gpio_keys_show_##name(struct device *dev, \
struct device_attribute *attr, \
char *buf) \
@@ -260,22 +278,25 @@ static ssize_t gpio_keys_show_##name(struct device *dev, \
struct gpio_keys_drvdata *ddata = platform_get_drvdata(pdev); \
\
return gpio_keys_attr_show_helper(ddata, buf, \
- type, only_disabled); \
+ type, only_disabled, display); \
}
-ATTR_SHOW_FN(keys, EV_KEY, false);
-ATTR_SHOW_FN(switches, EV_SW, false);
-ATTR_SHOW_FN(disabled_keys, EV_KEY, true);
-ATTR_SHOW_FN(disabled_switches, EV_SW, true);
+ATTR_SHOW_FN(keys, EV_KEY, false, gpio_attr_display_key);
+ATTR_SHOW_FN(switches, EV_SW, false, gpio_attr_display_key);
+ATTR_SHOW_FN(states, EV_KEY, false, gpio_attr_display_state);
+ATTR_SHOW_FN(disabled_keys, EV_KEY, true, gpio_attr_display_key);
+ATTR_SHOW_FN(disabled_switches, EV_SW, true, gpio_attr_display_key);
/*
* ATTRIBUTES:
*
* /sys/devices/platform/gpio-keys/keys [ro]
* /sys/devices/platform/gpio-keys/switches [ro]
+ * /sys/devices/platform/gpio-keys/states [ro]
*/
static DEVICE_ATTR(keys, S_IRUGO, gpio_keys_show_keys, NULL);
static DEVICE_ATTR(switches, S_IRUGO, gpio_keys_show_switches, NULL);
+static DEVICE_ATTR(states, S_IRUGO, gpio_keys_show_states, NULL);
#define ATTR_STORE_FN(name, type) \
static ssize_t gpio_keys_store_##name(struct device *dev, \
@@ -313,6 +334,7 @@ static DEVICE_ATTR(disabled_switches, S_IWUSR | S_IRUGO,
static struct attribute *gpio_keys_attrs[] = {
&dev_attr_keys.attr,
&dev_attr_switches.attr,
+ &dev_attr_states.attr,
&dev_attr_disabled_keys.attr,
&dev_attr_disabled_switches.attr,
NULL,
--
1.8.3.2
^ permalink raw reply related
* Re: Hp 3d driveguard seems to be sending events through the keyboard bus - should atkbd be modified to ignore that?
From: Dmitry Torokhov @ 2014-10-16 23:11 UTC (permalink / raw)
To: Giedrius Statkevicius; +Cc: linux-input
In-Reply-To: <543FECAD.5030104@gmail.com>
Hi Giedrius,
On Thu, Oct 16, 2014 at 07:05:01PM +0300, Giedrius Statkevicius wrote:
> Hello,
> In some hp laptops there is a functionality called hp 3d driverguard
> which is basically a accelerometer that detects free fall. It seems
> that on some laptops a keyboard button press event is generated when
> accelerometer's values change and ofc the scan code is not recognized
> by atkbd (and it shouldn't be as it's not a real key). The result of
> this is that the system log gets filled with these messages:
>
> [ 9163.578181] atkbd serio0: Unknown key pressed (translated set 2, code 0xa8 on isa0060/serio0).
> [ 9163.578189] atkbd serio0: Use 'setkeycodes e028 <keycode>' to make it known.
>
> The range of scan codes seem to be from 0xa5 to 0xa8. In my opinion,
> these scan codes on hp laptops with this future should definitely be
> ignored because they are handled by the 'hp_accel' driver. For some
> reason, the accelerometer sends the events through the keyboard bus too.
>
> I've filled a bug report here:
> https://bugzilla.kernel.org/show_bug.cgi?id=84941
>
> What does everyone else think about ignoring these scan codes for
> laptops with this particular feature?
hp_accel driver should use i8042_install_filter() to install a
filtering function that will remove accelerometer data from the keyboard
data stream.
Thanks.
--
Dmitry
^ permalink raw reply
* [git pull] Input updates for 3.18-rc0 (part 2)
From: Dmitry Torokhov @ 2014-10-16 23:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input, Jiri Kosina
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive 2nd round of updates for the input subsystem. Mostly simple
bug fixes, although we do have one brand new driver for Microchip AR1021
i2c touchscreen. Also there is change to stop trying to use i8042 active
multiplexing by default (it is still possible to activate it via
i8042.nomux=0 on boxes that implement it).
Changelog:
---------
Andreas Bosch (1):
Input: alps - fix v4 button press recognition
Chang Huaixin (1):
Input: xen-kbdfront - free grant table entry in xenkbd_disconnect_backend
Christian Gmeiner (1):
Input: Add Microchip AR1021 i2c touchscreen
Dmitry Torokhov (4):
Input: evdev - fix EVIOCG{type} ioctl
Input: automatically set EV_ABS bit in input_set_abs_params
Input: synaptics - gate forcepad support by DMI check
Input: i8042 - disable active multiplexing by default
Hans de Goede (1):
Input: i8042 - add noloop quirk for Asus X750LN
Jaewon Kim (1):
Input: max77693-haptic - fix state check in imax77693_haptic_disable()
Pramod Gurav (2):
Input: opencores-kbd - switch to using managed resources
Input: adp5588-keys - cancel workqueue in failure path
Richard Leitner (2):
Input: avoid negative input device numbers
Input: serio - avoid negative serio device numbers
Sjoerd Simons (1):
Input: cros_ec_keyb - add of match table
Tommi Rantala (2):
Input: xpad - add USB ID for Thrustmaster Ferrari 458 Racing Wheel
Input: xpad - add Thrustmaster as Xbox 360 controller vendor
Diffstat:
--------
Documentation/kernel-parameters.txt | 2 +-
drivers/input/evdev.c | 13 +-
drivers/input/input.c | 5 +-
drivers/input/joystick/xpad.c | 2 +
drivers/input/keyboard/adp5588-keys.c | 1 +
drivers/input/keyboard/cros_ec_keyb.c | 9 ++
drivers/input/keyboard/opencores-kbd.c | 72 ++-------
drivers/input/misc/max77693-haptic.c | 2 +-
drivers/input/misc/xen-kbdfront.c | 4 +-
drivers/input/mouse/alps.c | 4 +-
drivers/input/mouse/synaptics.c | 22 ++-
drivers/input/mouse/synaptics.h | 8 +-
drivers/input/serio/i8042-x86ia64io.h | 287 ++-------------------------------
drivers/input/serio/i8042.c | 2 +-
drivers/input/serio/serio.c | 4 +-
drivers/input/touchscreen/Kconfig | 12 ++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/ar1021_i2c.c | 181 +++++++++++++++++++++
18 files changed, 280 insertions(+), 351 deletions(-)
create mode 100644 drivers/input/touchscreen/ar1021_i2c.c
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: xpad - add Thrustmaster as Xbox 360 controller vendor
From: Dmitry Torokhov @ 2014-10-16 21:02 UTC (permalink / raw)
To: Tommi Rantala; +Cc: linux-input, linux-kernel
In-Reply-To: <1413371076-12390-2-git-send-email-tt.rantala@gmail.com>
On Wed, Oct 15, 2014 at 02:04:36PM +0300, Tommi Rantala wrote:
> Add Thrustmaster as Xbox 360 controller vendor. This is required for
> example to make the GP XID (044f:b326) gamepad work.
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied both, thank you.
> ---
> drivers/input/joystick/xpad.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index cee4fe3..2ed7905 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -293,6 +293,7 @@ static const signed short xpad_abs_triggers[] = {
>
> static struct usb_device_id xpad_table[] = {
> { USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */
> + XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */
> XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */
> XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */
> XPAD_XBOX360_VENDOR(0x046d), /* Logitech X-Box 360 style controllers */
> --
> 1.9.3
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: misc: max77693-haptic - fix active state check in disable()
From: Dmitry Torokhov @ 2014-10-16 21:00 UTC (permalink / raw)
To: Jaewon Kim; +Cc: Chanwoo Choi, linux-input
In-Reply-To: <543DF957.3040907@samsung.com>
On Wed, Oct 15, 2014 at 01:34:31PM +0900, Jaewon Kim wrote:
> Hi Chanwoo,
>
>
> 2014년 10월 15일 13:17에 Chanwoo Choi 이(가) 쓴 글:
> >Hi Jaewon,
> >
> >I think you better to use ':' instead of '-'.
> >- before: Input: misc: max77693-haptic -
> >- after : Input: misc: max77693-haptic:
> I refer past log message.
> I think '-' is input driver style.
Yes, the input style is "Input: <driver> - <short change title>"
Applied, thank you.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Hp 3d driveguard seems to be sending events through the keyboard bus - should atkbd be modified to ignore that?
From: Giedrius Statkevicius @ 2014-10-16 16:05 UTC (permalink / raw)
To: linux-input
Hello,
In some hp laptops there is a functionality called hp 3d driverguard
which is basically a accelerometer that detects free fall. It seems
that on some laptops a keyboard button press event is generated when
accelerometer's values change and ofc the scan code is not recognized
by atkbd (and it shouldn't be as it's not a real key). The result of
this is that the system log gets filled with these messages:
[ 9163.578181] atkbd serio0: Unknown key pressed (translated set 2, code 0xa8 on isa0060/serio0).
[ 9163.578189] atkbd serio0: Use 'setkeycodes e028 <keycode>' to make it known.
The range of scan codes seem to be from 0xa5 to 0xa8. In my opinion,
these scan codes on hp laptops with this future should definitely be
ignored because they are handled by the 'hp_accel' driver. For some
reason, the accelerometer sends the events through the keyboard bus too.
I've filled a bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=84941
What does everyone else think about ignoring these scan codes for
laptops with this particular feature?
^ permalink raw reply
* Re: Problem with Das Keyboard 4 in N-key rollover mode
From: Adam Goode @ 2014-10-16 11:38 UTC (permalink / raw)
To: David Herrmann; +Cc: Fredrik Hallenberg, open list:HID CORE LAYER
In-Reply-To: <CANq1E4RkeszLkrqtadtt72k3TBPEOAfnjzQygfFCOD1dX+U4=g@mail.gmail.com>
On Thu, Oct 16, 2014 at 4:12 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Thu, Oct 16, 2014 at 8:36 AM, Fredrik Hallenberg
> <megahallon@gmail.com> wrote:
>> Hi, this issue was discussed on this list a while ago. Look for
>> spurious backslash in the archive. I submitted a patch that fixed the
>> problem but David Herrmann did a better one later in the thread.
>> However the patch was not applied.
>> David, are there remaining issues with your patch?
>
> Yeah, we need to move it into hid-input.c. Should be fairly easy to do
> and its on my TODO list, but currently busy with conferences.. sorry.
>
Thanks for looking into this. As mentioned on the thread, it would be
interesting if this also solves
https://bugzilla.kernel.org/show_bug.cgi?id=76461 (Bryan actually
works down the hall from me).
Adam
^ permalink raw reply
* Re: Problem with Das Keyboard 4 in N-key rollover mode
From: David Herrmann @ 2014-10-16 8:12 UTC (permalink / raw)
To: Fredrik Hallenberg; +Cc: Adam Goode, open list:HID CORE LAYER
In-Reply-To: <CAMsZVf_7o-ChQfxGRW1ZWth-HKrrr=99TU5Pn0TGd-hsRoMyvg@mail.gmail.com>
Hi
On Thu, Oct 16, 2014 at 8:36 AM, Fredrik Hallenberg
<megahallon@gmail.com> wrote:
> Hi, this issue was discussed on this list a while ago. Look for
> spurious backslash in the archive. I submitted a patch that fixed the
> problem but David Herrmann did a better one later in the thread.
> However the patch was not applied.
> David, are there remaining issues with your patch?
Yeah, we need to move it into hid-input.c. Should be fairly easy to do
and its on my TODO list, but currently busy with conferences.. sorry.
Thanks
David
^ permalink raw reply
* Re: Problem with Das Keyboard 4 in N-key rollover mode
From: Fredrik Hallenberg @ 2014-10-16 6:36 UTC (permalink / raw)
To: Adam Goode, David Herrmann; +Cc: open list:HID CORE LAYER
In-Reply-To: <CADN=WdrqExP36Drz-8ZLi=jU0Ga9Zdsw6LKqm3oJphD2-kM7=w@mail.gmail.com>
Hi, this issue was discussed on this list a while ago. Look for
spurious backslash in the archive. I submitted a patch that fixed the
problem but David Herrmann did a better one later in the thread.
However the patch was not applied.
David, are there remaining issues with your patch?
On Thu, Oct 16, 2014 at 5:15 AM, Adam Goode <adam@spicenitz.org> wrote:
> I have a Das Keyboard 4 and it has a USB N-key rollover mode. When I
> am holding backslash (but no other key that I have discovered!) then
> every press and release of the spacebar leads to another backslash
> keydown/keyup sequence. I also cannot repeat backslash by holding it
> down.
>
> This is with Fedora 21, though I have observed the same issues with
> CentOS 7. Windows 8.1 does not have this problem. Standard 6-key
> rollover does not have this problem (it is switchable on the keyboard
> with a hotkey).
>
> Below are some dumps. Here is what I typed:
>
> backslash down
> space down
> space up
> backslash up
>
>
>
> Here is evtest, you can see the spurious BACKSLASH events:
>
> Event: time 1413429154.248555, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031
> Event: time 1413429154.248555, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
> Event: time 1413429154.248555, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70032
> Event: time 1413429154.248555, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
> Event: time 1413429154.248555, -------------- SYN_REPORT ------------
> Event: time 1413429155.745546, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
> Event: time 1413429155.745546, type 1 (EV_KEY), code 57 (KEY_SPACE), value 1
> Event: time 1413429155.745546, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031
> Event: time 1413429155.745546, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
> Event: time 1413429155.745546, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70032
> Event: time 1413429155.745546, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
> Event: time 1413429155.745546, -------------- SYN_REPORT ------------
> Event: time 1413429155.858578, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
> Event: time 1413429155.858578, type 1 (EV_KEY), code 57 (KEY_SPACE), value 0
> Event: time 1413429155.858578, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031
> Event: time 1413429155.858578, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
> Event: time 1413429155.858578, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70032
> Event: time 1413429155.858578, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
> Event: time 1413429155.858578, -------------- SYN_REPORT ------------
>
>
> Here is hiddump:
>
>
> 003:047:001:DESCRIPTOR 1413429180.935271
> 05 01 09 80 A1 01 85 02 09 81 09 82 09 83 15 00
> 25 01 75 01 95 03 81 06 75 05 95 01 81 01 06 00
> FF 09 01 85 01 15 00 26 FF 00 75 08 95 07 B1 00
> C0 05 0C 09 01 A1 01 85 03 15 00 25 01 09 B5 09
> B6 09 B7 09 CD 09 E2 09 E5 09 E7 09 E9 09 EA 0A
> 52 01 0A 53 01 0A 54 01 0A 55 01 0A 83 01 0A 8A
> 01 0A 92 01 0A 94 01 0A 21 02 0A 23 02 0A 24 02
> 0A 25 02 0A 26 02 0A 27 02 0A 2A 02 75 01 95 18
> 81 02 C0
>
> 003:047:000:DESCRIPTOR 1413429180.935654
> 05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
> 75 01 95 08 81 02 19 00 29 67 95 68 81 02 05 08
> 19 01 29 05 15 00 25 01 75 01 95 05 91 02 75 03
> 95 01 91 01 C0
>
> Starting dumping interrupt transfer stream
> with 1 minute timeout.
>
> 003:047:000:STREAM 1413429182.598393
> 00 00 00 00 00 00 00 02 00 00 00 00 00 00
>
> 003:047:000:STREAM 1413429183.876383
> 00 00 00 00 00 00 10 02 00 00 00 00 00 00
>
> 003:047:000:STREAM 1413429183.995389
> 00 00 00 00 00 00 00 02 00 00 00 00 00 00
>
> 003:047:000:STREAM 1413429185.301376
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>
>
> I am no HID expert, but I will try to figure this out. I would
> appreciate any help.
>
>
>
> Thanks,
>
> Adam
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Problem with Das Keyboard 4 in N-key rollover mode
From: Adam Goode @ 2014-10-16 3:15 UTC (permalink / raw)
To: linux-input
I have a Das Keyboard 4 and it has a USB N-key rollover mode. When I
am holding backslash (but no other key that I have discovered!) then
every press and release of the spacebar leads to another backslash
keydown/keyup sequence. I also cannot repeat backslash by holding it
down.
This is with Fedora 21, though I have observed the same issues with
CentOS 7. Windows 8.1 does not have this problem. Standard 6-key
rollover does not have this problem (it is switchable on the keyboard
with a hotkey).
Below are some dumps. Here is what I typed:
backslash down
space down
space up
backslash up
Here is evtest, you can see the spurious BACKSLASH events:
Event: time 1413429154.248555, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031
Event: time 1413429154.248555, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1413429154.248555, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70032
Event: time 1413429154.248555, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1413429154.248555, -------------- SYN_REPORT ------------
Event: time 1413429155.745546, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
Event: time 1413429155.745546, type 1 (EV_KEY), code 57 (KEY_SPACE), value 1
Event: time 1413429155.745546, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031
Event: time 1413429155.745546, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1413429155.745546, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70032
Event: time 1413429155.745546, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1413429155.745546, -------------- SYN_REPORT ------------
Event: time 1413429155.858578, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
Event: time 1413429155.858578, type 1 (EV_KEY), code 57 (KEY_SPACE), value 0
Event: time 1413429155.858578, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70031
Event: time 1413429155.858578, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1413429155.858578, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70032
Event: time 1413429155.858578, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1413429155.858578, -------------- SYN_REPORT ------------
Here is hiddump:
003:047:001:DESCRIPTOR 1413429180.935271
05 01 09 80 A1 01 85 02 09 81 09 82 09 83 15 00
25 01 75 01 95 03 81 06 75 05 95 01 81 01 06 00
FF 09 01 85 01 15 00 26 FF 00 75 08 95 07 B1 00
C0 05 0C 09 01 A1 01 85 03 15 00 25 01 09 B5 09
B6 09 B7 09 CD 09 E2 09 E5 09 E7 09 E9 09 EA 0A
52 01 0A 53 01 0A 54 01 0A 55 01 0A 83 01 0A 8A
01 0A 92 01 0A 94 01 0A 21 02 0A 23 02 0A 24 02
0A 25 02 0A 26 02 0A 27 02 0A 2A 02 75 01 95 18
81 02 C0
003:047:000:DESCRIPTOR 1413429180.935654
05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
75 01 95 08 81 02 19 00 29 67 95 68 81 02 05 08
19 01 29 05 15 00 25 01 75 01 95 05 91 02 75 03
95 01 91 01 C0
Starting dumping interrupt transfer stream
with 1 minute timeout.
003:047:000:STREAM 1413429182.598393
00 00 00 00 00 00 00 02 00 00 00 00 00 00
003:047:000:STREAM 1413429183.876383
00 00 00 00 00 00 10 02 00 00 00 00 00 00
003:047:000:STREAM 1413429183.995389
00 00 00 00 00 00 00 02 00 00 00 00 00 00
003:047:000:STREAM 1413429185.301376
00 00 00 00 00 00 00 00 00 00 00 00 00 00
I am no HID expert, but I will try to figure this out. I would
appreciate any help.
Thanks,
Adam
^ permalink raw reply
* Re: [PATCH 1/3] input: alps: Reset mouse before identifying it
From: Dmitry Torokhov @ 2014-10-15 18:22 UTC (permalink / raw)
To: Pali Rohár
Cc: Tommy Will, Hans de Goede, Yunkang Tang, linux-input,
linux-kernel
In-Reply-To: <201410152010.39507@pali>
On Wed, Oct 15, 2014 at 08:10:39PM +0200, Pali Rohár wrote:
> On Wednesday 15 October 2014 20:00:11 Dmitry Torokhov wrote:
> > On Wed, Oct 15, 2014 at 07:57:37PM +0200, Pali Rohár wrote:
> > > On Wednesday 15 October 2014 19:43:15 Dmitry Torokhov wrote:
> > > > On Wed, Oct 15, 2014 at 02:53:11PM +0200, Pali Rohár wrote:
> > > > > On Tuesday 14 October 2014 08:08:34 Dmitry Torokhov
> wrote:
> > > > > > On Fri, Oct 03, 2014 at 11:47:59AM +0200, Hans de
> > > > > > Goede
> > >
> > > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Thanks for working on this!
> > > > > > >
> > > > > > > On 10/03/2014 11:43 AM, Pali Rohár wrote:
> > > > > > > > On some systems after starting computer function
> > > > > > > > alps_identify() does not detect dual ALPS
> > > > > > > > touchpad+trackstick device correctly and detect
> > > > > > > > only touchpad.
> > > > > > > >
> > > > > > > > Resetting ALPS device before identifiying it
> > > > > > > > fixing this problem and both parts touchpad and
> > > > > > > > trackstick are detected.
> > > > > > > >
> > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > > > > Tested-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > > >
> > > > > > > Looks good and seems sensible:
> > > > > > >
> > > > > > > Acked-by: Hans de Goede <hdegoede@redhat.com>
> > > > > >
> > > > > > *sigh* I am not really happy about this, as we making
> > > > > > boot longer and longer for people without ALPS
> > > > > > touchpads. It would be better if we only reset the
> > > > > > mouse when we knew we are dealing with ALPS, and even
> > > > > > better if we only reset it when we suspected that we
> > > > > > missed trackstick. Any chance of doing this?
> > > > > >
> > > > > > Thanks.
> > > > >
> > > > > Dmitry, problem is that function check which detecting
> > > > > trackstick does not working when I start my laptop from
> > > > > power-off state and do not reset PS/2 device. But
> > > > > detecting ALPS touchpad looks like working. So if do
> > > > > not like this idea, what about doing something like
> > > > > this in alps_dectect function?
> > > > >
> > > > > int alps_detect(...)
> > > > > {
> > > > > ...
> > > > > /* detect if device is ALPS */
> > > > > if (alps_identify(...) < 0)
> > > > > return -1;
> > > > > /* now we know that device is ALPS */
> > > > > if (!(flags & ALPS_DUALPOINT)) {
> > > > > /* reset it and identify again, maybe there is
> > > > > trackstick */ psmouse_reset(...);
> > > > > alps_identify(...);
> > > > > }
> > > > > ...
> > > > > }
> > > > >
> > > > > It will does not affect non ALPS devices (because first
> > > > > identify call will fail), but will affect ALPS devices
> > > > > without trackstick (because identify will be called
> > > > > twice and reset too).
> > > >
> > > > I think this is a step in right direction. Do you know
> > > > what exactly fails in alps_identify() on your box if you
> > > > do not call psmouse_reset?
> > > >
> > > > Thanks.
> > >
> > > Yes, I know. It is failing in alps_probe_trackstick_v3(). It
> > > calls alps_command_mode_read_reg(...) and it returns 0 which
> > > means trackstick is not there.
> >
> > OK, so can we try sticking psmouse_reset() there? This will
> > limit the exposure of the new delay.
> >
> > Thanks.
>
> Sorry, but I think this is not safe. Function psmouse_reset will
> reset device (set it to relative mode, etc...) and before and
> after alps_probe_trackstick_v3() are called other functions. So
> it could break something else.
We might need to repeat bits of alps_identify() after resetting the
mouse, you are right. It should still be doable though.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox