* Re: EVIOCSFF macro inconsistency
From: Dmitry Torokhov @ 2014-09-08 20:24 UTC (permalink / raw)
To: Elias Vanderstuyft; +Cc: open list:HID CORE LAYER
In-Reply-To: <CADbOyBT_UJJg3d4VYGi5Xry4L5egqc_T3_PGEL7th=4TO=NPcA@mail.gmail.com>
On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote:
> On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov
>
> <dmitry.torokhov@gmail.com> wrote:
> > Hi Elias,
> >
> > On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:
> >> Hi everyone,
> >>
> >> After inspecting the <linux/input.h> header file, I found that there
> >> is one single ioctl value macro that is inconsistent w.r.t. the other
> >>
> >> macros that do an IOC_WRITE :
> >> EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
> >>
> >> Why not define it as follows? :
> >> EVIOCSFF _IOW('E', 0x80, struct ff_effect)
> >>
> >> Apart from having a more readable definition, it also explicitly
> >> reveals type info ("struct ff_effect").
> >
> > I think it is just historical.
> >
> >> Is it worth to create a patch to fix it?
> >
> > Sure, why not.
>
> Cool, thanks!
>
> So probably the same applies to the IOC_READ counter parts? :
> EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + (ev), len)
> EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len)
> EVIOCGLED(len) _IOC(_IOC_READ, 'E', 0x19, len)
> EVIOCGMTSLOTS(len) _IOC(_IOC_READ, 'E', 0x0a, len)
> EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len)
> EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len)
> EVIOCGPROP(len) _IOC(_IOC_READ, 'E', 0x09, len)
> EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len)
> EVIOCGSW(len) _IOC(_IOC_READ, 'E', 0x1b, len)
> EVIOCGUNIQ(len) _IOC(_IOC_READ, 'E', 0x08, len)
> to be converted to:
> EVIOCGBIT(ev,len) _IOR('E', 0x20 + (ev), len)
> EVIOCGKEY(len) _IOR('E', 0x18, len)
> EVIOCGLED(len) _IOR('E', 0x19, len)
> EVIOCGMTSLOTS(len) _IOR('E', 0x0a, len)
> EVIOCGNAME(len) _IOR('E', 0x06, len)
> EVIOCGPHYS(len) _IOR('E', 0x07, len)
> EVIOCGPROP(len) _IOR('E', 0x09, len)
> EVIOCGSND(len) _IOR('E', 0x1a, len)
> EVIOCGSW(len) _IOR('E', 0x1b, len)
> EVIOCGUNIQ(len) _IOR('E', 0x08, len)
No, because 'len' is not a type.
Thanks.
--
Dmitry
^ permalink raw reply
* 0930:0807 Toshiba Corp. not recognized
From: Andrea Momesso @ 2014-09-08 19:36 UTC (permalink / raw)
To: linux-input
The device 0930:0807 Toshiba Corp. is a trackpad. The kernel
doesn't recognize it and I have to add this quirk to my bootloader to
have it to work: usbhid.quirks=0x0930:0x0807:0x0040
Anyway with the quirk it is recognized but I get very limited
functionality (no scrolling, no middle click etc), and it is
recognized as a mouse input instead of an event input.
I've seen a bug for the same device has been opened for Ubuntu here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1280839
The laptop that ships this device (Toshiba Portege Z10t A) has also a
trackpad that seems to be connected to the touchpad (it only works
when I use the quirk and I don't see any other entries in lsusb
related to that device). Using the quirk trackpad buttons will work,
while touchpad buttons don't.
Thank you
--
Momesso Andrea
^ permalink raw reply
* Re: EVIOCSFF macro inconsistency
From: Elias Vanderstuyft @ 2014-09-08 19:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: open list:HID CORE LAYER
In-Reply-To: <20140908183157.GA36623@core.coreip.homeip.net>
On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Elias,
>
> On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:
>> Hi everyone,
>>
>> After inspecting the <linux/input.h> header file, I found that there
>> is one single ioctl value macro that is inconsistent w.r.t. the other
>> macros that do an IOC_WRITE :
>> EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
>> Why not define it as follows? :
>> EVIOCSFF _IOW('E', 0x80, struct ff_effect)
>> Apart from having a more readable definition, it also explicitly
>> reveals type info ("struct ff_effect").
>
> I think it is just historical.
>
>> Is it worth to create a patch to fix it?
>
> Sure, why not.
Cool, thanks!
So probably the same applies to the IOC_READ counter parts? :
EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + (ev), len)
EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len)
EVIOCGLED(len) _IOC(_IOC_READ, 'E', 0x19, len)
EVIOCGMTSLOTS(len) _IOC(_IOC_READ, 'E', 0x0a, len)
EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len)
EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len)
EVIOCGPROP(len) _IOC(_IOC_READ, 'E', 0x09, len)
EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len)
EVIOCGSW(len) _IOC(_IOC_READ, 'E', 0x1b, len)
EVIOCGUNIQ(len) _IOC(_IOC_READ, 'E', 0x08, len)
to be converted to:
EVIOCGBIT(ev,len) _IOR('E', 0x20 + (ev), len)
EVIOCGKEY(len) _IOR('E', 0x18, len)
EVIOCGLED(len) _IOR('E', 0x19, len)
EVIOCGMTSLOTS(len) _IOR('E', 0x0a, len)
EVIOCGNAME(len) _IOR('E', 0x06, len)
EVIOCGPHYS(len) _IOR('E', 0x07, len)
EVIOCGPROP(len) _IOR('E', 0x09, len)
EVIOCGSND(len) _IOR('E', 0x1a, len)
EVIOCGSW(len) _IOR('E', 0x1b, len)
EVIOCGUNIQ(len) _IOR('E', 0x08, len)
Thanks,
Elias
^ permalink raw reply
* Re: EVIOCSFF macro inconsistency
From: Dmitry Torokhov @ 2014-09-08 18:31 UTC (permalink / raw)
To: Elias Vanderstuyft; +Cc: open list:HID CORE LAYER
In-Reply-To: <CADbOyBRcKFntUAruYTGcqzt2Vi=MHJDFoZK5v4fE8WLFjT0viw@mail.gmail.com>
Hi ELias,
On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:
> Hi everyone,
>
> After inspecting the <linux/input.h> header file, I found that there
> is one single ioctl value macro that is inconsistent w.r.t. the other
> macros that do an IOC_WRITE :
> EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
> Why not define it as follows? :
> EVIOCSFF _IOW('E', 0x80, struct ff_effect)
> Apart from having a more readable definition, it also explicitly
> reveals type info ("struct ff_effect").
I think it is just historical.
> Is it worth to create a patch to fix it?
Sure, why not.
Thanks.
--
Dmitry
^ permalink raw reply
* EVIOCSFF macro inconsistency
From: Elias Vanderstuyft @ 2014-09-08 18:14 UTC (permalink / raw)
To: open list:HID CORE LAYER; +Cc: Dmitry Torokhov
Hi everyone,
After inspecting the <linux/input.h> header file, I found that there
is one single ioctl value macro that is inconsistent w.r.t. the other
macros that do an IOC_WRITE :
EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
Why not define it as follows? :
EVIOCSFF _IOW('E', 0x80, struct ff_effect)
Apart from having a more readable definition, it also explicitly
reveals type info ("struct ff_effect").
Is it worth to create a patch to fix it?
Thanks,
Elias
^ permalink raw reply
* RE:
From: Deborah Mayher @ 2014-09-08 17:36 UTC (permalink / raw)
To: Deborah Mayher
In-Reply-To: <6A286AB51AD8EC4180C4B2E9EF1D0A027AAD7EFF1E@exmb01.wrschool.net>
________________________________
From: Deborah Mayher
Sent: Monday, September 08, 2014 10:13 AM
To: Deborah Mayher
Subject:
IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security. You need to update your account immediately for activation. Click the website below for activation:
Click Here<http://motorgumishop.hu/tmp/393934>
You will not be able to send or receive mail if activation is not complete.
IT Message Center.
^ permalink raw reply
* [PATCH] Input: synaptics - add support for ForcePads
From: Dmitry Torokhov @ 2014-09-08 16:55 UTC (permalink / raw)
To: linux-input
Cc: Hans de Goede, Benjamin Tissoires, Christopher Heiny,
linux-kernel
ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.
For now we are using DMI matching to detect ForcePads, hopefully we'll
be able to figure a better way down the road.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/synaptics.c | 80 ++++++++++++++++++++++++++++++++---------
drivers/input/mouse/synaptics.h | 5 +++
2 files changed, 69 insertions(+), 16 deletions(-)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index e8573c6..5de1bb6 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -618,6 +618,8 @@ static void synaptics_parse_agm(const unsigned char buf[],
priv->agm_pending = true;
}
+static bool is_forcepad;
+
static int synaptics_parse_hw_state(const unsigned char buf[],
struct synaptics_data *priv,
struct synaptics_hw_state *hw)
@@ -629,10 +631,58 @@ static int synaptics_parse_hw_state(const unsigned char buf[],
((buf[0] & 0x04) >> 1) |
((buf[3] & 0x04) >> 2));
+ if ((SYN_CAP_ADV_GESTURE(priv->ext_cap_0c) ||
+ SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)) &&
+ hw->w == 2) {
+ synaptics_parse_agm(buf, priv, hw);
+ return 1;
+ }
+
+ hw->x = (((buf[3] & 0x10) << 8) |
+ ((buf[1] & 0x0f) << 8) |
+ buf[4]);
+ hw->y = (((buf[3] & 0x20) << 7) |
+ ((buf[1] & 0xf0) << 4) |
+ buf[5]);
+ hw->z = buf[2];
+
hw->left = (buf[0] & 0x01) ? 1 : 0;
hw->right = (buf[0] & 0x02) ? 1 : 0;
- if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) {
+ if (is_forcepad) {
+ /* XXX is there a proper capability bit for this? */
+ /*
+ * ForcePads, like Clickpads, use middle button
+ * bits to report primary button clicks.
+ * Unfortunately they report primary button not only
+ * when user presses on the pad above certain threshold,
+ * but also when there are more than one finger on the
+ * touchpad, which interferes with out multi-finger
+ * gestures.
+ */
+ if (hw->z == 0) {
+ /* No contacts */
+ priv->press = priv->report_press = false;
+ } else if (hw->w >= 4 && ((buf[0] ^ buf[3]) & 0x01)) {
+ /*
+ * Single-finger touch with pressure above
+ * the threshold.
+ */
+ if (!priv->press) {
+ priv->press_start = jiffies;
+ priv->press = true;
+ } else if (time_after(jiffies,
+ priv->press_start +
+ msecs_to_jiffies(50))) {
+ priv->report_press = true;
+ }
+ } else {
+ priv->press = false;
+ }
+
+ hw->left = priv->report_press;
+
+ } else if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) {
/*
* Clickpad's button is transmitted as middle button,
* however, since it is primary button, we will report
@@ -651,21 +701,6 @@ static int synaptics_parse_hw_state(const unsigned char buf[],
hw->down = ((buf[0] ^ buf[3]) & 0x02) ? 1 : 0;
}
- if ((SYN_CAP_ADV_GESTURE(priv->ext_cap_0c) ||
- SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)) &&
- hw->w == 2) {
- synaptics_parse_agm(buf, priv, hw);
- return 1;
- }
-
- hw->x = (((buf[3] & 0x10) << 8) |
- ((buf[1] & 0x0f) << 8) |
- buf[4]);
- hw->y = (((buf[3] & 0x20) << 7) |
- ((buf[1] & 0xf0) << 4) |
- buf[5]);
- hw->z = buf[2];
-
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
((buf[0] ^ buf[3]) & 0x02)) {
switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
@@ -1642,11 +1677,24 @@ static const struct dmi_system_id __initconst cr48_dmi_table[] = {
{ }
};
+static const struct dmi_system_id forcepad_dmi_table[] __initconst = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook Folio 1040 G1"),
+ },
+ },
+#endif
+ { }
+};
+
void __init synaptics_module_init(void)
{
impaired_toshiba_kbc = dmi_check_system(toshiba_dmi_table);
broken_olpc_ec = dmi_check_system(olpc_dmi_table);
cr48_profile_sensor = dmi_check_system(cr48_dmi_table);
+ is_forcepad = dmi_check_system(forcepad_dmi_table);
}
static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode)
diff --git a/drivers/input/mouse/synaptics.h b/drivers/input/mouse/synaptics.h
index e594af0..adc80c9 100644
--- a/drivers/input/mouse/synaptics.h
+++ b/drivers/input/mouse/synaptics.h
@@ -177,6 +177,11 @@ struct synaptics_data {
*/
struct synaptics_hw_state agm;
bool agm_pending; /* new AGM packet received */
+
+ /* ForcePad handling */
+ unsigned long press_start;
+ bool press;
+ bool report_press;
};
void synaptics_module_init(void);
--
2.1.0.rc2.206.gedb03e5
--
Dmitry
^ permalink raw reply related
* Re: [PATCH v2 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
From: Andrew Bresticker @ 2014-09-08 16:16 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Lee Jones, Wolfram Sang, Dmitry Torokhov, Doug Anderson,
Simon Glass, Bill Richardson, Derek Basehore, Todd Broch,
Olof Johansson, linux-i2c, linux-input, linux-samsung-soc
In-Reply-To: <540D9577.9000702@collabora.co.uk>
On Mon, Sep 8, 2014 at 4:39 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Lee,
>
> On 09/04/2014 10:34 AM, Lee Jones wrote:
>> On Mon, 25 Aug 2014, Javier Martinez Canillas wrote:
>>> From: Andrew Bresticker <abrestic@chromium.org>
>>>
>>> When an EC command returns EC_RES_IN_PROGRESS, we need to query
>>> the state of the EC until it indicates that it is no longer busy.
>>> Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
>>> commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
>>> it is working on the in-progress command.
>>>
>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>>
>>> Changes since v1:
>>> - The *xfer() calls don't modify the passed cros_ec_command so there is
>>> no need to populate it inside the for loop. Suggested by Lee Jones.
>>> ---
>>> drivers/mfd/cros_ec.c | 34 +++++++++++++++++++++++++++++++++-
>>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
>>> index c53804a..cd0c93c 100644
>>> --- a/drivers/mfd/cros_ec.c
>>> +++ b/drivers/mfd/cros_ec.c
>>> @@ -23,6 +23,10 @@
>>> #include <linux/mfd/core.h>
>>> #include <linux/mfd/cros_ec.h>
>>> #include <linux/mfd/cros_ec_commands.h>
>>> +#include <linux/delay.h>
>>> +
>>> +#define EC_COMMAND_RETRIES 50
>>> +#define EC_RETRY_DELAY_MS 10
>>
>> Where did these values come from?
>>
>
> These patches were taken from the ChromeOS 3.8 kernel so I don't really know
> why these values were chosen. I'll let Andrew or one of the ChromiumOS folks
> to answer this question.
These are the values flashrom used when retrying commands.
^ permalink raw reply
* Re: [PATCH v3 2/4] Input: misc: Add haptic driver on max77693
From: Lee Jones @ 2014-09-08 13:05 UTC (permalink / raw)
To: Jaewon Kim
Cc: Dmitry Torokhov, Samuel Ortiz, linux-kernel, linux-input,
Chanwoo Choi
In-Reply-To: <1409917702-17009-3-git-send-email-jaewon02.kim@samsung.com>
On Fri, 05 Sep 2014, Jaewon Kim wrote:
> This patch add max77693-haptic device driver to support the haptic controller
> on MAX77693. The MAX77693 is a Multifunction device with PMIC, CHARGER, LED,
> MUIC, HAPTIC and the patch is haptic device driver in the MAX77693. This driver
> support external pwm and LRA(Linear Resonant Actuator) motor. User can control
> the haptic driver by using force feedback framework.
>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
So I guess we just need a Maintainer Ack for this, then we can take in
the set?
Can the other patches in the set be applied without this one?
> ---
> drivers/input/misc/Kconfig | 12 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/max77693-haptic.c | 321 ++++++++++++++++++++++++++++++++++
> include/linux/mfd/max77693-private.h | 9 +
> 4 files changed, 343 insertions(+)
> create mode 100644 drivers/input/misc/max77693-haptic.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 2ff4425..c597c52 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -144,6 +144,18 @@ config INPUT_M68K_BEEP
> tristate "M68k Beeper support"
> depends on M68K
>
> +config INPUT_MAX77693_HAPTIC
> + tristate "MAXIM MAX77693 haptic controller support"
> + depends on MFD_MAX77693 && PWM
> + select INPUT_FF_MEMLESS
> + help
> + This option enables device driver support for the haptic controller
> + on MAXIM MAX77693 chip. This driver supports ff-memless interface
> + from input framework.
> +
> + To compile this driver as module, choose M here: the
> + module will be called max77693-haptic.
> +
> config INPUT_MAX8925_ONKEY
> tristate "MAX8925 ONKEY support"
> depends on MFD_MAX8925
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 4955ad3..b28570c 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
> obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
> obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
> obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
> +obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
> obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
> obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
> obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
> diff --git a/drivers/input/misc/max77693-haptic.c b/drivers/input/misc/max77693-haptic.c
> new file mode 100644
> index 0000000..d06026b
> --- /dev/null
> +++ b/drivers/input/misc/max77693-haptic.c
> @@ -0,0 +1,321 @@
> +/*
> + * max77693-haptic.c - MAXIM MAX77693 Haptic device driver
> + *
> + * Copyright (C) 2014 Samsung Electronics
> + * Jaewon Kim <jaewon02.kim@samsung.com>
> + *
> + * This program is not provided / owned by Maxim Integrated Products.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include <linux/regmap.h>
> +#include <linux/input.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/slab.h>
> +#include <linux/workqueue.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/mfd/max77693.h>
> +#include <linux/mfd/max77693-private.h>
> +
> +#define MAX_MAGNITUDE_SHIFT 16
> +
> +enum max77693_haptic_motor_type {
> + MAX77693_HAPTIC_ERM = 0,
> + MAX77693_HAPTIC_LRA,
> +};
> +
> +enum max77693_haptic_pulse_mode {
> + MAX77693_HAPTIC_EXTERNAL_MODE = 0,
> + MAX77693_HAPTIC_INTERNAL_MODE,
> +};
> +
> +enum max77693_haptic_pwm_divisor {
> + MAX77693_HAPTIC_PWM_DIVISOR_32 = 0,
> + MAX77693_HAPTIC_PWM_DIVISOR_64,
> + MAX77693_HAPTIC_PWM_DIVISOR_128,
> + MAX77693_HAPTIC_PWM_DIVISOR_256,
> +};
> +
> +struct max77693_haptic {
> + struct regmap *regmap_pmic;
> + struct regmap *regmap_haptic;
> + struct device *dev;
> + struct input_dev *input_dev;
> + struct pwm_device *pwm_dev;
> + struct regulator *motor_reg;
> +
> + bool enabled;
> + unsigned int magnitude;
> + unsigned int pwm_duty;
> + enum max77693_haptic_motor_type type;
> + enum max77693_haptic_pulse_mode mode;
> + enum max77693_haptic_pwm_divisor pwm_divisor;
> +
> + struct work_struct work;
> +};
> +
> +static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
> +{
> + int ret;
> + int delta = (haptic->pwm_dev->period + haptic->pwm_duty)/2;
> +
> + ret = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
> + if (ret) {
> + dev_err(haptic->dev, "cannot configuration pwm\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int max77693_haptic_configure(struct max77693_haptic *haptic,
> + unsigned int enable)
> +{
> + int ret;
> + unsigned int value = 0;
> +
> + value = ((haptic->type << MAX77693_CONFIG2_MODE) |
> + (enable << MAX77693_CONFIG2_MEN) |
> + (haptic->mode << MAX77693_CONFIG2_HTYP) |
> + (haptic->pwm_divisor));
> +
> + ret = regmap_write(haptic->regmap_haptic,
> + MAX77693_HAPTIC_REG_CONFIG2, value);
> + if (ret) {
> + dev_err(haptic->dev, "cannot write haptic regmap\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int max77693_haptic_lowsys(struct max77693_haptic *haptic,
> + unsigned int enable)
> +{
> + int ret;
> +
> + ret = regmap_update_bits(haptic->regmap_pmic,
> + MAX77693_PMIC_REG_LSCNFG,
> + MAX77693_PMIC_LOW_SYS_MASK,
> + enable << MAX77693_PMIC_LOW_SYS_SHIFT);
> + if (ret) {
> + dev_err(haptic->dev, "cannot update pmic regmap\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void max77693_haptic_enable(struct max77693_haptic *haptic)
> +{
> + int ret;
> +
> + if (haptic->enabled)
> + return;
> +
> + ret = pwm_enable(haptic->pwm_dev);
> + if (ret) {
> + dev_err(haptic->dev, "cannot enable haptic pwm device");
> + return;
> + }
> +
> + ret = max77693_haptic_lowsys(haptic, 1);
> + if (ret)
> + goto err_enable_lowsys;
> +
> + ret = max77693_haptic_configure(haptic, 1);
> + if (ret)
> + goto err_enable_config;
> +
> + haptic->enabled = true;
> +
> + return;
> +
> +err_enable_config:
> + max77693_haptic_lowsys(haptic, 0);
> +err_enable_lowsys:
> + pwm_disable(haptic->pwm_dev);
> +}
> +
> +static void max77693_haptic_disable(struct max77693_haptic *haptic)
> +{
> + int ret;
> +
> + if (!haptic->enabled)
> + return;
> +
> + ret = max77693_haptic_configure(haptic, 0);
> + if (ret)
> + return;
> +
> + ret = max77693_haptic_lowsys(haptic, 0);
> + if (ret)
> + goto err_disable_lowsys;
> +
> + pwm_disable(haptic->pwm_dev);
> + haptic->enabled = false;
> +
> + return;
> +
> +err_disable_lowsys:
> + max77693_haptic_configure(haptic, 1);
> +}
> +
> +static void max77693_haptic_play_work(struct work_struct *work)
> +{
> + struct max77693_haptic *haptic =
> + container_of(work, struct max77693_haptic, work);
> + int ret;
> +
> + ret = max77693_haptic_set_duty_cycle(haptic);
> + if (ret) {
> + dev_err(haptic->dev, "cannot set duty cycle\n");
> + return;
> + }
> +
> + if (haptic->magnitude)
> + max77693_haptic_enable(haptic);
> + else
> + max77693_haptic_disable(haptic);
> +}
> +
> +static int max77693_haptic_play_effect(struct input_dev *dev, void *data,
> + struct ff_effect *effect)
> +{
> + struct max77693_haptic *haptic = input_get_drvdata(dev);
> + uint64_t period_mag_multi;
> +
> + haptic->magnitude = effect->u.rumble.strong_magnitude;
> + if (!haptic->magnitude)
> + haptic->magnitude = effect->u.rumble.weak_magnitude;
> +
> + /*
> + * The magnitude comes from force-feedback interface.
> + * The formula convert magnitude to pwm_duty as following:
> + * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0xFFFF)
> + */
> + period_mag_multi = (int64_t)(haptic->pwm_dev->period *
> + haptic->magnitude);
> + haptic->pwm_duty = (unsigned int)(period_mag_multi >>
> + MAX_MAGNITUDE_SHIFT);
> +
> + schedule_work(&haptic->work);
> +
> + return 0;
> +}
> +
> +static void max77693_haptic_close(struct input_dev *dev)
> +{
> + struct max77693_haptic *haptic = input_get_drvdata(dev);
> +
> + cancel_work_sync(&haptic->work);
> + max77693_haptic_disable(haptic);
> +}
> +
> +static int max77693_haptic_probe(struct platform_device *pdev)
> +{
> + struct max77693_dev *max77693 = dev_get_drvdata(pdev->dev.parent);
> + struct max77693_haptic *haptic;
> + int ret = 0;
> +
> + haptic = devm_kzalloc(&pdev->dev, sizeof(*haptic), GFP_KERNEL);
> + if (!haptic)
> + return -ENOMEM;
> +
> + haptic->regmap_pmic = max77693->regmap;
> + haptic->regmap_haptic = max77693->regmap_haptic;
> + haptic->dev = &pdev->dev;
> + haptic->type = MAX77693_HAPTIC_LRA;
> + haptic->mode = MAX77693_HAPTIC_EXTERNAL_MODE;
> + haptic->pwm_divisor = MAX77693_HAPTIC_PWM_DIVISOR_128;
> +
> + /* Get pwm and regulatot for haptic device */
> + haptic->pwm_dev = devm_pwm_get(&pdev->dev, NULL);
> + if (IS_ERR(haptic->pwm_dev)) {
> + dev_err(&pdev->dev, "failed to get pwm device\n");
> + return PTR_ERR(haptic->pwm_dev);
> + }
> +
> + haptic->motor_reg = devm_regulator_get(&pdev->dev, "haptic");
> + if (IS_ERR(haptic->motor_reg)) {
> + dev_err(&pdev->dev, "failed to get regulator\n");
> + return PTR_ERR(haptic->motor_reg);
> + }
> +
> + ret = regulator_enable(haptic->motor_reg);
> + if (ret) {
> + dev_err(haptic->dev, "failed to enable regulator\n");
> + return ret;
> + }
> +
> + /* Initialize input device for haptic device */
> + haptic->input_dev = devm_input_allocate_device(&pdev->dev);
> + if (!haptic->input_dev) {
> + dev_err(&pdev->dev, "failed to allocate input device\n");
> + return -ENOMEM;
> + }
> +
> + haptic->input_dev->name = "max77693-haptic";
> + haptic->input_dev->id.version = 1;
> + haptic->input_dev->dev.parent = &pdev->dev;
> + haptic->input_dev->close = max77693_haptic_close;
> + input_set_drvdata(haptic->input_dev, haptic);
> + input_set_capability(haptic->input_dev, EV_FF, FF_RUMBLE);
> +
> + ret = input_ff_create_memless(haptic->input_dev, NULL,
> + max77693_haptic_play_effect);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to create force-feedback\n");
> + return ret;
> + }
> +
> + ret = input_register_device(haptic->input_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register input device\n");
> + return ret;
> + }
> +
> + INIT_WORK(&haptic->work, max77693_haptic_play_work);
> +
> + platform_set_drvdata(pdev, haptic);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int max77693_haptic_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct max77693_haptic *haptic = platform_get_drvdata(pdev);
> +
> + max77693_haptic_disable(haptic);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(max77693_haptic_pm_ops, max77693_haptic_suspend, NULL);
> +
> +static struct platform_driver max77693_haptic_driver = {
> + .driver = {
> + .name = "max77693-haptic",
> + .owner = THIS_MODULE,
> + .pm = &max77693_haptic_pm_ops,
> + },
> + .probe = max77693_haptic_probe,
> +};
> +module_platform_driver(max77693_haptic_driver);
> +
> +MODULE_AUTHOR("Jaewon Kim <jaewon02.kim@samsung.com>");
> +MODULE_DESCRIPTION("MAXIM MAX77693 Haptic driver");
> +MODULE_ALIAS("platform:max77693-haptic");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/max77693-private.h b/include/linux/mfd/max77693-private.h
> index c466ff3..d0e578f 100644
> --- a/include/linux/mfd/max77693-private.h
> +++ b/include/linux/mfd/max77693-private.h
> @@ -251,6 +251,15 @@ enum max77693_haptic_reg {
> MAX77693_HAPTIC_REG_END,
> };
>
> +/* max77693-pmic LSCNFG configuraton register */
> +#define MAX77693_PMIC_LOW_SYS_MASK 0x80
> +#define MAX77693_PMIC_LOW_SYS_SHIFT 7
> +
> +/* max77693-haptic configuration register */
> +#define MAX77693_CONFIG2_MODE 7
> +#define MAX77693_CONFIG2_MEN 6
> +#define MAX77693_CONFIG2_HTYP 5
> +
> enum max77693_irq_source {
> LED_INT = 0,
> TOPSYS_INT,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [PATCH v2 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
From: Lee Jones @ 2014-09-08 12:48 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, linux-i2c, linux-input, linux-samsung-soc
In-Reply-To: <540D9577.9000702@collabora.co.uk>
On Mon, 08 Sep 2014, Javier Martinez Canillas wrote:
> On 09/04/2014 10:34 AM, Lee Jones wrote:
> > On Mon, 25 Aug 2014, Javier Martinez Canillas wrote:
> >> From: Andrew Bresticker <abrestic@chromium.org>
> >>
> >> When an EC command returns EC_RES_IN_PROGRESS, we need to query
> >> the state of the EC until it indicates that it is no longer busy.
> >> Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
> >> commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
> >> it is working on the in-progress command.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> Reviewed-by: Simon Glass <sjg@chromium.org>
> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> >> ---
> >>
> >> Changes since v1:
> >> - The *xfer() calls don't modify the passed cros_ec_command so there is
> >> no need to populate it inside the for loop. Suggested by Lee Jones.
> >> ---
> >> drivers/mfd/cros_ec.c | 34 +++++++++++++++++++++++++++++++++-
> >> 1 file changed, 33 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> >> index c53804a..cd0c93c 100644
> >> --- a/drivers/mfd/cros_ec.c
> >> +++ b/drivers/mfd/cros_ec.c
[...]
> >> mutex_lock(&ec_dev->lock);
> >> ret = ec_dev->cmd_xfer(ec_dev, msg);
> >> + if (ret == -EAGAIN && msg->result == EC_RES_IN_PROGRESS) {
> >
> > Is there ever a time where (ret == -EAGAIN) but (msg->result !=
> > EC_RES_IN_PROGRESS) [note the !=]. And/or is there ever a time where
> > (msg->result == EC_RES_IN_PROGRESS) but (ret != -EAGAIN) [again, not
> > the !=].
> >
> > Another way of explaining it. Can ret be anything other than -EAGAIN
> > when the result is EC_RES_IN_PROGRESS. And can the result be anything
> > other than EC_RES_IN_PROGRESS when ret is -EAGAIN?
[...]
> But after looking at all the cros_ec transport drivers it seems to be safe to
> just check if result is EC_RES_IN_PROGRESS instead of checking also if ret is
> -EAGAIN since (at least on all the current transport drivers) the former
> implies the later.
That's exactly what I was getting at.
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
From: Javier Martinez Canillas @ 2014-09-08 11:39 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, linux-i2c, linux-input, linux-samsung-soc
In-Reply-To: <20140904083426.GD8257@lee--X1>
Hello Lee,
On 09/04/2014 10:34 AM, Lee Jones wrote:
> On Mon, 25 Aug 2014, Javier Martinez Canillas wrote:
>> From: Andrew Bresticker <abrestic@chromium.org>
>>
>> When an EC command returns EC_RES_IN_PROGRESS, we need to query
>> the state of the EC until it indicates that it is no longer busy.
>> Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
>> commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
>> it is working on the in-progress command.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Reviewed-by: Simon Glass <sjg@chromium.org>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>
>> Changes since v1:
>> - The *xfer() calls don't modify the passed cros_ec_command so there is
>> no need to populate it inside the for loop. Suggested by Lee Jones.
>> ---
>> drivers/mfd/cros_ec.c | 34 +++++++++++++++++++++++++++++++++-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
>> index c53804a..cd0c93c 100644
>> --- a/drivers/mfd/cros_ec.c
>> +++ b/drivers/mfd/cros_ec.c
>> @@ -23,6 +23,10 @@
>> #include <linux/mfd/core.h>
>> #include <linux/mfd/cros_ec.h>
>> #include <linux/mfd/cros_ec_commands.h>
>> +#include <linux/delay.h>
>> +
>> +#define EC_COMMAND_RETRIES 50
>> +#define EC_RETRY_DELAY_MS 10
>
> Where did these values come from?
>
These patches were taken from the ChromeOS 3.8 kernel so I don't really know
why these values were chosen. I'll let Andrew or one of the ChromiumOS folks
to answer this question.
>> int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>> struct cros_ec_command *msg)
>> @@ -65,10 +69,38 @@ EXPORT_SYMBOL(cros_ec_check_result);
>> int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>> struct cros_ec_command *msg)
>> {
>> - int ret;
>> + int ret, i;
>> + struct cros_ec_command status_msg;
>> + struct ec_response_get_comms_status status;
>
> Please put these inside the if().
>
Ok.
>> mutex_lock(&ec_dev->lock);
>> ret = ec_dev->cmd_xfer(ec_dev, msg);
>> + if (ret == -EAGAIN && msg->result == EC_RES_IN_PROGRESS) {
>
> Is there ever a time where (ret == -EAGAIN) but (msg->result !=
> EC_RES_IN_PROGRESS) [note the !=]. And/or is there ever a time where
> (msg->result == EC_RES_IN_PROGRESS) but (ret != -EAGAIN) [again, not
> the !=].
>
> Another way of explaining it. Can ret be anything other than -EAGAIN
> when the result is EC_RES_IN_PROGRESS. And can the result be anything
> other than EC_RES_IN_PROGRESS when ret is -EAGAIN?
>
For the first question, no. ret is always -EAGAIN when result is
EC_RES_IN_PROGRESS.
All the cros_ec transport drivers (cros_ec_{i2c,spi,lpc}) have the following
code block:
switch (msg->result) {
...
case EC_RES_IN_PROGRESS:
ret = -EAGAIN;
...
};
For the second question, yes AFAICT. Some transports transfer function return
-EAGAIN and that error is propagated. As an example i2c_transfer() returns
-EAGAIN if the struct i2c_adapter bus_lock mutex is tried to be acquired.
But after looking at all the cros_ec transport drivers it seems to be safe to
just check if result is EC_RES_IN_PROGRESS instead of checking also if ret is
-EAGAIN since (at least on all the current transport drivers) the former
implies the later.
>> + /*
>> + * Query the EC's status until it's no longer busy or
>> + * we encounter an error.
>> + */
>> + status_msg.version = 0;
>> + status_msg.command = EC_CMD_GET_COMMS_STATUS;
>> + status_msg.outdata = NULL;
>> + status_msg.outsize = 0;
>> + status_msg.indata = (uint8_t *)&status;
>> + status_msg.insize = sizeof(status);
>> +
>> + for (i = 0; i < EC_COMMAND_RETRIES; i++) {
>> + msleep(EC_RETRY_DELAY_MS);
>
> msleep() doesn't handle any time below 20ms well, use usleep() or even
> better usleep_range() instead.
>
Ok.
>> + ret = ec_dev->cmd_xfer(ec_dev, &status_msg);
>> + if (ret < 0)
>> + break;
>
> What does a ret of >0 mean?
>
When ret > 0, it means the actual amount of data received in the transfer.
>> + msg->result = status_msg.result;
>> + if (status_msg.result != EC_RES_SUCCESS)
>> + break;
>> + if (!(status.flags & EC_COMMS_STATUS_PROCESSING))
>> + break;
>> + }
>> + }
>> mutex_unlock(&ec_dev->lock);
>>
>> return ret;
>
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH v2 6/7] mfd: cros_ec: Instantiate sub-devices from device tree
From: Javier Martinez Canillas @ 2014-09-08 10:57 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140904082513.GC8257@lee--X1>
Hello Lee,
Sorry for the delay but had been on holidays last week.
On 09/04/2014 10:25 AM, Lee Jones wrote:
>>
>> -static const struct mfd_cell cros_devs[] = {
>> - {
>> - .name = "cros-ec-keyb",
>> - .id = 1,
>> - .of_compatible = "google,cros-ec-keyb",
>> - },
>> - {
>> - .name = "cros-ec-i2c-tunnel",
>> - .id = 2,
>> - .of_compatible = "google,cros-ec-i2c-tunnel",
>> - },
>> -};
>> -
>> int cros_ec_register(struct cros_ec_device *ec_dev)
>> {
>> struct device *dev = ec_dev->dev;
>> +#ifdef CONFIG_OF
>> + struct device_node *node = dev->of_node;
>> +#endif
>
> Drop the #ifdiffery.
>
I used the #ifdef guards because I remembered of_node being conditionally
build but I see that this is not longer true after commmit:
c9e358d driver-core: remove conditionals around devicetree pointers
So I'll remove it, thanks for the pointer.
>> int err = 0;
>>
>> if (ec_dev->din_size) {
>> @@ -138,13 +129,19 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>>
>> mutex_init(&ec_dev->lock);
>>
>> - err = mfd_add_devices(dev, 0, cros_devs,
>> - ARRAY_SIZE(cros_devs),
>> - NULL, ec_dev->irq, NULL);
>> - if (err) {
>> - dev_err(dev, "failed to add mfd devices\n");
>> - return err;
>> +#ifdef CONFIG_OF
>
> And here.
>
Nod.
>> + /*
>> + * Add sub-devices declared in the device tree. NOTE they should NOT be
>> + * declared in cros_devs
>> + */
>
> Drop this comment. cros_devs no longer exists and we know what
> of_platform_populate() does.
>
Ok.
>> + if (node) {
>> + err = of_platform_populate(node, NULL, NULL, dev);
>> + if (err) {
>> + dev_err(dev, "fail to add %s\n", node->full_name);
>
> That's not true. Just put "Failed to register subordinate devices".
>
Ok.
>> + return err;
>> + }
>> }
>> +#endif
>>
>> dev_info(dev, "Chrome EC device registered\n");
>>
>
Thanks a lot for the feedback and best regards,
Javier
^ permalink raw reply
* Re: [PATCH] usbhid: fix PIXART optical mouse
From: Jiri Kosina @ 2014-09-08 9:26 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-input, johan
In-Reply-To: <1410168109-16005-1-git-send-email-oneukum@suse.de>
On Mon, 8 Sep 2014, Oliver Neukum wrote:
> This mouse keeps disconnecting in runlevel 3. It needs the
> ALWAYS_POLL quirk.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied to hid.git#for-3.18/always-poll-quirk, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] usbhid: fix PIXART optical mouse
From: Oliver Neukum @ 2014-09-08 9:21 UTC (permalink / raw)
To: jkosina, linux-input, johan; +Cc: Oliver Neukum
This mouse keeps disconnecting in runlevel 3. It needs the
ALWAYS_POLL quirk.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0d2e07d..c2aca75 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -736,6 +736,7 @@
#define USB_DEVICE_ID_PI_ENGINEERING_VEC_USB_FOOTPEDAL 0xff
#define USB_VENDOR_ID_PIXART 0x093a
+#define USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE 0x2510
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN 0x8001
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1 0x8002
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2 0x8003
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index ca18136..8c97e63 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -80,6 +80,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1610, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1640, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2, HID_QUIRK_NO_INIT_REPORTS },
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH] HID: rmi: check sanity of the incoming report
From: Jiri Kosina @ 2014-09-08 8:13 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Andrew Duggan, linux-input, linux-kernel
In-Reply-To: <1409925435-6556-1-git-send-email-benjamin.tissoires@redhat.com>
On Fri, 5 Sep 2014, Benjamin Tissoires wrote:
> In the Dell XPS 13 9333, it appears that sometimes the bus get confused
> and corrupts the incoming data. It fills the input report with the
> sentinel value "ff". Synaptics told us that such behavior does not comes
> from the touchpad itself, so we filter out such reports here.
>
> Unfortunately, we can not simply discard the incoming data because they
> may contain useful information. Most of the time, the misbehavior is
> quite near the end of the report, so we can still use the valid part of
> it.
>
> Fixes:
> https://bugzilla.redhat.com/show_bug.cgi?id=1123584
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> drivers/hid/hid-rmi.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 8389e81..db92c3b 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -320,9 +320,6 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 irq, u8 *data,
> int offset;
> int i;
>
> - if (size < hdata->f11.report_size)
> - return 0;
> -
> if (!(irq & hdata->f11.irq_mask))
> return 0;
>
> @@ -332,9 +329,13 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 irq, u8 *data,
> int fs_bit_position = (i & 0x3) << 1;
> int finger_state = (data[fs_byte_position] >> fs_bit_position) &
> 0x03;
> + int position = offset + 5 * i;
> +
> + if (position + 5 > size)
> + /* partial report, go on with what we received */
> + break;
Do you perhaps want to warn the user here, so that he knows that things
are getting a little bit hairy? Or is this happening so often that it
makes no sense to warn about it?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] HID: usbhid: fix Elan touchscreen disconnects
From: Jiri Kosina @ 2014-09-08 7:30 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg KH, Alan Stern, Bjørn Mork, Sarah Sharp,
Drew Von Spreecken, Mathias Nyman, linux-usb, linux-input,
Oliver Neukum
In-Reply-To: <1409933328-7190-1-git-send-email-johan@kernel.org>
On Fri, 5 Sep 2014, Johan Hovold wrote:
> Here's the always-poll quirk that is needed to prevent the Elan
> touchscreen from disconnecting itself from the bus.
>
> These patches are against v3.16.1, but applies fine to hid-next.
>
> Note that this series is not dependent on the device-qualifier quirk
> [1], which is needed to get the same device to enumerate reliably, so
> these two quirks could in through the USB and HID tree, respectively.
Thanks for respinning this patchset. I have queued it for 3.18.
Oliver, could you please send me your patch for 0x093a / 0x2510 so that I
could apply it on top of this?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] xpad: sync device IDs with xboxdrv
From: Benjamin Valentin @ 2014-09-06 12:47 UTC (permalink / raw)
To: linux-input, linux-kernel; +Cc: Dmitry Torokhov, Ted Mielczarek, Paul Gortmaker
The userspace xboxdrv driver knows some more device ids than the kernel.
This patch adds the missing xbox gamepads from [1] to xpad.c
[1] https://github.com/Grumbel/xboxdrv/blob/master/src/xpad_device.cpp
Signed-off-by: Benjamin Valentin <benpicco@zedat.fu-berlin.de>
---
drivers/input/joystick/xpad.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 177602c..5ebf37d 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -126,7 +126,9 @@ static const struct xpad_device {
{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
+ { 0x044f, 0xb326, "Thrustmaster Gamepad GP XID", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
+ { 0x046d, 0xc21e, "Logitech Gamepad F510", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
{ 0x046d, 0xca84, "Logitech Xbox Cordless Controller", 0, XTYPE_XBOX },
@@ -140,10 +142,17 @@ static const struct xpad_device {
{ 0x0738, 0x4540, "Mad Catz Beat Pad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x0738, 0x4556, "Mad Catz Lynx Wireless Controller", 0, XTYPE_XBOX },
{ 0x0738, 0x4716, "Mad Catz Wired Xbox 360 Controller", 0, XTYPE_XBOX360 },
+ { 0x0738, 0x4718, "Mad Catz Street Fighter IV FightStick SE", 0, XTYPE_XBOX360 },
+ { 0x0738, 0x4726, "Mad Catz Xbox 360 Controller", 0, XTYPE_XBOX360 },
{ 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0738, 0x4738, "Mad Catz Wired Xbox 360 Controller (SFIV)", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
+ { 0x0738, 0x4740, "Mad Catz Beat Pad", 0, XTYPE_XBOX360 },
{ 0x0738, 0x6040, "Mad Catz Beat Pad Pro", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
+ { 0x0738, 0xb726, "Mad Catz Xbox controller - MW2", 0, XTYPE_XBOX360 },
{ 0x0738, 0xbeef, "Mad Catz JOYTECH NEO SE Advanced GamePad", XTYPE_XBOX360 },
+ { 0x0738, 0xcb02, "Saitek Cyborg Rumble Pad - PC/Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x0738, 0xcb03, "Saitek P3200 Rumble Pad - PC/Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x0738, 0xf738, "Super SFIV FightStick TE S", 0, XTYPE_XBOX360 },
{ 0x0c12, 0x8802, "Zeroplus Xbox Controller", 0, XTYPE_XBOX },
{ 0x0c12, 0x8809, "RedOctane Xbox Dance Pad", DANCEPAD_MAP_CONFIG, XTYPE_XBOX },
{ 0x0c12, 0x880a, "Pelican Eclipse PL-2023", 0, XTYPE_XBOX },
@@ -156,28 +165,49 @@ static const struct xpad_device {
{ 0x0e6f, 0x0005, "Eclipse wireless Controller", 0, XTYPE_XBOX },
{ 0x0e6f, 0x0006, "Edge wireless Controller", 0, XTYPE_XBOX },
{ 0x0e6f, 0x0105, "HSM3 Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
+ { 0x0e6f, 0x0113, "Afterglow AX.1 Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x0201, "Pelican PL-3601 'TSZ' Wired Xbox 360 Controller", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x0213, "Afterglow Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x0e6f, 0x021f, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 },
+ { 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
{ 0x0e8f, 0x0201, "SmartJoy Frag Xpad/PS2 adaptor", 0, XTYPE_XBOX },
+ { 0x0e8f, 0x3008, "Generic xbox control (dealextreme)", 0, XTYPE_XBOX },
+ { 0x0f0d, 0x000a, "Hori Co. DOA4 FightStick", 0, XTYPE_XBOX360 },
{ 0x0f0d, 0x000d, "Hori Fighting Stick EX2", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0f0d, 0x0016, "Hori Real Arcade Pro.EX", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0f30, 0x0202, "Joytech Advanced Controller", 0, XTYPE_XBOX },
{ 0x0f30, 0x8888, "BigBen XBMiniPad Controller", 0, XTYPE_XBOX },
{ 0x102c, 0xff0c, "Joytech Wireless Advanced Controller", 0, XTYPE_XBOX },
{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
+ { 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x1430, 0x4748, "RedOctane Guitar Hero X-plorer", 0, XTYPE_XBOX360 },
{ 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0, XTYPE_XBOX360 },
+ { 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
+ { 0x15e4, 0x3f00, "Power A Mini Pro Elite", 0, XTYPE_XBOX360 },
+ { 0x15e4, 0x3f0a, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 },
+ { 0x15e4, 0x3f10, "Batarang Xbox 360 controller", 0, XTYPE_XBOX360 },
+ { 0x162e, 0xbeef, "Joytech Neo-Se Take2", 0, XTYPE_XBOX360 },
{ 0x1689, 0xfd00, "Razer Onza Tournament Edition", 0, XTYPE_XBOX360 },
{ 0x1689, 0xfd01, "Razer Onza Classic Edition", 0, XTYPE_XBOX360 },
{ 0x1bad, 0x0002, "Harmonix Rock Band Guitar", 0, XTYPE_XBOX360 },
{ 0x1bad, 0x0003, "Harmonix Rock Band Drumkit", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x1bad, 0xf016, "Mad Catz Xbox 360 Controller", 0, XTYPE_XBOX360 },
+ { 0x1bad, 0xf023, "MLG Pro Circuit Controller (Xbox)", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xf028, "Street Fighter IV FightPad", 0, XTYPE_XBOX360 },
+ { 0x1bad, 0xf038, "Street Fighter IV FightStick TE", 0, XTYPE_XBOX360 },
+ { 0x1bad, 0xf900, "Harmonix Xbox 360 Controller", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xf901, "Gamestop Xbox 360 Controller", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xf903, "Tron Xbox 360 controller", 0, XTYPE_XBOX360 },
+ { 0x24c6, 0x5000, "Razer Atrox Arcade Stick", 0, XTYPE_XBOX360 },
{ 0x24c6, 0x5300, "PowerA MINI PROEX Controller", 0, XTYPE_XBOX360 },
+ { 0x24c6, 0x5303, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 },
+ { 0x24c6, 0x5500, "Hori XBOX 360 EX 2 with Turbo", 0, XTYPE_XBOX360 },
+ { 0x24c6, 0x5501, "Hori Real Arcade Pro VX-SA", 0, XTYPE_XBOX360 },
+ { 0x24c6, 0x5506, "Hori SOULCALIBUR V Stick", 0, XTYPE_XBOX360 },
+ { 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0, XTYPE_XBOX360 },
{ 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
{ 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
};
@@ -274,6 +304,9 @@ static struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x0f0d), /* Hori Controllers */
XPAD_XBOX360_VENDOR(0x1689), /* Razer Onza */
XPAD_XBOX360_VENDOR(0x24c6), /* PowerA Controllers */
+ XPAD_XBOX360_VENDOR(0x1532), /* Razer Sabertooth */
+ XPAD_XBOX360_VENDOR(0x15e4), /* Numark X-Box 360 controllers */
+ XPAD_XBOX360_VENDOR(0x162e), /* Joytech X-Box 360 controllers */
{ }
};
^ permalink raw reply related
* Re: Driver for Logitech M560
From: Goffredo Baroncelli @ 2014-09-05 17:47 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Nestor Lopez Casado, HID CORE LAYER
In-Reply-To: <CAN+gG=HMUJBWQj65OKRfoPiyzzRPXLVveA6V2S_a1dSJXKJc3g@mail.gmail.com>
On 09/03/2014 11:36 PM, Benjamin Tissoires wrote:
> Hi Goffredo,
>
> On Mon, Sep 1, 2014 at 3:20 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
>> Hi Benjamin,
>>
>> following the Nestor suggestion, I rewrote the driver for the
>> mouse Logitech M560 on the basis of your work (branch "for-whot").
>
> Just for the record. This branch is located here:
> https://github.com/bentiss/hid-logitech-dj/tree/for-whot and I
> *really* need to finish this work so that everything can go upstream
> :(
:-) For me this is not a problem. I solved my issue (I made a dkms
package for this mouse), but I want to share my effort..
>
>>
>> The Logitech M560 is is a mouse designed for windows 8.
>> Comparing to a standard one, some buttons (the middle one and the
>> two ones placed on the side) are bounded to a key combination
>> instead of a classic "mouse" button.
>>
>> Think this mouse as a pair of mouse and keyboard. When the middle
>> button is pressed the it sends a key (as keyboard)
>> combination, the same for the other two side button.
>> Instead the left/right/wheel work correctly.
>> To complicate further the things, the middle button send a
>> key combination the odd press, and another one for the even press;
>> in the latter case it sends also a left click. But the worst thing
>> is that no event is generated when the middle button is released.
>>
>> Moreover this device is a wireless mouse which uses the unifying
>> receiver.
>>
>> I discovered that it is possible to re-configure the mouse
>> sending a command (see function m560_send_config_command()).
>> After this command the mouse sends some sequence when the
>> buttons are pressed and/or released (see comments for
>> an explanation of the mouse protocol).
>>
>> If the mouse is "silent" (no data is sent) for more than
>> PACKET_TIMEOUT seconds (currently 10), when the next packet
>> comes, the driver try to reconfigure it.
>> This because it is possible that the mouse is switched-off
>> and lost its setting. Se we need to reconfigure.
>
> This just looks weird. I am pretty sure we managed to properly tackle
> that for the touchpads, there should not be any difference with the
> mouse. Or maybe we did not?
> Anyway, calling this every timeout is not a good solution IMO.
I looked at the wtp source, and I was not able to find anything.
Anyway I will remove the reset-by-timeout; eventually I split this
in another patch for further development
>
>
>>
>> Benjamin, I have to highlight three things:
>> when the dj driver detects a disconnection, it
>> sends a sequence like
>>
>> 0x01 0x00 0x00 0x00 0x00 0x00 0x00 ...
>> 0x02 0x00 0x00 0x00 0x00 0x00 0x00 ...
>>
>> because the mouse is both a keyboard (0x01) and
>> a mouse (0x02). But this sequence is a valid one
>> (when two buttons are released) due to the strangeness
>> of the protocol.
>>
>> Can I suggest to send in these case a sequence like
>>
>> <device_type> 0xff 0xff 0xff 0xff 0xff 0xff....
>>
>> ? I suspect that this would be less common.
>
> Nope. This does not work. The idea behind sending the "null" report is
> that this report will reset the current state of the keyboards/mice by
> sending a "all buttons are now released" event. It is _not_ designed
> as a marker that the device has been disconnected.
>
> If you need this info, then another mechanism has to be used.
Have you any suggestions ?
>
>>
>> Another thing that seemed strange to me is that report
>> with ID equal 0x20 and 0x21 are handled so the packet
>> are forwarded to the driver from the 3rd byte onward.
>
> Yes. 0x20 and 0x21 are DJ reports, which encapsulate a mouse/keyboard
> report coming from the DJ device.
> To be properly handled by the final driver, we have to remove the
> encapsulation fields so that the reports are just plain HID.
>
>> In the others cases (this mouse send also packet with
>> ID=0x11) the report id forwarded as is (without
>> by-passing the first two bytes). It is the expected
>> behaviour, or the code was written on the basis the
>> assumption that the devices send ID=0x20/0x21 and the
>> other ID are sent only by the receiver ?
>
> No. The 0x10/0x11 reports are from the HID++ Logitech-specific
> implementation, and must be forwarded as is. They have to be handled
> as such by the final driver, and so, they must keep their report ID.
Ok, I don't have any problem about that. I want to be sure that it
is intentionally and not an hole discovered due to the M560 mouse
protocol.
>
>>
>> Finally I have to point out that to work, this driver
>> has to be inserted BEFORE the hid_logitech_dj
>>
>> In fact I had to add a file /etc/modprobe.d/hid-logitech_dj.conf
>> as below
>>
>> install hid_logitech_dj modprobe hid_logitech_m560; sleep 5s ; modprobe --ignore-install hid_logitech_dj
>>
>> It is possible that the "sleep 5s" is not needed.
>
> Hmm. This might be because there are some conflicts between your
> current install and the one you just changed. I would not worry about
> that. When this work will land upstream, there will be not problems.
>
> I still did not decided if I am going to take this right now into the
> github tree or not (and make a deeper review).
>
> BTW, there is no need to send such patch to the LKML currently, you
> are working against my non upstream branch. What you can do is either
> setup a github clone with your patch/modifications if you want to
> share them, or I can also pull this in a separate branch.
Ok, I will prepare (I hope this week-end) a github repo for a pull.
Let me to remove the reset-by-timeout code.
>
> Once I'll finish the changes I want to do to hid-logitech-dj and
> hid-logitech-hidpp, then we can think of merging that in my
> submission.
> Sorry, I still need a little bit of time to finish up this work.
Ok, thanks
> Cheers,
> Benjamin
>
[... cut ... cut ... ]
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Bug ID: 83911 Summary: Thermaltake USB Gaming Mouse not working
From: Laurent Debian @ 2014-09-05 16:16 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
Hi all,
I was asked to send you a bug report I just submit so here we are :
the bug is there https://bugzilla.kernel.org/show_bug.cgi?id=83911.
I reproduce it here :
I have a usb mouse model : TT esport Sapphira, from thermaltake.
When I plug it in I have this kernel messages
[ 1019.645758] usb 1-1.6.2: new full-speed USB device number 8 using ehci-pci
[ 1019.741008] usb 1-1.6.2: New USB device found, idVendor=04f2,
idProduct=1106
[ 1019.741016] usb 1-1.6.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 1019.741020] usb 1-1.6.2: Product: USB Gaming Mouse
[ 1019.741024] usb 1-1.6.2: Manufacturer: Thermaltake
[ 1019.742903] input: Thermaltake USB Gaming Mouse as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.2/1-1.6.2:1.0/input/input23
[ 1019.743530] hid-generic 0003:04F2:1106.0006: input,hidraw1: USB HID v1.11
Mouse [Thermaltake USB Gaming Mouse] on usb-0000:00:1a.0-1.6.2/input0
[ 1019.747180] input: Thermaltake USB Gaming Mouse as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.2/1-1.6.2:1.1/input/input24
[ 1019.749302] hid-generic 0003:04F2:1106.0007: input,hiddev0,hidraw2: USB HID
v1.11 Keyboard [Thermaltake USB Gaming Mouse] on usb-0000:00:1a.0-1.6.2/input1
So the usb mouse is properly identify but that's about it. Nothing more,the
mouse is not powered (non of the led-light neither the laser produce light)
and of course neither clicking or moving the mouse do anything.
To add to the confusion in rare occasions, ( +/- 3 times in one month of using
the computer each day) it get powered and works correctly. One time it
occurred I checked the modules loaded and messages from the kernel but I did
not find anything relevant.
I normally use occurs a kernel 3.13.0-24-generic of Linux mint package (aka
Ubuntu kernel), but I tested as well with the last kernel from git which was
at the time 3.17-rc3 and the problem was still there.
Attached a lsmod result.
Ps: I know I use nvidia binary but this problem happened before, so please
just ignore it.
[-- Attachment #2: lsmod.txt --]
[-- Type: text/plain, Size: 2739 bytes --]
Module Size Used by
nls_utf8 12557 1
udf 89723 1
nls_iso8859_1 12713 1
crc_itu_t 12707 1 udf
pci_stub 12622 1
vboxpci 23194 0
vboxnetadp 25670 0
vboxnetflt 27613 0
vboxdrv 339502 3 vboxnetadp,vboxnetflt,vboxpci
rfcomm 69160 0
bnep 19624 2
bluetooth 395423 10 bnep,rfcomm
binfmt_misc 17468 1
gpio_ich 13476 0
dm_multipath 22873 0
scsi_dh 14882 1 dm_multipath
joydev 17381 0
uvcvideo 80885 0
videobuf2_vmalloc 13216 1 uvcvideo
videobuf2_memops 13362 1 videobuf2_vmalloc
videobuf2_core 40664 1 uvcvideo
videodev 134688 2 uvcvideo,videobuf2_core
snd_hda_codec_hdmi 46207 1
intel_powerclamp 14705 0
coretemp 13435 0
kvm 451511 0
nvidia 10675249 39
serio_raw 13462 0
snd_hda_codec_realtek 61438 1
snd_hda_intel 52355 0
snd_hda_codec 192906 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_hwdep 13602 1 snd_hda_codec
lpc_ich 21080 0
snd_pcm 102099 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
drm 302817 2 nvidia
snd_seq_midi 13324 0
snd_seq_midi_event 14899 1 snd_seq_midi
snd_rawmidi 30144 1 snd_seq_midi
wmi 19177 0
snd_seq 61560 2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer 29482 2 snd_pcm,snd_seq
snd 69238 11 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
soundcore 12680 1 snd
mac_hid 13205 0
mei_me 18627 0
mei 82274 1 mei_me
parport_pc 32701 0
ppdev 17671 0
lp 17759 0
parport 42348 3 lp,ppdev,parport_pc
dm_mirror 22135 0
dm_region_hash 20862 1 dm_mirror
dm_log 18411 2 dm_region_hash,dm_mirror
usb_storage 62209 1
hid_generic 12548 0
usbhid 52616 0
hid 106148 2 hid_generic,usbhid
psmouse 102222 0
r8169 67581 0
mii 13934 1 r8169
ahci 25819 3
libahci 32168 1 ahci
^ permalink raw reply
* [PATCH 2/2] HID: usbhid: enable always-poll quirk for Elan Touchscreen
From: Johan Hovold @ 2014-09-05 16:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: Greg KH, Alan Stern, Bjørn Mork, Sarah Sharp,
Drew Von Spreecken, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum, Johan Hovold
In-Reply-To: <1409933328-7190-1-git-send-email-johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Enable the always-poll quirk for Elan Touchscreens found on some recent
Samsung laptops.
Without this quirk the device keeps disconnecting from the bus (and is
re-enumerated) unless opened (and kept open, should an input event
occur).
Note that while the device can be run-time suspended, the autosuspend
timeout must be high enough to allow the device to be polled at least
once before being suspended. Specifically, using autosuspend_delay_ms=0
will still cause the device to disconnect on input events.
Signed-off-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 48b66bb..79b966d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -296,6 +296,9 @@
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7 0x73f7
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001
+#define USB_VENDOR_ID_ELAN 0x04f3
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
+
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 31e6727..72da083 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -70,6 +70,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, HID_QUIRK_NOGET },
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] HID: usbhid: add always-poll quirk
From: Johan Hovold @ 2014-09-05 16:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: Greg KH, Alan Stern, Bjørn Mork, Sarah Sharp,
Drew Von Spreecken, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum, Johan Hovold
In-Reply-To: <1409933328-7190-1-git-send-email-johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/hid/usbhid/hid-core.c | 26 +++++++++++++++++++++++---
include/linux/hid.h | 1 +
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 7b88f4c..d8b6976 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
struct usbhid_device *usbhid = hid->driver_data;
spin_lock_irqsave(&usbhid->lock, flags);
- if (hid->open > 0 &&
+ if ((hid->open > 0 || hid->quirks & HID_QUIRK_ALWAYS_POLL) &&
!test_bit(HID_DISCONNECTED, &usbhid->iofl) &&
!test_bit(HID_SUSPENDED, &usbhid->iofl) &&
!test_and_set_bit(HID_IN_RUNNING, &usbhid->iofl)) {
@@ -292,6 +292,8 @@ static void hid_irq_in(struct urb *urb)
case 0: /* success */
usbhid_mark_busy(usbhid);
usbhid->retry_delay = 0;
+ if ((hid->quirks & HID_QUIRK_ALWAYS_POLL) && !hid->open)
+ break;
hid_input_report(urb->context, HID_INPUT_REPORT,
urb->transfer_buffer,
urb->actual_length, 1);
@@ -734,8 +736,10 @@ void usbhid_close(struct hid_device *hid)
if (!--hid->open) {
spin_unlock_irq(&usbhid->lock);
hid_cancel_delayed_stuff(usbhid);
- usb_kill_urb(usbhid->urbin);
- usbhid->intf->needs_remote_wakeup = 0;
+ if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL)) {
+ usb_kill_urb(usbhid->urbin);
+ usbhid->intf->needs_remote_wakeup = 0;
+ }
} else {
spin_unlock_irq(&usbhid->lock);
}
@@ -1133,6 +1137,19 @@ static int usbhid_start(struct hid_device *hid)
set_bit(HID_STARTED, &usbhid->iofl);
+ if (hid->quirks & HID_QUIRK_ALWAYS_POLL) {
+ ret = usb_autopm_get_interface(usbhid->intf);
+ if (ret)
+ goto fail;
+ usbhid->intf->needs_remote_wakeup = 1;
+ ret = hid_start_in(hid);
+ if (ret) {
+ dev_err(&hid->dev,
+ "failed to start in urb: %d\n", ret);
+ }
+ usb_autopm_put_interface(usbhid->intf);
+ }
+
/* Some keyboards don't work until their LEDs have been set.
* Since BIOSes do set the LEDs, it must be safe for any device
* that supports the keyboard boot protocol.
@@ -1165,6 +1182,9 @@ static void usbhid_stop(struct hid_device *hid)
if (WARN_ON(!usbhid))
return;
+ if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
+ usbhid->intf->needs_remote_wakeup = 0;
+
clear_bit(HID_STARTED, &usbhid->iofl);
spin_lock_irq(&usbhid->lock); /* Sync with error and led handlers */
set_bit(HID_DISCONNECTED, &usbhid->iofl);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 77632cf..05eb710 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -286,6 +286,7 @@ struct hid_item {
#define HID_QUIRK_HIDINPUT_FORCE 0x00000080
#define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
#define HID_QUIRK_NO_INIT_INPUT_REPORTS 0x00000200
+#define HID_QUIRK_ALWAYS_POLL 0x00000400
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
#define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x00020000
#define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x00040000
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/2] HID: usbhid: fix Elan touchscreen disconnects
From: Johan Hovold @ 2014-09-05 16:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: Greg KH, Alan Stern, Bjørn Mork, Sarah Sharp,
Drew Von Spreecken, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum, Johan Hovold
In-Reply-To: <alpine.LNX.2.00.1408211337050.23162-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
Here's the always-poll quirk that is needed to prevent the Elan
touchscreen from disconnecting itself from the bus.
These patches are against v3.16.1, but applies fine to hid-next.
Note that this series is not dependent on the device-qualifier quirk
[1], which is needed to get the same device to enumerate reliably, so
these two quirks could in through the USB and HID tree, respectively.
Johan
[1] http://marc.info/?l=linux-usb&m=140898201107571&w=2
Johan Hovold (2):
HID: usbhid: add always-poll quirk
HID: usbhid: enable always-poll quirk for Elan Touchscreen
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-core.c | 26 +++++++++++++++++++++++---
drivers/hid/usbhid/hid-quirks.c | 1 +
include/linux/hid.h | 1 +
4 files changed, 28 insertions(+), 3 deletions(-)
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] HID: rmi: check sanity of the incoming report
From: Benjamin Tissoires @ 2014-09-05 13:57 UTC (permalink / raw)
To: Jiri Kosina, Andrew Duggan; +Cc: linux-input, linux-kernel
In the Dell XPS 13 9333, it appears that sometimes the bus get confused
and corrupts the incoming data. It fills the input report with the
sentinel value "ff". Synaptics told us that such behavior does not comes
from the touchpad itself, so we filter out such reports here.
Unfortunately, we can not simply discard the incoming data because they
may contain useful information. Most of the time, the misbehavior is
quite near the end of the report, so we can still use the valid part of
it.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1123584
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-rmi.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 8389e81..db92c3b 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -320,9 +320,6 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 irq, u8 *data,
int offset;
int i;
- if (size < hdata->f11.report_size)
- return 0;
-
if (!(irq & hdata->f11.irq_mask))
return 0;
@@ -332,9 +329,13 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 irq, u8 *data,
int fs_bit_position = (i & 0x3) << 1;
int finger_state = (data[fs_byte_position] >> fs_bit_position) &
0x03;
+ int position = offset + 5 * i;
+
+ if (position + 5 > size)
+ /* partial report, go on with what we received */
+ break;
- rmi_f11_process_touch(hdata, i, finger_state,
- &data[offset + 5 * i]);
+ rmi_f11_process_touch(hdata, i, finger_state, &data[position]);
}
input_mt_sync_frame(hdata->input);
input_sync(hdata->input);
@@ -412,9 +413,29 @@ static int rmi_read_data_event(struct hid_device *hdev, u8 *data, int size)
return 1;
}
+static int rmi_check_sanity(struct hid_device *hdev, u8 *data, int size)
+{
+ int valid_size = size;
+ /*
+ * On the Dell XPS 13 9333, the bus sometimes get confused and fills
+ * the report with a sentinel value "ff". Synaptics told us that such
+ * behavior does not comes from the touchpad itself, so we filter out
+ * such reports here.
+ */
+
+ while ((data[valid_size - 1] == 0xff) && valid_size > 0)
+ valid_size--;
+
+ return valid_size;
+}
+
static int rmi_raw_event(struct hid_device *hdev,
struct hid_report *report, u8 *data, int size)
{
+ size = rmi_check_sanity(hdev, data, size);
+ if (size < 2)
+ return 0;
+
switch (data[0]) {
case RMI_READ_DATA_REPORT_ID:
return rmi_read_data_event(hdev, data, size);
--
2.1.0
^ permalink raw reply related
* [PATCH] Input: serport: Add compat_ioctl routine to support 32bit inputtattach in 64bit systems
From: John Sung @ 2014-09-05 13:04 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: penmount.touch
When running a 32-bit inputattach utility in a 64-bit system, there will be error code "inputattach: can't set device type". This is caused by the serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl fails.
Signed-off-by: John Sung <penmount.touch@gmail.com>
---
drivers/input/serio/serport.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index 0cb7ef5..4b68c29 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -22,6 +22,8 @@
#include <linux/serio.h>
#include <linux/tty.h>
+#include <asm/compat.h>
+
MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
MODULE_DESCRIPTION("Input device TTY line discipline");
MODULE_LICENSE("GPL");
@@ -31,6 +33,8 @@ MODULE_ALIAS_LDISC(N_MOUSE);
#define SERPORT_ACTIVE 2
#define SERPORT_DEAD 3
+#define SPIOCSTYPE32 (_IOW('q', 0x01, compat_ulong_t))
+
struct serport {
struct tty_struct *tty;
wait_queue_head_t wait;
@@ -221,6 +225,25 @@ static int serport_ldisc_ioctl(struct tty_struct * tty, struct file * file, unsi
return -EINVAL;
}
+static long serport_ldisc_compat_ioctl(struct tty_struct *tty, struct file *file, unsigned int cmd, unsigned long arg)
+{
+ struct serport *serport = (struct serport*) tty->disc_data;
+ unsigned long type;
+
+ if (cmd == SPIOCSTYPE32) {
+ if (get_user(type, (unsigned long __user *) arg))
+ return -EFAULT;
+
+ serport->id.proto = type & 0x000000ff;
+ serport->id.id = (type & 0x0000ff00) >> 8;
+ serport->id.extra = (type & 0x00ff0000) >> 16;
+
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static void serport_ldisc_write_wakeup(struct tty_struct * tty)
{
struct serport *serport = (struct serport *) tty->disc_data;
@@ -243,6 +266,7 @@ static struct tty_ldisc_ops serport_ldisc = {
.close = serport_ldisc_close,
.read = serport_ldisc_read,
.ioctl = serport_ldisc_ioctl,
+ .compat_ioctl = serport_ldisc_compat_ioctl,
.receive_buf = serport_ldisc_receive,
.write_wakeup = serport_ldisc_write_wakeup
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/4] mfd: max77693: Initialize haptic register map
From: Jaewon Kim @ 2014-09-05 11:48 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Ortiz, Lee Jones
Cc: linux-kernel, linux-input, Chanwoo Choi, Jaewon Kim
In-Reply-To: <1409917702-17009-1-git-send-email-jaewon02.kim@samsung.com>
This patch add regmap_haptic initialization to use haptic register map
in haptic device driver.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/max77693.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 249c139..fbfed56 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -144,6 +144,12 @@ static const struct regmap_irq_chip max77693_muic_irq_chip = {
.num_irqs = ARRAY_SIZE(max77693_muic_irqs),
};
+static const struct regmap_config max77693_regmap_haptic_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = MAX77693_HAPTIC_REG_END,
+};
+
static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -193,6 +199,15 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
}
i2c_set_clientdata(max77693->haptic, max77693);
+ max77693->regmap_haptic = devm_regmap_init_i2c(max77693->haptic,
+ &max77693_regmap_haptic_config);
+ if (IS_ERR(max77693->regmap_haptic)) {
+ ret = PTR_ERR(max77693->regmap_haptic);
+ dev_err(max77693->dev,
+ "failed to initialize haptic register map: %d\n", ret);
+ goto err_regmap;
+ }
+
/*
* Initialize register map for MUIC device because use regmap-muic
* instance of MUIC device when irq of max77693 is initialized
@@ -204,7 +219,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
ret = PTR_ERR(max77693->regmap_muic);
dev_err(max77693->dev,
"failed to allocate register map: %d\n", ret);
- goto err_regmap_muic;
+ goto err_regmap;
}
ret = regmap_add_irq_chip(max77693->regmap, max77693->irq,
@@ -214,7 +229,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
&max77693->irq_data_led);
if (ret) {
dev_err(max77693->dev, "failed to add irq chip: %d\n", ret);
- goto err_regmap_muic;
+ goto err_regmap;
}
ret = regmap_add_irq_chip(max77693->regmap, max77693->irq,
@@ -265,7 +280,7 @@ err_irq_charger:
regmap_del_irq_chip(max77693->irq, max77693->irq_data_topsys);
err_irq_topsys:
regmap_del_irq_chip(max77693->irq, max77693->irq_data_led);
-err_regmap_muic:
+err_regmap:
i2c_unregister_device(max77693->haptic);
err_i2c_haptic:
i2c_unregister_device(max77693->muic);
--
1.7.9.5
^ permalink raw reply related
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