* [PATCH v2 05/24] input: Port max8997_haptic to ff-memless-next
From: Michal Malý @ 2014-04-22 13:59 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port max8997_haptic to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/input/misc/Kconfig | 2 +-
drivers/input/misc/max8997_haptic.c | 25 +++++++++++++++++++------
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 91dcae8..6ba327f 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -157,7 +157,7 @@ config INPUT_MAX8925_ONKEY
config INPUT_MAX8997_HAPTIC
tristate "MAXIM MAX8997 haptic controller support"
depends on PWM && HAVE_PWM && MFD_MAX8997
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
help
This option enables device driver support for the haptic controller
on MAXIM MAX8997 chip. This driver supports ff-memless interface
diff --git a/drivers/input/misc/max8997_haptic.c b/drivers/input/misc/max8997_haptic.c
index 1fea548..029ac8b 100644
--- a/drivers/input/misc/max8997_haptic.c
+++ b/drivers/input/misc/max8997_haptic.c
@@ -31,6 +31,7 @@
#include <linux/mfd/max8997-private.h>
#include <linux/mfd/max8997.h>
#include <linux/regulator/consumer.h>
+#include <linux/input/ff-memless-next.h>
/* Haptic configuration 2 register */
#define MAX8997_MOTOR_TYPE_SHIFT 7
@@ -43,6 +44,8 @@
#define MAX8997_SIG_DUTY_SHIFT 2
#define MAX8997_PWM_DUTY_SHIFT 0
+#define FF_UPDATE_RATE 50
+
struct max8997_haptic {
struct device *dev;
struct i2c_client *client;
@@ -219,13 +222,23 @@ static void max8997_haptic_play_effect_work(struct work_struct *work)
}
static int max8997_haptic_play_effect(struct input_dev *dev, void *data,
- struct ff_effect *effect)
+ const struct mlnx_effect_command *command)
{
struct max8997_haptic *chip = input_get_drvdata(dev);
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
- chip->level = effect->u.rumble.strong_magnitude;
- if (!chip->level)
- chip->level = effect->u.rumble.weak_magnitude;
+ switch (command->cmd) {
+ case MLNX_START_RUMBLE:
+ chip->level = rumble_force->strong;
+ if (!chip->level)
+ chip->level = rumble_force->weak;
+ break;
+ case MLNX_STOP_RUMBLE:
+ chip->level = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
schedule_work(&chip->work);
@@ -319,8 +332,8 @@ static int max8997_haptic_probe(struct platform_device *pdev)
input_set_drvdata(input_dev, chip);
input_set_capability(input_dev, EV_FF, FF_RUMBLE);
- error = input_ff_create_memless(input_dev, NULL,
- max8997_haptic_play_effect);
+ error = input_ff_create_mlnx(input_dev, NULL,
+ max8997_haptic_play_effect, FF_UPDATE_RATE);
if (error) {
dev_err(&pdev->dev,
"unable to create FF device, error: %d\n",
--
1.9.2
--
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 related
* [PATCH v2 06/24] input: Port pm8xxx-vibrator to ff-memless-next
From: Michal Malý @ 2014-04-22 13:59 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port pm8xxx-vibrator to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/input/misc/Kconfig | 2 +-
drivers/input/misc/pm8xxx-vibrator.c | 28 +++++++++++++++++++---------
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6ba327f..300b5a8 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -108,7 +108,7 @@ config INPUT_PCSPKR
config INPUT_PM8XXX_VIBRATOR
tristate "Qualcomm PM8XXX vibrator support"
depends on MFD_PM8XXX
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
help
This option enables device driver support for the vibrator
on Qualcomm PM8xxx chip. This driver supports ff-memless interface
diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index b88b7cb..6b0e9eb 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -17,6 +17,7 @@
#include <linux/input.h>
#include <linux/slab.h>
#include <linux/regmap.h>
+#include <linux/input/ff-memless-next.h>
#define VIB_DRV 0x4A
@@ -29,7 +30,7 @@
#define VIB_MAX_LEVELS (VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
#define MAX_FF_SPEED 0xff
-
+#define FF_UPDATE_RATE 50
/**
* struct pm8xxx_vib - structure to hold vibrator data
* @vib_input_dev: input device supporting force feedback
@@ -128,14 +129,23 @@ static void pm8xxx_vib_close(struct input_dev *dev)
* Currently this driver supports only rumble effects.
*/
static int pm8xxx_vib_play_effect(struct input_dev *dev, void *data,
- struct ff_effect *effect)
+ const struct mlnx_command *command)
{
struct pm8xxx_vib *vib = input_get_drvdata(dev);
-
- vib->speed = effect->u.rumble.strong_magnitude >> 8;
- if (!vib->speed)
- vib->speed = effect->u.rumble.weak_magnitude >> 9;
-
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
+
+ switch (command->cmd) {
+ case MLNX_START_RUMBLE:
+ vib->speed = rumble_force->strong >> 8;
+ if (!vib->speed)
+ vib->speed = rumble_force->weak >> 9;
+ break;
+ case MLNX_STOP_RUMBLE:
+ vib->speed = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
schedule_work(&vib->work);
return 0;
@@ -182,8 +192,8 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
input_set_drvdata(input_dev, vib);
input_set_capability(vib->vib_input_dev, EV_FF, FF_RUMBLE);
- error = input_ff_create_memless(input_dev, NULL,
- pm8xxx_vib_play_effect);
+ error = input_ff_create_mlnx(input_dev, NULL,
+ pm8xxx_vib_play_effect, FF_UPDATE_RATE);
if (error) {
dev_err(&pdev->dev,
"couldn't register vibrator as FF device\n");
--
1.9.2
--
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 related
* [PATCH v2 11/24] input: Port hid-holtekff to ff-memless-next
From: Michal Malý @ 2014-04-22 13:59 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port hid-holtekff to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/hid/Kconfig | 2 +-
drivers/hid/hid-holtekff.c | 47 +++++++++++++++++++++++++++++-----------------
2 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 24b336e..d1d4e77 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -247,7 +247,7 @@ config HID_HOLTEK
config HOLTEK_FF
bool "Holtek On Line Grip force feedback support"
depends on HID_HOLTEK
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
---help---
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
diff --git a/drivers/hid/hid-holtekff.c b/drivers/hid/hid-holtekff.c
index 9325545..9c6064d 100644
--- a/drivers/hid/hid-holtekff.c
+++ b/drivers/hid/hid-holtekff.c
@@ -27,9 +27,12 @@
#include <linux/input.h>
#include <linux/module.h>
#include <linux/slab.h>
+#include <linux/input/ff-memless-next.h>
#include "hid-ids.h"
+#define FF_UPDATE_RATE 50
+
#ifdef CONFIG_HOLTEK_FF
MODULE_LICENSE("GPL");
@@ -104,34 +107,44 @@ static void holtekff_send(struct holtekff_device *holtekff,
}
static int holtekff_play(struct input_dev *dev, void *data,
- struct ff_effect *effect)
+ const struct mlnx_effect_command *command)
{
struct hid_device *hid = input_get_drvdata(dev);
struct holtekff_device *holtekff = data;
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
int left, right;
/* effect type 1, length 65535 msec */
u8 buf[HOLTEKFF_MSG_LENGTH] =
{ 0x01, 0x01, 0xff, 0xff, 0x10, 0xe0, 0x00 };
- left = effect->u.rumble.strong_magnitude;
- right = effect->u.rumble.weak_magnitude;
- dbg_hid("called with 0x%04x 0x%04x\n", left, right);
+ switch (command->cmd) {
+ case MLNX_START_RUMBLE:
+ left = rumble_force->strong;
+ right = rumble_force->weak;
+ dbg_hid("called with 0x%04x 0x%04x\n", left, right);
- if (!left && !right) {
- holtekff_send(holtekff, hid, stop_all6);
- return 0;
- }
+ if (!left && !right) {
+ holtekff_send(holtekff, hid, stop_all6);
+ return 0;
+ }
- if (left)
- buf[1] |= 0x80;
- if (right)
- buf[1] |= 0x40;
+ if (left)
+ buf[1] |= 0x80;
+ if (right)
+ buf[1] |= 0x40;
- /* The device takes a single magnitude, so we just sum them up. */
- buf[6] = min(0xf, (left >> 12) + (right >> 12));
+ /* The device takes a single magnitude, so we just sum them up. */
+ buf[6] = min(0xf, (left >> 12) + (right >> 12));
- holtekff_send(holtekff, hid, buf);
- holtekff_send(holtekff, hid, start_effect_1);
+ holtekff_send(holtekff, hid, buf);
+ holtekff_send(holtekff, hid, start_effect_1);
+ return 0;
+ case MLNX_STOP_RUMBLE:
+ holtekff_send(holtekff, hid, stop_all6);
+ return 0;
+ default:
+ return -EINVAL;
+ }
return 0;
}
@@ -171,7 +184,7 @@ static int holtekff_init(struct hid_device *hid)
holtekff_send(holtekff, hid, stop_all4);
holtekff_send(holtekff, hid, stop_all6);
- error = input_ff_create_memless(dev, holtekff, holtekff_play);
+ error = input_ff_create_mlnx(dev, holtekff, holtekff_play, FF_UPDATE_RATE);
if (error) {
kfree(holtekff);
return error;
--
1.9.2
--
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 related
* [PATCH v2 14/24] input: Port hid-pl to ff-memless-next
From: Michal Malý @ 2014-04-22 13:59 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port hid-pl to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/hid/Kconfig | 2 +-
drivers/hid/hid-pl.c | 38 ++++++++++++++++++++++++++------------
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 6f2941a..87a02cc 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -500,7 +500,7 @@ config HID_PANTHERLORD
config PANTHERLORD_FF
bool "Pantherlord force feedback support"
depends on HID_PANTHERLORD
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
---help---
Say Y here if you have a PantherLord/GreenAsia based game controller
or adapter and want to enable force feedback support for it.
diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
index 2dcd7d9..9b539d5 100644
--- a/drivers/hid/hid-pl.c
+++ b/drivers/hid/hid-pl.c
@@ -44,9 +44,12 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/hid.h>
+#include <linux/input/ff-memless-next.h>
#include "hid-ids.h"
+#define FF_UPDATE_RATE 50
+
#ifdef CONFIG_PANTHERLORD_FF
struct plff_device {
@@ -57,24 +60,35 @@ struct plff_device {
};
static int hid_plff_play(struct input_dev *dev, void *data,
- struct ff_effect *effect)
+ const struct mlnx_effect_command *command)
{
struct hid_device *hid = input_get_drvdata(dev);
struct plff_device *plff = data;
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
int left, right;
- left = effect->u.rumble.strong_magnitude;
- right = effect->u.rumble.weak_magnitude;
- debug("called with 0x%04x 0x%04x", left, right);
-
- left = left * plff->maxval / 0xffff;
- right = right * plff->maxval / 0xffff;
+ switch (command->cmd) {
+ case MLNX_START_RUMBLE:
+ left = rumble_force->strong;
+ right = rumble_force->weak;
+ debug("called with 0x%04x 0x%04x", left, right);
+
+ left = left * plff->maxval / 0xffff;
+ right = right * plff->maxval / 0xffff;
+
+ *plff->strong = left;
+ *plff->weak = right;
+ debug("running with 0x%02x 0x%02x", left, right);
+ break;
+ case MLNX_STOP_RUMBLE:
+ *plff->strong = 0;
+ *plff->weak = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
- *plff->strong = left;
- *plff->weak = right;
- debug("running with 0x%02x 0x%02x", left, right);
hid_hw_request(hid, plff->report, HID_REQ_SET_REPORT);
-
return 0;
}
@@ -160,7 +174,7 @@ static int plff_init(struct hid_device *hid)
set_bit(FF_RUMBLE, dev->ffbit);
- error = input_ff_create_memless(dev, plff, hid_plff_play);
+ error = input_ff_create_mlnx(dev, plff, hid_plff_play, FF_UPDATE_RATE);
if (error) {
kfree(plff);
return error;
--
1.9.2
--
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 related
* [PATCH v2 15/24] input: Port hid-sjoy to ff-memless-next
From: Michal Malý @ 2014-04-22 14:00 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port hid-sjoy to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/hid/Kconfig | 2 +-
drivers/hid/hid-sjoy.c | 35 +++++++++++++++++++++++++----------
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 87a02cc..e76c36a 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -681,7 +681,7 @@ config HID_SMARTJOYPLUS
config SMARTJOYPLUS_FF
bool "SmartJoy PLUS PS2/USB adapter force feedback support"
depends on HID_SMARTJOYPLUS
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
---help---
Say Y here if you have a SmartJoy PLUS PS2/USB adapter and want to
enable force feedback support for it.
diff --git a/drivers/hid/hid-sjoy.c b/drivers/hid/hid-sjoy.c
index 37845ec..a6f8cfe 100644
--- a/drivers/hid/hid-sjoy.c
+++ b/drivers/hid/hid-sjoy.c
@@ -30,8 +30,11 @@
#include <linux/slab.h>
#include <linux/hid.h>
#include <linux/module.h>
+#include <linux/input/ff-memless-next.h>
#include "hid-ids.h"
+#define FF_UPDATE_RATE 50
+
#ifdef CONFIG_SMARTJOYPLUS_FF
struct sjoyff_device {
@@ -39,21 +42,33 @@ struct sjoyff_device {
};
static int hid_sjoyff_play(struct input_dev *dev, void *data,
- struct ff_effect *effect)
+ const struct mlnx_effect_command *command)
{
struct hid_device *hid = input_get_drvdata(dev);
struct sjoyff_device *sjoyff = data;
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
u32 left, right;
- left = effect->u.rumble.strong_magnitude;
- right = effect->u.rumble.weak_magnitude;
- dev_dbg(&dev->dev, "called with 0x%08x 0x%08x\n", left, right);
-
- left = left * 0xff / 0xffff;
- right = (right != 0); /* on/off only */
+ switch (command->cmd) {
+ case MLNX_START_RUMBLE:
+ left = rumble_force->strong;
+ right = rumble_force->weak;
+ dev_dbg(&dev->dev, "called with 0x%08x 0x%08x\n", left, right);
+
+ left = left * 0xff / 0xffff;
+ right = (right != 0); /* on/off only */
+
+ sjoyff->report->field[0]->value[1] = right;
+ sjoyff->report->field[0]->value[2] = left;
+ break;
+ case MLNX_STOP_RUMBLE:
+ left = 0;
+ right = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
- sjoyff->report->field[0]->value[1] = right;
- sjoyff->report->field[0]->value[2] = left;
dev_dbg(&dev->dev, "running with 0x%02x 0x%02x\n", left, right);
hid_hw_request(hid, sjoyff->report, HID_REQ_SET_REPORT);
@@ -103,7 +118,7 @@ static int sjoyff_init(struct hid_device *hid)
set_bit(FF_RUMBLE, dev->ffbit);
- error = input_ff_create_memless(dev, sjoyff, hid_sjoyff_play);
+ error = input_ff_create_mlnx(dev, sjoyff, hid_sjoyff_play, FF_UPDATE_RATE);
if (error) {
kfree(sjoyff);
return error;
--
1.9.2
--
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 related
* [PATCH v2 17/24] input: Port hid-tmff to ff-memless-next
From: Michal Malý @ 2014-04-22 14:00 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port hid-tmff to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/hid/Kconfig | 2 +-
drivers/hid/hid-tmff.c | 83 ++++++++++++++++++++++++++++++--------------------
2 files changed, 51 insertions(+), 34 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index fc22f72..ee999bc 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -719,7 +719,7 @@ config HID_THRUSTMASTER
config THRUSTMASTER_FF
bool "ThrustMaster devices force feedback support"
depends on HID_THRUSTMASTER
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
---help---
Say Y here if you have a THRUSTMASTER FireStore Dual Power 2 or 3,
a THRUSTMASTER Dual Trigger 3-in-1 or a THRUSTMASTER Ferrari GT
diff --git a/drivers/hid/hid-tmff.c b/drivers/hid/hid-tmff.c
index b833760..3df000c 100644
--- a/drivers/hid/hid-tmff.c
+++ b/drivers/hid/hid-tmff.c
@@ -31,9 +31,12 @@
#include <linux/input.h>
#include <linux/slab.h>
#include <linux/module.h>
+#include <linux/input/ff-memless-next.h>
#include "hid-ids.h"
+#define FF_UPDATE_RATE 50
+
static const signed short ff_rumble[] = {
FF_RUMBLE,
-1
@@ -41,6 +44,13 @@ static const signed short ff_rumble[] = {
static const signed short ff_joystick[] = {
FF_CONSTANT,
+ FF_RAMP,
+ FF_PERIODIC,
+ FF_SINE,
+ FF_SQUARE,
+ FF_TRIANGLE,
+ FF_SAW_DOWN,
+ FF_SAW_UP,
-1
};
@@ -67,12 +77,12 @@ static inline int tmff_scale_u16(unsigned int in, int minimum, int maximum)
return ret;
}
-/* Changes values from -0x80 to 0x7f into values from minimum to maximum */
-static inline int tmff_scale_s8(int in, int minimum, int maximum)
+/* Changes values from -0x7fff to 0x7fff into values from minimum to maximum */
+static inline int tmff_scale_s32(int in, int minimum, int maximum)
{
int ret;
- ret = (((in + 0x80) * (maximum - minimum)) / 0xff) + minimum;
+ ret = (((in + 0x7fff) * (maximum - minimum)) / 0xffff) + minimum;
if (ret < minimum)
return minimum;
if (ret > maximum)
@@ -81,43 +91,50 @@ static inline int tmff_scale_s8(int in, int minimum, int maximum)
}
static int tmff_play(struct input_dev *dev, void *data,
- struct ff_effect *effect)
+ const struct mlnx_effect_command *command)
{
struct hid_device *hid = input_get_drvdata(dev);
struct tmff_device *tmff = data;
struct hid_field *ff_field = tmff->ff_field;
int x, y;
- int left, right; /* Rumbling */
-
- switch (effect->type) {
- case FF_CONSTANT:
- x = tmff_scale_s8(effect->u.ramp.start_level,
- ff_field->logical_minimum,
- ff_field->logical_maximum);
- y = tmff_scale_s8(effect->u.ramp.end_level,
- ff_field->logical_minimum,
- ff_field->logical_maximum);
-
- dbg_hid("(x, y)=(%04x, %04x)\n", x, y);
- ff_field->value[0] = x;
- ff_field->value[1] = y;
- hid_hw_request(hid, tmff->report, HID_REQ_SET_REPORT);
- break;
- case FF_RUMBLE:
- left = tmff_scale_u16(effect->u.rumble.weak_magnitude,
- ff_field->logical_minimum,
- ff_field->logical_maximum);
- right = tmff_scale_u16(effect->u.rumble.strong_magnitude,
- ff_field->logical_minimum,
- ff_field->logical_maximum);
-
- dbg_hid("(left,right)=(%08x, %08x)\n", left, right);
- ff_field->value[0] = left;
- ff_field->value[1] = right;
- hid_hw_request(hid, tmff->report, HID_REQ_SET_REPORT);
+ switch (command->cmd) {
+ case MLNX_START_COMBINED: {
+ const struct mlnx_simple_force *sf = &command->u.simple_force;
+ x = tmff_scale_s32(sf->x,
+ ff_field->logical_minimum,
+ ff_field->logical_maximum);
+ y = tmff_scale_s32(sf->y,
+ ff_field->logical_minimum,
+ ff_field->logical_maximum);
+ break;
+ }
+ case MLNX_STOP_COMBINED:
+ x = 0;
+ y = 0;
+ break;
+ case MLNX_START_RUMBLE: {
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
+ x = tmff_scale_u16(rumble_force->weak,
+ ff_field->logical_minimum,
+ ff_field->logical_maximum);
+ y = tmff_scale_u16(rumble_force->strong,
+ ff_field->logical_minimum,
+ ff_field->logical_maximum);
break;
+ }
+ case MLNX_STOP_RUMBLE:
+ x = 0;
+ y = 0;
+ break;
+ default:
+ return -EINVAL;
}
+
+ ff_field->value[0] = x;
+ ff_field->value[1] = y;
+
+ hid_hw_request(hid, tmff->report, HID_REQ_SET_REPORT);
return 0;
}
@@ -192,7 +209,7 @@ static int tmff_init(struct hid_device *hid, const signed short *ff_bits)
goto fail;
}
- error = input_ff_create_memless(input_dev, tmff, tmff_play);
+ error = input_ff_create_mlnx(input_dev, tmff, tmff_play, FF_UPDATE_RATE);
if (error)
goto fail;
--
1.9.2
--
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 related
* [PATCH v2 21/24] input: Port xpad to ff-memless-next
From: Michal Malý @ 2014-04-22 14:00 UTC (permalink / raw)
To: linux-input, linux-kernel
Cc: dmitry.torokhov, jkosina, elias.vds, anssi.hannula, simon
In-Reply-To: <1398175209-9565-1-git-send-email-madcatxster@devoid-pointer.net>
Port xpad to ff-memless-next
Signed-off-by: Michal Malý <madcatxster@devoid-pointer.net>
---
drivers/input/joystick/Kconfig | 2 +-
drivers/input/joystick/xpad.c | 125 +++++++++++++++++++++++------------------
2 files changed, 71 insertions(+), 56 deletions(-)
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 2dd3ba1..9f26e48 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -294,7 +294,7 @@ config JOYSTICK_XPAD
config JOYSTICK_XPAD_FF
bool "X-Box gamepad rumble support"
depends on JOYSTICK_XPAD && INPUT
- select INPUT_FF_MEMLESS
+ select INPUT_FF_MEMLESS_NEXT
---help---
Say Y here if you want to take advantage of xbox 360 rumble features.
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 603fe0d..5d9c8a2 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -78,6 +78,7 @@
#include <linux/stat.h>
#include <linux/module.h>
#include <linux/usb/input.h>
+#include <linux/input/ff-memless-next.h>
#define DRIVER_AUTHOR "Marko Friedemann <mfr@bmx-chemnitz.de>"
#define DRIVER_DESC "X-Box pad driver"
@@ -97,6 +98,8 @@
#define XTYPE_XBOX360W 2
#define XTYPE_UNKNOWN 3
+#define FF_UPDATE_RATE 50
+
static bool dpad_to_buttons;
module_param(dpad_to_buttons, bool, S_IRUGO);
MODULE_PARM_DESC(dpad_to_buttons, "Map D-PAD to buttons rather than axes for unknown pads");
@@ -628,63 +631,75 @@ static void xpad_stop_output(struct usb_xpad *xpad) {}
#endif
#ifdef CONFIG_JOYSTICK_XPAD_FF
-static int xpad_play_effect(struct input_dev *dev, void *data, struct ff_effect *effect)
+static int xpad_play_effect(struct input_dev *dev, void *data,
+ const struct mlnx_effect_command *command)
{
struct usb_xpad *xpad = input_get_drvdata(dev);
+ const struct mlnx_rumble_force *rumble_force = &command->u.rumble_force;
+ __u16 strong, weak;
- if (effect->type == FF_RUMBLE) {
- __u16 strong = effect->u.rumble.strong_magnitude;
- __u16 weak = effect->u.rumble.weak_magnitude;
-
- switch (xpad->xtype) {
-
- case XTYPE_XBOX:
- xpad->odata[0] = 0x00;
- xpad->odata[1] = 0x06;
- xpad->odata[2] = 0x00;
- xpad->odata[3] = strong / 256; /* left actuator */
- xpad->odata[4] = 0x00;
- xpad->odata[5] = weak / 256; /* right actuator */
- xpad->irq_out->transfer_buffer_length = 6;
-
- return usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
-
- case XTYPE_XBOX360:
- xpad->odata[0] = 0x00;
- xpad->odata[1] = 0x08;
- xpad->odata[2] = 0x00;
- xpad->odata[3] = strong / 256; /* left actuator? */
- xpad->odata[4] = weak / 256; /* right actuator? */
- xpad->odata[5] = 0x00;
- xpad->odata[6] = 0x00;
- xpad->odata[7] = 0x00;
- xpad->irq_out->transfer_buffer_length = 8;
-
- return usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
-
- case XTYPE_XBOX360W:
- xpad->odata[0] = 0x00;
- xpad->odata[1] = 0x01;
- xpad->odata[2] = 0x0F;
- xpad->odata[3] = 0xC0;
- xpad->odata[4] = 0x00;
- xpad->odata[5] = strong / 256;
- xpad->odata[6] = weak / 256;
- xpad->odata[7] = 0x00;
- xpad->odata[8] = 0x00;
- xpad->odata[9] = 0x00;
- xpad->odata[10] = 0x00;
- xpad->odata[11] = 0x00;
- xpad->irq_out->transfer_buffer_length = 12;
-
- return usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
-
- default:
- dev_dbg(&xpad->dev->dev,
- "%s - rumble command sent to unsupported xpad type: %d\n",
- __func__, xpad->xtype);
- return -1;
- }
+ switch (command->cmd) {
+ case MLNX_START_RUMBLE:
+ strong = rumble_force->strong;
+ weak = rumble_force->weak;
+ break;
+ case MLNX_STOP_RUMBLE:
+ strong = 0;
+ weak = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+
+ switch (xpad->xtype) {
+
+ case XTYPE_XBOX:
+ xpad->odata[0] = 0x00;
+ xpad->odata[1] = 0x06;
+ xpad->odata[2] = 0x00;
+ xpad->odata[3] = strong / 256; /* left actuator */
+ xpad->odata[4] = 0x00;
+ xpad->odata[5] = weak / 256; /* right actuator */
+ xpad->irq_out->transfer_buffer_length = 6;
+
+ return usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
+
+ case XTYPE_XBOX360:
+ xpad->odata[0] = 0x00;
+ xpad->odata[1] = 0x08;
+ xpad->odata[2] = 0x00;
+ xpad->odata[3] = strong / 256; /* left actuator? */
+ xpad->odata[4] = weak / 256; /* right actuator? */
+ xpad->odata[5] = 0x00;
+ xpad->odata[6] = 0x00;
+ xpad->odata[7] = 0x00;
+ xpad->irq_out->transfer_buffer_length = 8;
+
+ return usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
+
+ case XTYPE_XBOX360W:
+ xpad->odata[0] = 0x00;
+ xpad->odata[1] = 0x01;
+ xpad->odata[2] = 0x0F;
+ xpad->odata[3] = 0xC0;
+ xpad->odata[4] = 0x00;
+ xpad->odata[5] = strong / 256;
+ xpad->odata[6] = weak / 256;
+ xpad->odata[7] = 0x00;
+ xpad->odata[8] = 0x00;
+ xpad->odata[9] = 0x00;
+ xpad->odata[10] = 0x00;
+ xpad->odata[11] = 0x00;
+ xpad->irq_out->transfer_buffer_length = 12;
+
+ return usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
+
+ default:
+ dev_dbg(&xpad->dev->dev,
+ "%s - rumble command sent to unsupported xpad type: %d\n",
+ __func__, xpad->xtype);
+ return -1;
}
return 0;
@@ -697,7 +712,7 @@ static int xpad_init_ff(struct usb_xpad *xpad)
input_set_capability(xpad->dev, EV_FF, FF_RUMBLE);
- return input_ff_create_memless(xpad->dev, NULL, xpad_play_effect);
+ return input_ff_create_mlnx(xpad->dev, NULL, xpad_play_effect, FF_UPDATE_RATE);
}
#else
--
1.9.2
--
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 related
* Re: Bug: HID-Sony: DS4 touch-pad corrupts Axis0
From: simon @ 2014-04-22 16:50 UTC (permalink / raw)
To: Frank Praznik; +Cc: simon, Frank Praznik, HID CORE LAYER, Jiri Kosina
In-Reply-To: <53557CB5.1010100@gmail.com>
> The joydev device *is* missing the mappings for the touchpad axes for
> some reason (JSIOCGAXES returns 14 instead of 17 like it should). I'm
> not sure why though. In the Sony driver the touchpad axis bits are set
> in the probe function and work correctly via the evdev interface and
> looking in the joydev module it should properly handle and map all axes
> up to ABS_MAX so the problem probably lies somewhere else. If I had to
> guess, it seems like the joydev device is being created after the HID
> descriptor is parsed, but before the device probe function is called.
>
> Can anyone more familiar with the general input system comment on why
> this might be happening?
I find it suspicious that it doesn't happen the first time (after boot)
that the controller is plugged in, but then does every subsequent time...
maybe some un-init memory somewhere.
Is this kernel behaviour, or down to the controller state (ie alive after
first plug)? We see that the DS3 behaves differently wrt leds depending on
whether it is asleep or alive when plugged in.
I'll dig a little deeper tonight to see if I can track the problem down.
Simon.
^ permalink raw reply
* [PATCH] Input: atkbd - fix keyboard LG Electronics
From: Sheng-Liang Song @ 2014-04-22 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sheng-Liang Song, Shawn Nematbakhsh, Dmitry Torokhov, linux-input,
linux-kernel
After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working.
The workaround is to issue ATKBD_CMD_RESET_DEF after ATKBD_CMD_RESET_DIS.
In order to keep the minimum changes to the current atkbd driver,
I add logic to apply the patch if and only if the device is LG LW25-B7HV or P1-J273B.
---
drivers/input/keyboard/atkbd.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..75e68f2 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -242,6 +242,7 @@ struct atkbd {
static void (*atkbd_platform_fixup)(struct atkbd *, const void *data);
static void *atkbd_platform_fixup_data;
static unsigned int (*atkbd_platform_scancode_fixup)(struct atkbd *, unsigned int);
+static void (*atkbd_deactivate_fixup)(struct atkbd *atkbd);
static ssize_t atkbd_attr_show_helper(struct device *dev, char *buf,
ssize_t (*handler)(struct atkbd *, char *));
@@ -698,6 +699,10 @@ static int atkbd_activate(struct atkbd *atkbd)
* atkbd_deactivate() resets and disables the keyboard from sending
* keystrokes.
*/
+static void atkbd_deactivate_rst_fixup(struct atkbd *atkbd)
+{
+ ps2_command(&atkbd->ps2dev, NULL, ATKBD_CMD_RESET_DEF);
+}
static void atkbd_deactivate(struct atkbd *atkbd)
{
@@ -707,6 +712,9 @@ static void atkbd_deactivate(struct atkbd *atkbd)
dev_err(&ps2dev->serio->dev,
"Failed to deactivate keyboard on %s\n",
ps2dev->serio->phys);
+
+ if (atkbd_deactivate_fixup)
+ atkbd_deactivate_fixup(atkbd);
}
/*
@@ -1638,6 +1646,12 @@ static int __init atkbd_setup_scancode_fixup(const struct dmi_system_id *id)
return 1;
}
+static int __init atkbd_setup_deactivate(const struct dmi_system_id *id)
+{
+ atkbd_deactivate_fixup = id->driver_data;
+ return 1;
+}
+
static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
{
.matches = {
@@ -1775,6 +1789,22 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
.callback = atkbd_setup_scancode_fixup,
.driver_data = atkbd_oqo_01plus_scancode_fixup,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LW25-B7HV"),
+ },
+ .callback = atkbd_setup_deactivate,
+ .driver_data = atkbd_deactivate_rst_fixup,
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P1-J273B"),
+ },
+ .callback = atkbd_setup_deactivate,
+ .driver_data = atkbd_deactivate_rst_fixup,
+ },
{ }
};
--
1.9.1.423.g4596e3a
^ permalink raw reply related
* Re: Bug: HID-Sony: DS4 touch-pad corrupts Axis0
From: Frank Praznik @ 2014-04-22 17:31 UTC (permalink / raw)
To: simon; +Cc: Frank Praznik, HID CORE LAYER, Jiri Kosina
In-Reply-To: <35342da9a382362bc86ab7abfa7ee07a.squirrel@mungewell.org>
On 4/22/2014 12:50, simon@mungewell.org wrote:
>> The joydev device *is* missing the mappings for the touchpad axes for
>> some reason (JSIOCGAXES returns 14 instead of 17 like it should). I'm
>> not sure why though. In the Sony driver the touchpad axis bits are set
>> in the probe function and work correctly via the evdev interface and
>> looking in the joydev module it should properly handle and map all axes
>> up to ABS_MAX so the problem probably lies somewhere else. If I had to
>> guess, it seems like the joydev device is being created after the HID
>> descriptor is parsed, but before the device probe function is called.
>>
>> Can anyone more familiar with the general input system comment on why
>> this might be happening?
> I find it suspicious that it doesn't happen the first time (after boot)
> that the controller is plugged in, but then does every subsequent time...
> maybe some un-init memory somewhere.
>
> Is this kernel behaviour, or down to the controller state (ie alive after
> first plug)? We see that the DS3 behaves differently wrt leds depending on
> whether it is asleep or alive when plugged in.
>
> I'll dig a little deeper tonight to see if I can track the problem down.
> Simon.
>
It might be a matter of the joydev module not being loaded into memory
the first time thus allowing the probe function to complete and set the
proper axis bits before the js* device is created. On subsequent
connects the module would already be loaded so the js* device would be
created before the extra axis bits are set, assuming that my earlier
hypothesis is correct and the joystick device is being created before
the probe function returns.
The joydev system also zero initializes the mapping arrays and doesn't
filter out unmapped axis or button events, which is why the unmapped
axes always effect axis 0.
^ permalink raw reply
* [PATCH] input: zforce: add regulator handling
From: Heiko Stübner @ 2014-04-22 19:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Henrik Rydberg, linux-input, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, devicetree
In-Reply-To: <2587208.XYbbI8xJiH@phil>
From: Heiko Stuebner <heiko.stuebner@bq.com>
It's possible that the controller has an individually switchable power supply.
Therefore add support to control a supplying regulator.
As this is not always the case, the regulator is requested as optional.
Signed-off-by: Heiko Stuebner <heiko.stuebner@bq.com>
---
.../bindings/input/touchscreen/zforce_ts.txt | 4 +++
drivers/input/touchscreen/zforce_ts.c | 30 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
index 2faf1f1..80c37df 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
@@ -9,6 +9,9 @@ Required properties:
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
+Optional properties:
+- vdd-supply: Regulator controlling the controller supply
+
Example:
i2c@00000000 {
@@ -18,6 +21,7 @@ Example:
compatible = "neonode,zforce";
reg = <0x50>;
interrupts = <2 0>;
+ vdd-supply = <®_zforce_vdd>;
gpios = <&gpio5 6 0>, /* INT */
<&gpio5 9 0>; /* RST */
diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
index 01d30ce..39ca962 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -29,6 +29,8 @@
#include <linux/sysfs.h>
#include <linux/input/mt.h>
#include <linux/platform_data/zforce_ts.h>
+#include <linux/regulator/consumer.h>
+#include <linux/delay.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
@@ -117,6 +119,8 @@ struct zforce_ts {
const struct zforce_ts_platdata *pdata;
char phys[32];
+ struct regulator *reg_vdd;
+
bool suspending;
bool suspended;
bool boot_complete;
@@ -690,6 +694,11 @@ static void zforce_reset(void *data)
struct zforce_ts *ts = data;
gpio_set_value(ts->pdata->gpio_rst, 0);
+
+ udelay(10);
+
+ if (!IS_ERR(ts->reg_vdd))
+ regulator_disable(ts->reg_vdd);
}
static struct zforce_ts_platdata *zforce_parse_dt(struct device *dev)
@@ -765,10 +774,31 @@ static int zforce_probe(struct i2c_client *client,
return ret;
}
+ ts->reg_vdd = devm_regulator_get_optional(&client->dev, "vdd");
+ if (IS_ERR(ts->reg_vdd) && PTR_ERR(ts->reg_vdd) == -EPROBE_DEFER)
+ return PTR_ERR(ts->reg_vdd);
+
+ if (!IS_ERR(ts->reg_vdd)) {
+ ret = regulator_enable(ts->reg_vdd);
+ if (ret)
+ return ret;
+
+ /*
+ * according to datasheet add 100us grace time after regular
+ * regulator enable delay.
+ */
+ udelay(100);
+ }
+
ret = devm_add_action(&client->dev, zforce_reset, ts);
if (ret) {
dev_err(&client->dev, "failed to register reset action, %d\n",
ret);
+
+ /* hereafter the regulator will be disabled by the action */
+ if (!IS_ERR(ts->reg_vdd))
+ regulator_disable(ts->reg_vdd);
+
return ret;
}
--
1.9.0
^ permalink raw reply related
* [PATCH] Input: ads7877: Remove bitrotted comment
From: Mark Brown @ 2014-04-22 21:18 UTC (permalink / raw)
To: Michael Hennerich, Dmitry Torokhov; +Cc: linux-input, linaro-kernel, Mark Brown
From: Mark Brown <broonie@linaro.org>
While searching for users of spi_async() I found a reference in the ad7877
driver to using it to initiate data transfer from the interrupt handler.
However there is no code for this, instead the interrupt handler is a
threaded handler and uses spi_sync() instead.
Remove the bitrotted comment, though in actual fact the use case mentioned
is a great use for spi_async() since it would cut down on latency handling
the interrupt by saving us a context switch before we start SPI.
This was previously implemented, it was removed in commit b534422b2d11
(Input: ad7877 - switch to using threaded IRQ) for code complexity reasons.
It may be better to revert that commit instead.
Signed-off-by: Mark Brown <broonie@linaro.org>
---
drivers/input/touchscreen/ad7877.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c
index 6793c85903ae..523865daa1d3 100644
--- a/drivers/input/touchscreen/ad7877.c
+++ b/drivers/input/touchscreen/ad7877.c
@@ -210,11 +210,6 @@ static bool gpio3;
module_param(gpio3, bool, 0);
MODULE_PARM_DESC(gpio3, "If gpio3 is set to 1 AUX3 acts as GPIO3");
-/*
- * ad7877_read/write are only used for initial setup and for sysfs controls.
- * The main traffic is done using spi_async() in the interrupt handler.
- */
-
static int ad7877_read(struct spi_device *spi, u16 reg)
{
struct ser_req *req;
--
1.9.2
^ permalink raw reply related
* [PATCH] Input: ads7846: Correct log message for spi_sync() errors
From: Mark Brown @ 2014-04-22 21:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linaro-kernel, Mark Brown
From: Mark Brown <broonie@linaro.org>
While searching for users of spi_async() I got a false positive in the
ads7846 driver, fix that.
Signed-off-by: Mark Brown <broonie@linaro.org>
---
drivers/input/touchscreen/ads7846.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 7f8aa981500d..da201b8e37dc 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -706,7 +706,7 @@ static void ads7846_read_state(struct ads7846 *ts)
m = &ts->msg[msg_idx];
error = spi_sync(ts->spi, m);
if (error) {
- dev_err(&ts->spi->dev, "spi_async --> %d\n", error);
+ dev_err(&ts->spi->dev, "spi_sync --> %d\n", error);
packet->tc.ignore = true;
return;
}
--
1.9.2
^ permalink raw reply related
* Re: [PATCH] HID: add missing hid usages
From: Dmitry Torokhov @ 2014-04-23 0:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Olivier Gay, linux-input, Nestor Lopez Casado, Mathieu Meisser
In-Reply-To: <alpine.LNX.2.00.1404070949020.8157@pobox.suse.cz>
On Mon, Apr 07, 2014 at 09:49:52AM +0200, Jiri Kosina wrote:
>
> [ adding Dmitry to CC ]
>
> On Fri, 4 Apr 2014, Olivier Gay wrote:
>
> >
> > #define KEY_ALS_TOGGLE 0x230 /* Ambient light sensor */
> >
> > +#define KEY_BUTTONCONFIG 0x240 /* AL Button Configuration */
> > +#define KEY_TASKMANAGER 0x241 /* AL Task/Project Manager */
> > +#define KEY_JOURNAL 0x242 /* AL Log/Journal/Timecard */
> > +#define KEY_CONTROLPANEL 0x243 /* AL Control Panel */
> > +#define KEY_APPSELECT 0x244 /* AL Select Task/Application */
> > +#define KEY_SCREENSAVER 0x245 /* AL Screen Saver */
> > +#define KEY_VOICECOMMAND 0x246 /* Listening Voice Command */
> > +
> > +#define KEY_BRIGHTNESS_INC KEY_BRIGHTNESSUP
> > +#define KEY_BRIGHTNESS_DEC KEY_BRIGHTNESSDOWN
> > +#define KEY_BRIGHTNESS 0x250 /* Display Brightness */
What is it supposed to do exactly? Show OSD for brightness?
> > +#define KEY_BRIGHTNESS_TOGGLE 0x251 /* Backlight Toggle */
We already have KEY_DISPLAYTOGGLE, isn't this the same?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] evdev: flush ABS_* events during EVIOCGABS
From: Peter Hutterer @ 2014-04-23 0:21 UTC (permalink / raw)
To: David Herrmann
Cc: open list:HID CORE LAYER, Dmitry Torokhov, Benjamin Tissoires
In-Reply-To: <CANq1E4RQtaNNab9PzoBchmx2qqpJ5_PdrZjf2+ZQkq4YTNzXkA@mail.gmail.com>
On Tue, Apr 22, 2014 at 08:21:54AM +0200, David Herrmann wrote:
> Hi Peter
>
> On Tue, Apr 22, 2014 at 6:15 AM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> > How are you planning to handle the slot-based events? We'd either need to
> > add something similar (but more complex) to evdev_handle_mt_request or rely
> > on the caller to call the whole EV_ABS range and ditch anything ABS_MT_.
> > I'd prefer the former, the latter is yet more behaviour that's easy to get
> > wrong.
>
> This is all racy..
>
> We _really_ need an ioctl to receive _all_ ABS information atomically.
> I mean, there's no way we can know the user's state from the kernel.
> Even if the user resyncs via EVIOCGMTSLOTS, we can never flush the
> whole ABS queue. Problem is, the user has to call the ioctl for _each_
> available MT code and events might get queued in between. So yeah,
> this patch doesn't help much..
>
> I have no better idea than adding a new EVIOCGABS call that retrieves
> ABS values for all slots atomically (and for all other axes..). No
> idea how to properly fix the old ioctls.
bonus points for making that ioctl fetch the state of the last SYN_DROPPED
and leave the events since in the client buffer. That way we can smooth over
SYN_DROPPED and lose less information.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH] Input: ads7846: Correct log message for spi_sync() errors
From: Dmitry Torokhov @ 2014-04-23 0:38 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-input, linaro-kernel, Mark Brown
In-Reply-To: <1398201555-13539-1-git-send-email-broonie@kernel.org>
On Tue, Apr 22, 2014 at 10:19:15PM +0100, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> While searching for users of spi_async() I got a false positive in the
> ads7846 driver, fix that.
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
Applied, thank you.
> ---
> drivers/input/touchscreen/ads7846.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index 7f8aa981500d..da201b8e37dc 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -706,7 +706,7 @@ static void ads7846_read_state(struct ads7846 *ts)
> m = &ts->msg[msg_idx];
> error = spi_sync(ts->spi, m);
> if (error) {
> - dev_err(&ts->spi->dev, "spi_async --> %d\n", error);
> + dev_err(&ts->spi->dev, "spi_sync --> %d\n", error);
> packet->tc.ignore = true;
> return;
> }
> --
> 1.9.2
>
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: ads7877: Remove bitrotted comment
From: Dmitry Torokhov @ 2014-04-23 0:39 UTC (permalink / raw)
To: Mark Brown; +Cc: Michael Hennerich, linux-input, linaro-kernel, Mark Brown
In-Reply-To: <1398201501-13470-1-git-send-email-broonie@kernel.org>
On Tue, Apr 22, 2014 at 10:18:21PM +0100, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> While searching for users of spi_async() I found a reference in the ad7877
> driver to using it to initiate data transfer from the interrupt handler.
> However there is no code for this, instead the interrupt handler is a
> threaded handler and uses spi_sync() instead.
>
> Remove the bitrotted comment, though in actual fact the use case mentioned
> is a great use for spi_async() since it would cut down on latency handling
> the interrupt by saving us a context switch before we start SPI.
>
> This was previously implemented, it was removed in commit b534422b2d11
> (Input: ad7877 - switch to using threaded IRQ) for code complexity reasons.
> It may be better to revert that commit instead.
Hmm, maybe.. although I think original would cause device 'stuck' if
call to spi_async() fails, so probably not a straight revert...
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
> ---
> drivers/input/touchscreen/ad7877.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c
> index 6793c85903ae..523865daa1d3 100644
> --- a/drivers/input/touchscreen/ad7877.c
> +++ b/drivers/input/touchscreen/ad7877.c
> @@ -210,11 +210,6 @@ static bool gpio3;
> module_param(gpio3, bool, 0);
> MODULE_PARM_DESC(gpio3, "If gpio3 is set to 1 AUX3 acts as GPIO3");
>
> -/*
> - * ad7877_read/write are only used for initial setup and for sysfs controls.
> - * The main traffic is done using spi_async() in the interrupt handler.
> - */
> -
> static int ad7877_read(struct spi_device *spi, u16 reg)
> {
> struct ser_req *req;
> --
> 1.9.2
>
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: atkbd - fix keyboard LG Electronics
From: Dmitry Torokhov @ 2014-04-23 0:42 UTC (permalink / raw)
To: Sheng-Liang Song
Cc: linux-arm-kernel, Shawn Nematbakhsh, linux-input, linux-kernel
In-Reply-To: <1398185970-16331-1-git-send-email-ssl@chromium.org>
Hi Sheng-Liang,
On Tue, Apr 22, 2014 at 09:59:30AM -0700, Sheng-Liang Song wrote:
> After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working.
> The workaround is to issue ATKBD_CMD_RESET_DEF after ATKBD_CMD_RESET_DIS.
Hmm, if ATKBD_CMD_RESET_DIS causes keyboard not working should we
simply not call it on LG devices?
The idea for using ATKBD_CMD_RESET_DIS was for keyboard to stop
generating scan codes so they do not interfere with detection/resume and
issuing ATKBD_CMD_RESET_DEF right after ATKBD_CMD_RESET_DIS keeps
keyboard in exactly the same state as it was before (i.e. generating
scancodes).
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: atkbd - fix keyboard LG Electronics
From: Sheng-Liang Song @ 2014-04-23 1:51 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sheng-Liang Song, Shawn Nematbakhsh, Dmitry Torokhov, linux-input,
linux-kernel
After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working.
The workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
In order to keep the minimum changes to the current atkbd driver,
I add logic to apply the patch if and only if the device is LG LW25-B7HV or P1-J273B.
---
drivers/input/keyboard/atkbd.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..9f82533 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -243,6 +243,8 @@ static void (*atkbd_platform_fixup)(struct atkbd *, const void *data);
static void *atkbd_platform_fixup_data;
static unsigned int (*atkbd_platform_scancode_fixup)(struct atkbd *, unsigned int);
+static void *atkbd_deactivate_fixup;
+
static ssize_t atkbd_attr_show_helper(struct device *dev, char *buf,
ssize_t (*handler)(struct atkbd *, char *));
static ssize_t atkbd_attr_set_helper(struct device *dev, const char *buf, size_t count,
@@ -698,11 +700,13 @@ static int atkbd_activate(struct atkbd *atkbd)
* atkbd_deactivate() resets and disables the keyboard from sending
* keystrokes.
*/
-
static void atkbd_deactivate(struct atkbd *atkbd)
{
struct ps2dev *ps2dev = &atkbd->ps2dev;
+ if (atkbd_deactivate_fixup)
+ return;
+
if (ps2_command(ps2dev, NULL, ATKBD_CMD_RESET_DIS))
dev_err(&ps2dev->serio->dev,
"Failed to deactivate keyboard on %s\n",
@@ -1638,6 +1642,12 @@ static int __init atkbd_setup_scancode_fixup(const struct dmi_system_id *id)
return 1;
}
+static int __init atkbd_setup_deactivate(const struct dmi_system_id *id)
+{
+ atkbd_deactivate_fixup = id->driver_data;
+ return 1;
+}
+
static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
{
.matches = {
@@ -1775,6 +1785,22 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
.callback = atkbd_setup_scancode_fixup,
.driver_data = atkbd_oqo_01plus_scancode_fixup,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LW25-B7HV"),
+ },
+ .callback = atkbd_setup_deactivate,
+ .driver_data = (void*) 1,
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P1-J273B"),
+ },
+ .callback = atkbd_setup_deactivate,
+ .driver_data = (void*) 1,
+ },
{ }
};
--
1.9.1.423.g4596e3a
^ permalink raw reply related
* Re: Bug: HID-Sony: DS4 touch-pad corrupts Axis0
From: simon @ 2014-04-23 3:21 UTC (permalink / raw)
To: Frank Praznik; +Cc: simon, Frank Praznik, HID CORE LAYER, Jiri Kosina
In-Reply-To: <5356A774.5050505@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]
> It might be a matter of the joydev module not being loaded into memory
> the first time thus allowing the probe function to complete and set the
> proper axis bits before the js* device is created. On subsequent
> connects the module would already be loaded so the js* device would be
> created before the extra axis bits are set, assuming that my earlier
> hypothesis is correct and the joystick device is being created before
> the probe function returns.
You are correct... I did some quick testing and it appears that 'joydev'
and 'hid-sony' are remaining loaded after the controller is unplugged.
In this state when the DS4 is reconnected (2nd time) jstest shows 14 axes.
--
Driver version is 2.1.0.
Joystick (Sony Computer Entertainment Wireless Controller) has 14 axes (X,
Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y, (null), (null), (null), (null), (null),
(null))
and 14 buttons (BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect,
BtnStart, BtnMode, BtnThumbL, BtnThumbR, ?, ?).
Testing ... (interrupt to exit)
--
If I 'sudo rmmod joydev' after removing the DS4 and then plug it back in
(3rd time), we get 18 axis (as we should)
--
Driver version is 2.1.0.
Joystick (Sony Computer Entertainment Wireless Controller) has 18 axes (X,
Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y, (null), (null), (null), (null), (null),
(null), (null), (null), (null), (null))
and 14 buttons (BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect,
BtnStart, BtnMode, BtnThumbL, BtnThumbR, ?, ?).
Testing ... (interrupt to exit)
--
Also when in the 'faulty/14 axis' state, I can 'sudo rmmod joydev' and
'sudo modprobe joydev' to return it to the 'correct/18 axes' state without
unplugging the DS4.
The HID report descriptors (from /sys/bus/hid/...) are identical on all
plug in cycles, as is the 'syslog' text.
If I blacklist hid-sony I do not get a 'js0' to check and no report
descriptor is present.
Anything else I can test for you guys?
Simon
[-- Attachment #2: syslog_2nd.txt --]
[-- Type: text/plain, Size: 1285 bytes --]
Apr 22 20:48:07 bigbox kernel: [ 2529.236727] usb 5-2: USB disconnect, device number 3
Apr 22 20:49:10 bigbox kernel: [ 2592.524323] usb 5-2: new full-speed USB device number 4 using uhci_hcd
Apr 22 20:49:11 bigbox kernel: [ 2592.900863] usb 5-2: New USB device found, idVendor=054c, idProduct=05c4
Apr 22 20:49:11 bigbox kernel: [ 2592.900870] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Apr 22 20:49:11 bigbox kernel: [ 2592.900873] usb 5-2: Product: Wireless Controller
Apr 22 20:49:11 bigbox kernel: [ 2592.900875] usb 5-2: Manufacturer: Sony Computer Entertainment
Apr 22 20:49:11 bigbox kernel: [ 2592.907030] sony 0003:054C:05C4.0003: Using modified Dualshock 4 report descriptor with gyroscope axes
Apr 22 20:49:11 bigbox kernel: [ 2592.952084] input: Sony Computer Entertainment Wireless Controller as /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/0003:054C:05C4.0003/input/input6
Apr 22 20:49:11 bigbox kernel: [ 2592.952404] sony 0003:054C:05C4.0003: input,hidraw1: USB HID v1.11 Gamepad [Sony Computer Entertainment Wireless Controller] on usb-0000:00:1d.3-2/input0
Apr 22 20:49:11 bigbox mtp-probe: checking bus 5, device 4: "/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-2"
Apr 22 20:49:11 bigbox mtp-probe: bus: 5, device: 4 was not an MTP device
[-- Attachment #3: syslog_3rd.txt --]
[-- Type: text/plain, Size: 1285 bytes --]
Apr 22 20:50:40 bigbox kernel: [ 2682.258150] usb 5-2: USB disconnect, device number 4
Apr 22 20:51:45 bigbox kernel: [ 2747.112424] usb 5-2: new full-speed USB device number 5 using uhci_hcd
Apr 22 20:51:45 bigbox kernel: [ 2747.284439] usb 5-2: New USB device found, idVendor=054c, idProduct=05c4
Apr 22 20:51:45 bigbox kernel: [ 2747.284446] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Apr 22 20:51:45 bigbox kernel: [ 2747.284450] usb 5-2: Product: Wireless Controller
Apr 22 20:51:45 bigbox kernel: [ 2747.284452] usb 5-2: Manufacturer: Sony Computer Entertainment
Apr 22 20:51:45 bigbox kernel: [ 2747.290508] sony 0003:054C:05C4.0004: Using modified Dualshock 4 report descriptor with gyroscope axes
Apr 22 20:51:45 bigbox kernel: [ 2747.335577] input: Sony Computer Entertainment Wireless Controller as /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/0003:054C:05C4.0004/input/input7
Apr 22 20:51:45 bigbox kernel: [ 2747.335881] sony 0003:054C:05C4.0004: input,hidraw1: USB HID v1.11 Gamepad [Sony Computer Entertainment Wireless Controller] on usb-0000:00:1d.3-2/input0
Apr 22 20:51:45 bigbox mtp-probe: checking bus 5, device 5: "/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-2"
Apr 22 20:51:45 bigbox mtp-probe: bus: 5, device: 5 was not an MTP device
^ permalink raw reply
* Re: [PATCH] evdev: flush ABS_* events during EVIOCGABS
From: Peter Hutterer @ 2014-04-23 5:38 UTC (permalink / raw)
To: David Herrmann
Cc: open list:HID CORE LAYER, Dmitry Torokhov, Benjamin Tissoires
In-Reply-To: <20140423002103.GA6917@yabbi.bne.redhat.com>
On Wed, Apr 23, 2014 at 10:21:03AM +1000, Peter Hutterer wrote:
> On Tue, Apr 22, 2014 at 08:21:54AM +0200, David Herrmann wrote:
> > Hi Peter
> >
> > On Tue, Apr 22, 2014 at 6:15 AM, Peter Hutterer
> > <peter.hutterer@who-t.net> wrote:
> > > How are you planning to handle the slot-based events? We'd either need to
> > > add something similar (but more complex) to evdev_handle_mt_request or rely
> > > on the caller to call the whole EV_ABS range and ditch anything ABS_MT_.
> > > I'd prefer the former, the latter is yet more behaviour that's easy to get
> > > wrong.
> >
> > This is all racy..
> >
> > We _really_ need an ioctl to receive _all_ ABS information atomically.
> > I mean, there's no way we can know the user's state from the kernel.
> > Even if the user resyncs via EVIOCGMTSLOTS, we can never flush the
> > whole ABS queue. Problem is, the user has to call the ioctl for _each_
> > available MT code and events might get queued in between. So yeah,
> > this patch doesn't help much..
> >
> > I have no better idea than adding a new EVIOCGABS call that retrieves
> > ABS values for all slots atomically (and for all other axes..). No
> > idea how to properly fix the old ioctls.
>
> bonus points for making that ioctl fetch the state of the last SYN_DROPPED
> and leave the events since in the client buffer. That way we can smooth over
> SYN_DROPPED and lose less information.
to expand on this, something like the below would work from userspace:
1. userspace opens fd, EVIOCGBIT for everything
2. userspace calls EVIOCGABSATOMIC
3. kernel empties the event queue, flags the client as capable
4. kernel copies current device state into client-specific struct
5. kernel replies with that device state to the ioctl
6. client reads events
..
7. kernel sees a SYN_DROPPED for this client. Takes a snapshot of the device
for the client, empties the buffer, leaves SYN_DROPPED in the buffer
(current behaviour)
8. client reads SYN_DROPPED, calls EVIOCGABSATOMIC
9. kernel replies with the snapshot state, leaves the event buffer otherwise
unmodified
10. client reads all events after SYN_DROPPED, gets a smooth continuation
11. goto 6
if the buffer overflows multiple times, repeat 7 so that the snapshot state
is always the last SYN_DROPPED state. well, technically the state should be
the state of the device at the first SYN_REPORT after the last SYN_DROPPED,
since the current API says that interrupted event is incomplete.
there are two oddities here:
1. the first ioctl will have to flush the buffer to guarantee consistent state,
though you could even avoid that by taking a snapshot of the device on
open(). though that comes with a disadvantage, you don't know if the client
supports the new approach so you're wasting effort and memory here.
2. I'm not quite sure how to handle multiple repeated calls short of
updating the client-specific snapshot with every event as it is read
successfully.
any comments?
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH] evdev: flush ABS_* events during EVIOCGABS
From: Dmitry Torokhov @ 2014-04-23 5:46 UTC (permalink / raw)
To: Peter Hutterer
Cc: David Herrmann, open list:HID CORE LAYER, Benjamin Tissoires
In-Reply-To: <20140423053849.GA4036@yabbi.redhat.com>
On Wed, Apr 23, 2014 at 03:38:49PM +1000, Peter Hutterer wrote:
> On Wed, Apr 23, 2014 at 10:21:03AM +1000, Peter Hutterer wrote:
> > On Tue, Apr 22, 2014 at 08:21:54AM +0200, David Herrmann wrote:
> > > Hi Peter
> > >
> > > On Tue, Apr 22, 2014 at 6:15 AM, Peter Hutterer
> > > <peter.hutterer@who-t.net> wrote:
> > > > How are you planning to handle the slot-based events? We'd either need to
> > > > add something similar (but more complex) to evdev_handle_mt_request or rely
> > > > on the caller to call the whole EV_ABS range and ditch anything ABS_MT_.
> > > > I'd prefer the former, the latter is yet more behaviour that's easy to get
> > > > wrong.
> > >
> > > This is all racy..
> > >
> > > We _really_ need an ioctl to receive _all_ ABS information atomically.
> > > I mean, there's no way we can know the user's state from the kernel.
> > > Even if the user resyncs via EVIOCGMTSLOTS, we can never flush the
> > > whole ABS queue. Problem is, the user has to call the ioctl for _each_
> > > available MT code and events might get queued in between. So yeah,
> > > this patch doesn't help much..
> > >
> > > I have no better idea than adding a new EVIOCGABS call that retrieves
> > > ABS values for all slots atomically (and for all other axes..). No
> > > idea how to properly fix the old ioctls.
> >
> > bonus points for making that ioctl fetch the state of the last SYN_DROPPED
> > and leave the events since in the client buffer. That way we can smooth over
> > SYN_DROPPED and lose less information.
>
> to expand on this, something like the below would work from userspace:
>
> 1. userspace opens fd, EVIOCGBIT for everything
> 2. userspace calls EVIOCGABSATOMIC
> 3. kernel empties the event queue, flags the client as capable
> 4. kernel copies current device state into client-specific struct
> 5. kernel replies with that device state to the ioctl
> 6. client reads events
> ..
> 7. kernel sees a SYN_DROPPED for this client. Takes a snapshot of the device
> for the client, empties the buffer, leaves SYN_DROPPED in the buffer
> (current behaviour)
> 8. client reads SYN_DROPPED, calls EVIOCGABSATOMIC
> 9. kernel replies with the snapshot state, leaves the event buffer otherwise
> unmodified
> 10. client reads all events after SYN_DROPPED, gets a smooth continuation
> 11. goto 6
>
> if the buffer overflows multiple times, repeat 7 so that the snapshot state
> is always the last SYN_DROPPED state. well, technically the state should be
> the state of the device at the first SYN_REPORT after the last SYN_DROPPED,
> since the current API says that interrupted event is incomplete.
>
> there are two oddities here:
> 1. the first ioctl will have to flush the buffer to guarantee consistent state,
> though you could even avoid that by taking a snapshot of the device on
> open(). though that comes with a disadvantage, you don't know if the client
> supports the new approach so you're wasting effort and memory here.
> 2. I'm not quite sure how to handle multiple repeated calls short of
> updating the client-specific snapshot with every event as it is read
> successfully.
>
> any comments?
Do we really need to optimize the case when we are dropping events?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] soc_button_array: fix a crash during rmmod
From: Dmitry Torokhov @ 2014-04-23 5:53 UTC (permalink / raw)
To: Zhu, Lejun; +Cc: linux-input, linux-kernel
In-Reply-To: <53560E6F.9000806@linux.intel.com>
On Tue, Apr 22, 2014 at 02:38:39PM +0800, Zhu, Lejun wrote:
> When the system has zero or one button available, trying to rmmod
> soc_button_array will cause crash. Fix this by properly handling -ENODEV
> in probe().
>
> Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Applied, thank you.
> ---
> drivers/input/misc/soc_button_array.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/misc/soc_button_array.c
> b/drivers/input/misc/soc_button_array.c
> index 08ead2a..20c80f5 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -169,6 +169,7 @@ static int soc_button_pnp_probe(struct pnp_dev *pdev,
> soc_button_remove(pdev);
> return error;
> }
> + continue;
> }
>
> priv->children[i] = pd;
> --
> 1.8.3.2
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] evdev: flush ABS_* events during EVIOCGABS
From: Peter Hutterer @ 2014-04-23 5:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: David Herrmann, open list:HID CORE LAYER, Benjamin Tissoires
In-Reply-To: <20140423054647.GA24854@core.coreip.homeip.net>
On Tue, Apr 22, 2014 at 10:46:47PM -0700, Dmitry Torokhov wrote:
> On Wed, Apr 23, 2014 at 03:38:49PM +1000, Peter Hutterer wrote:
> > On Wed, Apr 23, 2014 at 10:21:03AM +1000, Peter Hutterer wrote:
> > > On Tue, Apr 22, 2014 at 08:21:54AM +0200, David Herrmann wrote:
> > > > Hi Peter
> > > >
> > > > On Tue, Apr 22, 2014 at 6:15 AM, Peter Hutterer
> > > > <peter.hutterer@who-t.net> wrote:
> > > > > How are you planning to handle the slot-based events? We'd either need to
> > > > > add something similar (but more complex) to evdev_handle_mt_request or rely
> > > > > on the caller to call the whole EV_ABS range and ditch anything ABS_MT_.
> > > > > I'd prefer the former, the latter is yet more behaviour that's easy to get
> > > > > wrong.
> > > >
> > > > This is all racy..
> > > >
> > > > We _really_ need an ioctl to receive _all_ ABS information atomically.
> > > > I mean, there's no way we can know the user's state from the kernel.
> > > > Even if the user resyncs via EVIOCGMTSLOTS, we can never flush the
> > > > whole ABS queue. Problem is, the user has to call the ioctl for _each_
> > > > available MT code and events might get queued in between. So yeah,
> > > > this patch doesn't help much..
> > > >
> > > > I have no better idea than adding a new EVIOCGABS call that retrieves
> > > > ABS values for all slots atomically (and for all other axes..). No
> > > > idea how to properly fix the old ioctls.
> > >
> > > bonus points for making that ioctl fetch the state of the last SYN_DROPPED
> > > and leave the events since in the client buffer. That way we can smooth over
> > > SYN_DROPPED and lose less information.
> >
> > to expand on this, something like the below would work from userspace:
> >
> > 1. userspace opens fd, EVIOCGBIT for everything
> > 2. userspace calls EVIOCGABSATOMIC
> > 3. kernel empties the event queue, flags the client as capable
> > 4. kernel copies current device state into client-specific struct
> > 5. kernel replies with that device state to the ioctl
> > 6. client reads events
> > ..
> > 7. kernel sees a SYN_DROPPED for this client. Takes a snapshot of the device
> > for the client, empties the buffer, leaves SYN_DROPPED in the buffer
> > (current behaviour)
> > 8. client reads SYN_DROPPED, calls EVIOCGABSATOMIC
> > 9. kernel replies with the snapshot state, leaves the event buffer otherwise
> > unmodified
> > 10. client reads all events after SYN_DROPPED, gets a smooth continuation
> > 11. goto 6
> >
> > if the buffer overflows multiple times, repeat 7 so that the snapshot state
> > is always the last SYN_DROPPED state. well, technically the state should be
> > the state of the device at the first SYN_REPORT after the last SYN_DROPPED,
> > since the current API says that interrupted event is incomplete.
> >
> > there are two oddities here:
> > 1. the first ioctl will have to flush the buffer to guarantee consistent state,
> > though you could even avoid that by taking a snapshot of the device on
> > open(). though that comes with a disadvantage, you don't know if the client
> > supports the new approach so you're wasting effort and memory here.
> > 2. I'm not quite sure how to handle multiple repeated calls short of
> > updating the client-specific snapshot with every event as it is read
> > successfully.
> >
> > any comments?
>
> Do we really need to optimize the case when we are dropping events?
It happens frequently, to the point where on some laptops you're pretty much
guaranteed to get SYN_DROPPED events on resume and sometimes even during
normal multi-finger user.
I don't have any measurements on how many events are dropped on average.
Could be one or two, could be several buffer sizes, I honestly don't know.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH 0/6] input: cyapa: integrated with gen5 trackpad supported in one driver.
From: Dmitry Torokhov @ 2014-04-23 5:59 UTC (permalink / raw)
To: Dudley Du
Cc: Benson Leung, Daniel Kurtz, David Solda,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <77BC725C9062764F874D79F51E1F1A8F40C153FF@S04-MBX01-01.s04.local>
Hi Dudley,
On Tue, Apr 22, 2014 at 08:39:43AM +0000, Dudley Du wrote:
> Hi Dmitry,
>
> Could you help review the patches of input: cyapa for re-architecture
> and supporting new trackpad devices, I'm really looking forward your
> responses.
It is on my TODO list, sorry it takes too long...
Thanks.
--
Dmitry
^ 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