Re: [PATCH v3] Fix modifier keys for Redragon Asura Keyboard

Hi Robert, First, apologies for not answering to the RFC. I missed it and it fell down in my INBOX. On Wed, Mar 21, 2018 at 11:43 AM, Robert Munteanu wrote: > The microdia family of keyboards uses a non-standard way of sending > modifier keys. > > The down event always sets

Re: [PATCH v3] Fix modifier keys for Redragon Asura Keyboard

Hi Robert, First, apologies for not answering to the RFC. I missed it and it fell down in my INBOX. On Wed, Mar 21, 2018 at 11:43 AM, Robert Munteanu wrote: > The microdia family of keyboards uses a non-standard way of sending > modifier keys. > > The down event always sets the first bit to

Re: [PATCH v5 0/4] new driver for Valve Steam Controller

Hi Rodrigo, On Mon, Mar 19, 2018 at 9:08 PM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Sat, Mar 17, 2018 at 02:54:07PM -0700, Pierre-Loup A. Griffais wrote: >> >> >> On 03/15/2018 02:06 PM, Rodrigo Rivas Costa wrote: >> > On Wed, Mar 14

Re: [PATCH v5 0/4] new driver for Valve Steam Controller

Hi Rodrigo, On Mon, Mar 19, 2018 at 9:08 PM, Rodrigo Rivas Costa wrote: > On Sat, Mar 17, 2018 at 02:54:07PM -0700, Pierre-Loup A. Griffais wrote: >> >> >> On 03/15/2018 02:06 PM, Rodrigo Rivas Costa wrote: >> > On Wed, Mar 14, 2018 at 05:39:25PM +0100, Benjamin

[PATCH 0/7] HID core and multitouch fixups

that other drivers could reuse the hid-mt logic (but it's not that easy I must confess). Cheers, Benjamin Benjamin Tissoires (7): HID: multitouch: export a quirk for the button handling of touchpads HID: multitouch: remove dead zones of Razer Blade Stealth HID: use BIT macro instead

[PATCH 1/7] HID: multitouch: export a quirk for the button handling of touchpads

Instead of using the class name, we better have a specific quirk for it so other classes can make use of it. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/hid/hid-multitouch.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-)

[PATCH 0/7] HID core and multitouch fixups

that other drivers could reuse the hid-mt logic (but it's not that easy I must confess). Cheers, Benjamin Benjamin Tissoires (7): HID: multitouch: export a quirk for the button handling of touchpads HID: multitouch: remove dead zones of Razer Blade Stealth HID: use BIT macro instead

[PATCH 1/7] HID: multitouch: export a quirk for the button handling of touchpads

Instead of using the class name, we better have a specific quirk for it so other classes can make use of it. Signed-off-by: Benjamin Tissoires --- drivers/hid/hid-multitouch.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/hid/hid

[PATCH 4/7] HID: use BIT() macro for quirks too

This should prevent future mess ups fortunately. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> -- include/linux/hid.h | 52 ++-- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/include/linux/hid.h b/i

[PATCH 4/7] HID: use BIT() macro for quirks too

This should prevent future mess ups fortunately. Signed-off-by: Benjamin Tissoires -- include/linux/hid.h | 52 ++-- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/include/linux/hid.h b/include/linux/hid.h index ea78336984d3

[PATCH 7/7] HID: core: reset the quirks before calling probe again

Given that now the quirk handling is done in hid-quirk.c, we can actually reset the quirks before calling .probe(), so that the drivers do not need to keep track of initial quirks. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/hid/hid-core.c | 2 ++ d

[PATCH 7/7] HID: core: reset the quirks before calling probe again

Given that now the quirk handling is done in hid-quirk.c, we can actually reset the quirks before calling .probe(), so that the drivers do not need to keep track of initial quirks. Signed-off-by: Benjamin Tissoires --- drivers/hid/hid-core.c | 2 ++ drivers/hid/hid-multitouch.c | 7

[PATCH 2/7] HID: multitouch: remove dead zones of Razer Blade Stealth

tection up to the upper stack Link: https://bugs.freedesktop.org/show_bug.cgi?id=105409 Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/hid/hid-multitouch.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/hid/hid-multitouch.c b

[PATCH 2/7] HID: multitouch: remove dead zones of Razer Blade Stealth

tection up to the upper stack Link: https://bugs.freedesktop.org/show_bug.cgi?id=105409 Signed-off-by: Benjamin Tissoires --- drivers/hid/hid-multitouch.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index fc

[PATCH 3/7] HID: use BIT macro instead of plain integers for flags

This can lead to some hairy situation with the developer losing a day or two realizing that 4 should be after 2, not 3. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Reviewed-by: Dmitry Torokhov <dmitry.torok...@gmail.com> -- include/linux/hid.h | 13 +++--

[PATCH 3/7] HID: use BIT macro instead of plain integers for flags

This can lead to some hairy situation with the developer losing a day or two realizing that 4 should be after 2, not 3. Signed-off-by: Benjamin Tissoires Reviewed-by: Dmitry Torokhov -- include/linux/hid.h | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git

[PATCH 5/7] HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT

There is no real point of registering an empty input node. This should be default, but given some drivers need the blank input node to set it up during input_configured, we need to postpone the check for hidinput_has_been_populated(). Signed-off-by: Benjamin Tissoires <benjamin.tis

[PATCH 5/7] HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT

There is no real point of registering an empty input node. This should be default, but given some drivers need the blank input node to set it up during input_configured, we need to postpone the check for hidinput_has_been_populated(). Signed-off-by: Benjamin Tissoires --- drivers/hid/hid-asus.c

[PATCH 6/7] HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS

It is set by default now, so there is no point setting it in the driver Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/hid/hid-multitouch.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/drivers/hid/hid-multitouch.c b/d

[PATCH 6/7] HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS

It is set by default now, so there is no point setting it in the driver Signed-off-by: Benjamin Tissoires --- drivers/hid/hid-multitouch.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index

Re: [PATCH v5 0/4] new driver for Valve Steam Controller

On Mon, Mar 12, 2018 at 9:51 PM, Rodrigo Rivas Costa wrote: > On Mon, Mar 12, 2018 at 03:30:43PM +0100, Clément VUCHENER wrote: >> 2018-03-11 20:58 GMT+01:00 Rodrigo Rivas Costa : >> > This patchset implements a driver for Valve Steam

Re: [PATCH v5 0/4] new driver for Valve Steam Controller

On Mon, Mar 12, 2018 at 9:51 PM, Rodrigo Rivas Costa wrote: > On Mon, Mar 12, 2018 at 03:30:43PM +0100, Clément VUCHENER wrote: >> 2018-03-11 20:58 GMT+01:00 Rodrigo Rivas Costa : >> > This patchset implements a driver for Valve Steam Controller, based on a >> > reverse analysis by myself. >> >

Re: [PATCH v4] HID: google: add google hammer HID driver

Hi Nicolas, On Wed, Mar 14, 2018 at 6:22 AM, Nicolas Boichat wrote: > From: Wei-Ning Huang > > Add Google hammer HID driver. This driver allow us to control hammer > keyboard backlight and support future features. > > We add a new HID quirk, that

Re: [PATCH v4] HID: google: add google hammer HID driver

Hi Nicolas, On Wed, Mar 14, 2018 at 6:22 AM, Nicolas Boichat wrote: > From: Wei-Ning Huang > > Add Google hammer HID driver. This driver allow us to control hammer > keyboard backlight and support future features. > > We add a new HID quirk, that allows us to have the keyboard interface > to

Re: [PATCH 1/1] HID: core: rewrite the hid-generic automatic unbind

Hi Jiri, On Fri, Dec 8, 2017 at 3:29 PM, Benjamin Tissoires <benjamin.tissoi...@redhat.com> wrote: > We actually can have the unbind/rebind logic in hid-core.c, leaving > only the match function in hid-generic. > This makes hid-generic simpler and the whole logic simpler too.

Re: [PATCH 1/1] HID: core: rewrite the hid-generic automatic unbind

Hi Jiri, On Fri, Dec 8, 2017 at 3:29 PM, Benjamin Tissoires wrote: > We actually can have the unbind/rebind logic in hid-core.c, leaving > only the match function in hid-generic. > This makes hid-generic simpler and the whole logic simpler too. > > Signed-off-by: Benjamin Tissoire

Re: [PATCH v2 1/1] HID: Logitech K290: Add driver for the Logitech K290 USB keyboard

Hi Florent, On Mon, Mar 5, 2018 at 10:31 AM, Nestor Lopez Casado wrote: > Hello Florent, > > In my view, this driver may not be a good idea. The default behaviour > of K290 is 'send multimedia keycodes' with the user given the choice > to change that behaviour via

Re: [PATCH v2 1/1] HID: Logitech K290: Add driver for the Logitech K290 USB keyboard

Hi Florent, On Mon, Mar 5, 2018 at 10:31 AM, Nestor Lopez Casado wrote: > Hello Florent, > > In my view, this driver may not be a good idea. The default behaviour > of K290 is 'send multimedia keycodes' with the user given the choice > to change that behaviour via vendor commands. Putting a

Re: [PATCH v3 0/3] new driver for Valve Steam Controller

Hi Rodrigo, On Sun, Feb 25, 2018 at 7:52 PM, Rodrigo Rivas Costa wrote: > This patchset implements a driver for Valve Steam Controller, based on a > reverse analysis by myself. To me, the code looks OK now. I haven't got the time to do a better review, so giving my:

Re: [PATCH v3 0/3] new driver for Valve Steam Controller

Hi Rodrigo, On Sun, Feb 25, 2018 at 7:52 PM, Rodrigo Rivas Costa wrote: > This patchset implements a driver for Valve Steam Controller, based on a > reverse analysis by myself. To me, the code looks OK now. I haven't got the time to do a better review, so giving my: Acked-by: Bnejamin Tissoires

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

On Thu, Feb 22, 2018 at 6:48 PM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Thu, Feb 22, 2018 at 06:06:30PM +0100, Benjamin Tissoires wrote: >> On Thu, Feb 22, 2018 at 5:31 PM, Rodrigo Rivas Costa >> <rodrigorivasco...@gmail.com> wrote: >> >

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

On Thu, Feb 22, 2018 at 6:48 PM, Rodrigo Rivas Costa wrote: > On Thu, Feb 22, 2018 at 06:06:30PM +0100, Benjamin Tissoires wrote: >> On Thu, Feb 22, 2018 at 5:31 PM, Rodrigo Rivas Costa >> wrote: >> > On Thu, Feb 22, 2018 at 10:10:40AM +0100, Benjamin Tissoires wrote: &g

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

On Thu, Feb 22, 2018 at 5:31 PM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Thu, Feb 22, 2018 at 10:10:40AM +0100, Benjamin Tissoires wrote: >> On Thu, Feb 22, 2018 at 1:13 AM, Pierre-Loup A. Griffais >> <pgriff...@valvesoftware.com> wrote: >> &

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

On Thu, Feb 22, 2018 at 5:31 PM, Rodrigo Rivas Costa wrote: > On Thu, Feb 22, 2018 at 10:10:40AM +0100, Benjamin Tissoires wrote: >> On Thu, Feb 22, 2018 at 1:13 AM, Pierre-Loup A. Griffais >> wrote: >> > >> > >> > On 02/21/2018 12:21 PM, Rodrigo Riv

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

>>> would still get keyboard/mouse input over these USB endpoints while >>> trying >>> to interact with the controller. But sending this after Steam programmed >>> a >>> setting, or instructed the controller to go back to lizard mode be

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

keyboard/mouse input over these USB endpoints while >>> trying >>> to interact with the controller. But sending this after Steam programmed >>> a >>> setting, or instructed the controller to go back to lizard mode because >>> it >>> was

Re: [PATCH v2 1/3] HID: add driver for Valve Steam Controller

On Tue, Feb 20, 2018 at 8:33 PM, Rodrigo Rivas Costa wrote: > There are two ways to connect the Steam Controller: directly to the USB > or with the USB wireless adapter. Both methods are similar, but the > wireless adapter can connect up to 4 devices at the same

Re: [PATCH v2 1/3] HID: add driver for Valve Steam Controller

On Tue, Feb 20, 2018 at 8:33 PM, Rodrigo Rivas Costa wrote: > There are two ways to connect the Steam Controller: directly to the USB > or with the USB wireless adapter. Both methods are similar, but the > wireless adapter can connect up to 4 devices at the same time. > > The wired device will

Re: [PATCH 2/3] HID: steam: add serial number information.

On Fri, Feb 16, 2018 at 9:59 PM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Fri, Feb 16, 2018 at 11:38:11AM +0100, Benjamin Tissoires wrote: >> On Fri, Feb 16, 2018 at 10:57 AM, Rodrigo Rivas Costa >> <rodrigorivasco...@gmail.com> wrote: >> >

Re: [PATCH 2/3] HID: steam: add serial number information.

On Fri, Feb 16, 2018 at 9:59 PM, Rodrigo Rivas Costa wrote: > On Fri, Feb 16, 2018 at 11:38:11AM +0100, Benjamin Tissoires wrote: >> On Fri, Feb 16, 2018 at 10:57 AM, Rodrigo Rivas Costa >> wrote: >> > On Fri, Feb 16, 2018 at 10:31:35AM +0100, Benjamin Tissoires wr

Re: [PATCH 2/3] HID: steam: add serial number information.

On Fri, Feb 16, 2018 at 10:57 AM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Fri, Feb 16, 2018 at 10:31:35AM +0100, Benjamin Tissoires wrote: >> > Ok, I'll do that. The weird thing, however, is that: >> > >> > hid

Re: [PATCH 2/3] HID: steam: add serial number information.

On Fri, Feb 16, 2018 at 10:57 AM, Rodrigo Rivas Costa wrote: > On Fri, Feb 16, 2018 at 10:31:35AM +0100, Benjamin Tissoires wrote: >> > Ok, I'll do that. The weird thing, however, is that: >> > >> > hid_hw_raw_request(steam->hid_dev, 0x00, >>

Re: [PATCH 2/3] HID: steam: add serial number information.

On Fri, Feb 16, 2018 at 10:02 AM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Fri, Feb 16, 2018 at 09:44:34AM +0100, Benjamin Tissoires wrote: >> > I have an issue with this one. The problem is that using >> > hid_report_len() on the feature report

Re: [PATCH 2/3] HID: steam: add serial number information.

On Fri, Feb 16, 2018 at 10:02 AM, Rodrigo Rivas Costa wrote: > On Fri, Feb 16, 2018 at 09:44:34AM +0100, Benjamin Tissoires wrote: >> > I have an issue with this one. The problem is that using >> > hid_report_len() on the feature report returns 64. But I must call &g

Re: [PATCH 2/3] HID: steam: add serial number information.

On Thu, Feb 15, 2018 at 11:16 PM, Rodrigo Rivas Costa <rodrigorivasco...@gmail.com> wrote: > On Wed, Feb 14, 2018 at 03:51:31PM +0100, Benjamin Tissoires wrote: >> On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa >> > +#define STEAM_FEATURE_REPORT_SIZE 65

Re: [PATCH 2/3] HID: steam: add serial number information.

On Thu, Feb 15, 2018 at 11:16 PM, Rodrigo Rivas Costa wrote: > On Wed, Feb 14, 2018 at 03:51:31PM +0100, Benjamin Tissoires wrote: >> On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa >> > +#define STEAM_FEATURE_REPORT_SIZE 65 >> > + >> > +static int s

Re: [PATCH 3/3] HID: steam: add battery device.

On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa wrote: > The wireless Steam Controller is battery operated, so add the battery > device and power information. > > Signed-off-by: Rodrigo Rivas Costa > --- > drivers/hid/hid-steam.c |

Re: [PATCH 3/3] HID: steam: add battery device.

On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa wrote: > The wireless Steam Controller is battery operated, so add the battery > device and power information. > > Signed-off-by: Rodrigo Rivas Costa > --- > drivers/hid/hid-steam.c | 139 > +++- >

Re: [PATCH 2/3] HID: steam: add serial number information.

On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa wrote: > This device has a feature report to send and receive commands. > Use it to get the serial number and set the device's uniq value. > > Signed-off-by: Rodrigo Rivas Costa > --- >

Re: [PATCH 2/3] HID: steam: add serial number information.

On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa wrote: > This device has a feature report to send and receive commands. > Use it to get the serial number and set the device's uniq value. > > Signed-off-by: Rodrigo Rivas Costa > --- > drivers/hid/hid-steam.c | 89 >

Re: [PATCH 1/3] HID: add driver for Valve Steam Controller

Hi Rodrigo, On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa wrote: > There are two ways to connect the Steam Controller: directly to the USB > or with the USB wireless adapter. Both methods are similar, but the > wireless adapter can connect up to 4 devices at

Re: [PATCH 1/3] HID: add driver for Valve Steam Controller

Hi Rodrigo, On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa wrote: > There are two ways to connect the Steam Controller: directly to the USB > or with the USB wireless adapter. Both methods are similar, but the > wireless adapter can connect up to 4 devices at the same time. > > The wired

Re: [PATCH 1/2] HID: core: i2c-hid: fix size check and type usage

Hi Aaron, There are quite some changes I'd like to see in this patch. See below. On Tue, Jan 2, 2018 at 6:30 PM, Aaron Ma wrote: > When convert char array with signed int, if the inbuf[x] is negative then > upper bits will be set to 1. Fix this by using u8 instead of

Re: [PATCH 1/2] HID: core: i2c-hid: fix size check and type usage

Hi Aaron, There are quite some changes I'd like to see in this patch. See below. On Tue, Jan 2, 2018 at 6:30 PM, Aaron Ma wrote: > When convert char array with signed int, if the inbuf[x] is negative then > upper bits will be set to 1. Fix this by using u8 instead of char. > > ret_size has to

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

Hi Aaron, On Tue, Jan 2, 2018 at 6:30 PM, Aaron Ma wrote: > When Rayd touchscreen resumed from S3, it issues too many errors like: > i2c_hid i2c-RAYD0001:00: i2c_hid_get_input: incomplete report (58/5442) > > And all the report data are corrupted, touchscreen is

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

Hi Aaron, On Tue, Jan 2, 2018 at 6:30 PM, Aaron Ma wrote: > When Rayd touchscreen resumed from S3, it issues too many errors like: > i2c_hid i2c-RAYD0001:00: i2c_hid_get_input: incomplete report (58/5442) > > And all the report data are corrupted, touchscreen is unresponsive. > > Fix this by

Re: [PATCH 2/2] input - leds: fix input_led_disconnect path

On Wed, Dec 20, 2017 at 7:20 PM, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > On Wed, Dec 20, 2017 at 9:11 AM, Benjamin Tissoires > <benjamin.tissoi...@redhat.com> wrote: >> On Sat, Dec 16, 2017 at 1:48 AM, Dmitry Torokhov >> <dmitry.torok...@

Re: [PATCH 2/2] input - leds: fix input_led_disconnect path

On Wed, Dec 20, 2017 at 7:20 PM, Dmitry Torokhov wrote: > On Wed, Dec 20, 2017 at 9:11 AM, Benjamin Tissoires > wrote: >> On Sat, Dec 16, 2017 at 1:48 AM, Dmitry Torokhov >> wrote: >>> Hi Benjamin, >>> >>> On Thu, Dec 14, 2017 at 02:25:22PM

Re: [PATCH 2/2] input - leds: fix input_led_disconnect path

On Sat, Dec 16, 2017 at 1:48 AM, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > Hi Benjamin, > > On Thu, Dec 14, 2017 at 02:25:22PM +0100, Benjamin Tissoires wrote: >> Before unregistering the led classes, we have to be sure there is no >> more events in the

Re: [PATCH 2/2] input - leds: fix input_led_disconnect path

On Sat, Dec 16, 2017 at 1:48 AM, Dmitry Torokhov wrote: > Hi Benjamin, > > On Thu, Dec 14, 2017 at 02:25:22PM +0100, Benjamin Tissoires wrote: >> Before unregistering the led classes, we have to be sure there is no >> more events in the input pipeline. >> Closing the

Re: [PATCH 0/2] input - leds: fix bugs found by fuzzing

On Fri, Dec 15, 2017 at 1:16 AM, Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote: > Hello, > > Benjamin Tissoires, on jeu. 14 déc. 2017 14:25:20 +0100, wrote: >> I marked them as stable as I believe eventhough not many >> people discovered those and reported

Re: [PATCH 0/2] input - leds: fix bugs found by fuzzing

On Fri, Dec 15, 2017 at 1:16 AM, Samuel Thibault wrote: > Hello, > > Benjamin Tissoires, on jeu. 14 déc. 2017 14:25:20 +0100, wrote: >> I marked them as stable as I believe eventhough not many >> people discovered those and reported them, they should >> still be fixed i

[PATCH 2/2] input - leds: fix input_led_disconnect path

/show_bug.cgi?id=197679 Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/input/input-leds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c index c86eb3d648bf..8aefcc

[PATCH 0/2] input - leds: fix bugs found by fuzzing

or RF_KILL seem to manage to mess up my network driver. Cheers, Benjamin [1] https://github.com/whot/fuzzydevice Benjamin Tissoires (2): input - leds: do not iterate over non initialized leds input - leds: fix input_led_disconnect path drivers/input/input-leds.c | 5 - 1 file changed, 4

[PATCH 2/2] input - leds: fix input_led_disconnect path

/show_bug.cgi?id=197679 Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires --- drivers/input/input-leds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c index c86eb3d648bf..8aefcc186a02 100644 --- a/drivers/input/input

[PATCH 0/2] input - leds: fix bugs found by fuzzing

or RF_KILL seem to manage to mess up my network driver. Cheers, Benjamin [1] https://github.com/whot/fuzzydevice Benjamin Tissoires (2): input - leds: do not iterate over non initialized leds input - leds: fix input_led_disconnect path drivers/input/input-leds.c | 5 - 1 file changed, 4

[PATCH 1/2] input - leds: do not iterate over non initialized leds

oopses. Found by running https://github.com/whot/fuzzydevice Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/input/input-leds.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/input/input-leds.c b/drivers/input/input-

[PATCH 1/2] input - leds: do not iterate over non initialized leds

oopses. Found by running https://github.com/whot/fuzzydevice Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires --- drivers/input/input-leds.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c index 83d930f7396a..c86eb3d648bf

[PATCH 1/1] HID: core: rewrite the hid-generic automatic unbind

We actually can have the unbind/rebind logic in hid-core.c, leaving only the match function in hid-generic. This makes hid-generic simpler and the whole logic simpler too. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- Hi Jiri, while trying to find out a local

[PATCH 1/1] HID: core: rewrite the hid-generic automatic unbind

We actually can have the unbind/rebind logic in hid-core.c, leaving only the match function in hid-generic. This makes hid-generic simpler and the whole logic simpler too. Signed-off-by: Benjamin Tissoires --- Hi Jiri, while trying to find out a local bug, I figured out we don't really need

[PATCH v2 1/2] HID: use BIT macro instead of plain integers for flags

This can lead to some hairy situation with the developer losing a day or two realizing that 4 should be after 2, not 3. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- new in v2 include/linux/hid.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)

[PATCH v2 1/2] HID: use BIT macro instead of plain integers for flags

This can lead to some hairy situation with the developer losing a day or two realizing that 4 should be after 2, not 3. Signed-off-by: Benjamin Tissoires --- new in v2 include/linux/hid.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/linux/hid.h b

[PATCH v2 2/2] HID: input: do not increment usages when a duplicate is found

compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE is created and can be applied to any device that needs this behavior. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v2: - fixed a bug where the flag was not used properly and prevented to remove

[PATCH v2 0/2] HID: input: do not increment usages when a duplicate is found

Hi Jiri, slightly modified version (to actually make it working this time). There is not much to add, the differences are in the commit messages and in the notes of each patch. Cheers, Benjamin Benjamin Tissoires (2): HID: use BIT macro instead of plain integers for flags HID: input: do

[PATCH v2 2/2] HID: input: do not increment usages when a duplicate is found

compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE is created and can be applied to any device that needs this behavior. Signed-off-by: Benjamin Tissoires --- changes in v2: - fixed a bug where the flag was not used properly and prevented to remove devices - downgrade the error mess

[PATCH v2 0/2] HID: input: do not increment usages when a duplicate is found

Hi Jiri, slightly modified version (to actually make it working this time). There is not much to add, the differences are in the commit messages and in the notes of each patch. Cheers, Benjamin Benjamin Tissoires (2): HID: use BIT macro instead of plain integers for flags HID: input: do

Re: [PATCH 08/45] drivers: input: remove duplicate includes

t; > Signed-off-by: Pravin Shedge <pravin.shedge4li...@gmail.com> > --- Acked-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Cheers, Benjamin > drivers/input/rmi4/rmi_f34.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/input/rmi4/rmi_f34.c b

Re: [PATCH 08/45] drivers: input: remove duplicate includes

> --- Acked-by: Benjamin Tissoires Cheers, Benjamin > drivers/input/rmi4/rmi_f34.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/input/rmi4/rmi_f34.c b/drivers/input/rmi4/rmi_f34.c > index 4cfe970..f1f5ac5 100644 > --- a/drivers/input/rmi4/rmi_f34.c >

Re: [PATCH][next] HID: quirks: make array hid_quirks static

t; drivers/hid/hid-quirks.c:29:28: warning: symbol 'hid_quirks' was not > declared. Should it be static? > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> > --- Sounds good. Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Cheers, Benjamin > dr

Re: [PATCH][next] HID: quirks: make array hid_quirks static

s' was not > declared. Should it be static? > > Signed-off-by: Colin Ian King > --- Sounds good. Reviewed-by: Benjamin Tissoires Cheers, Benjamin > drivers/hid/hid-quirks.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hid/hid-quirks.c b/

Re: [PATCH v2] HID: add quirk for another PIXART OEM mouse used by HP

946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse > [PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0 > > Signed-off-by: Dave Young <dyo...@redhat.com> > Cc: sta...@vger.kernel.org > --- Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@

Re: [PATCH v2] HID: add quirk for another PIXART OEM mouse used by HP

F0:094A.0003: input: USB HID v1.11 Mouse > [PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0 > > Signed-off-by: Dave Young > Cc: sta...@vger.kernel.org > --- Reviewed-by: Benjamin Tissoires > v1->v2: rebase to usb tree hid-quirks-cleanup branch > drivers

Re: [PATCH] HID: input: do not increment usages when a duplicate is found

On Nov 23 2017 or thereabouts, Benjamin Tissoires wrote: > This is something that bothered us from a long time. When hid-input > doesn't know how to map a usage, it uses *_MISC. But there is something > else which increments the usage if the evdev code is already used. > > Th

Re: [PATCH] HID: input: do not increment usages when a duplicate is found

On Nov 23 2017 or thereabouts, Benjamin Tissoires wrote: > This is something that bothered us from a long time. When hid-input > doesn't know how to map a usage, it uses *_MISC. But there is something > else which increments the usage if the evdev code is already used. > > Th

Re: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

On Nov 24 2017 or thereabouts, Zheng, Lv wrote: > Hi, Rui > > > From: Zhang, Rui > > Subject: RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue > > by moving EC event handling > > earlier > > > > > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > > > Subject:

Re: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

On Nov 24 2017 or thereabouts, Zheng, Lv wrote: > Hi, Rui > > > From: Zhang, Rui > > Subject: RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue > > by moving EC event handling > > earlier > > > > > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > > > Subject:

Re: [PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP

On Nov 27 2017 or thereabouts, Greg KH wrote: > On Mon, Nov 27, 2017 at 09:16:31AM +0100, Benjamin Tissoires wrote: > > On Nov 25 2017 or thereabouts, Dave Young wrote: > > > This mouse keep disconnecting in runleve 3 like below, add it needs the > > > quirk t

Re: [PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP

On Nov 27 2017 or thereabouts, Greg KH wrote: > On Mon, Nov 27, 2017 at 09:16:31AM +0100, Benjamin Tissoires wrote: > > On Nov 25 2017 or thereabouts, Dave Young wrote: > > > This mouse keep disconnecting in runleve 3 like below, add it needs the > > > quirk t

Re: [PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP

On Nov 25 2017 or thereabouts, Dave Young wrote: > This mouse keep disconnecting in runleve 3 like below, add it needs the > quirk to mute the anoying messages. > > [ 111.230555] usb 2-2: USB disconnect, device number 6 > [ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd >

Re: [PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP

On Nov 25 2017 or thereabouts, Dave Young wrote: > This mouse keep disconnecting in runleve 3 like below, add it needs the > quirk to mute the anoying messages. > > [ 111.230555] usb 2-2: USB disconnect, device number 6 > [ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd >

[PATCH] HID: input: do not increment usages when a duplicate is found

compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE is created and can be applied to any device that needs this behavior. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- Hi Jiri, this is obviously 4.16 material. It applies on top of your for-4.16/hid-quirks-cle

[PATCH] HID: input: do not increment usages when a duplicate is found

compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE is created and can be applied to any device that needs this behavior. Signed-off-by: Benjamin Tissoires --- Hi Jiri, this is obviously 4.16 material. It applies on top of your for-4.16/hid-quirks-cleanup/_base. Cheers, Benjamin drivers/hi

[PATCH v3 2/4] HID: quirks: move the list of special devices into a quirk

-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - rebased on top of for-next (1 THRUSTMASTER and 2 ELECOM entries added) no changes in v2 --- drivers/hid/hid-core.c| 537 +--- drivers/hid/hid-quirks.c

[PATCH v3 2/4] HID: quirks: move the list of special devices into a quirk

-by: Benjamin Tissoires --- changes in v3: - rebased on top of for-next (1 THRUSTMASTER and 2 ELECOM entries added) no changes in v2 --- drivers/hid/hid-core.c| 537 +--- drivers/hid/hid-quirks.c | 555

Re: [PATCH v2 0/4] Quirks cleanup and hid-generic niceness

On Nov 20 2017 or thereabouts, Jiri Kosina wrote: > On Thu, 16 Nov 2017, Benjamin Tissoires wrote: > > > > I am planning to queue this for 4.16; do you happen to have any followups > > > since you posted v2 in october? > > > > Cool. I did not updated it si

Re: [PATCH v2 0/4] Quirks cleanup and hid-generic niceness

On Nov 20 2017 or thereabouts, Jiri Kosina wrote: > On Thu, 16 Nov 2017, Benjamin Tissoires wrote: > > > > I am planning to queue this for 4.16; do you happen to have any followups > > > since you posted v2 in october? > > > > Cool. I did not updated it si

[PATCH v3 4/4] HID: core: remove the absolute need of hid_have_special_driver[]

hid_have_special_driver[] useless. It still allows to not see a hid-generic driver bound and removed during boot, so we can keep it around. This will also help other people to have a special HID driver without the need of recompiling hid-core. Signed-off-by: Benjamin Tissoires <benjamin.tis

[PATCH v3 4/4] HID: core: remove the absolute need of hid_have_special_driver[]

hid_have_special_driver[] useless. It still allows to not see a hid-generic driver bound and removed during boot, so we can keep it around. This will also help other people to have a special HID driver without the need of recompiling hid-core. Signed-off-by: Benjamin Tissoires --- no changes in v3

[PATCH v3 3/4] HID: core: move the list of ignored devices in hid-quirks.c

. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- no changes in v3 no changes in v2 --- drivers/hid/hid-core.c | 309 -- drivers/hid/hid-quirks.c | 312 +++ 2 files change

[PATCH v3 0/4] Quirks cleanup and hid-generic niceness

Hi, this is v3 rebased on top of for-next. There are no other changes. Cheers, Benjamin Benjamin Tissoires (4): HID: core: move the dynamic quirks handling in core HID: quirks: move the list of special devices into a quirk HID: core: move the list of ignored devices in hid-quirks.c HID

<    3   4   5   6   7   8   9   10   11   12   >