Re: [PATCH-V2 1/1] HID: Force feedback support for the Logitech G920

On Thu, Jan 28, 2016 at 2:33 PM, Jiri Kosina wrote: > On Tue, 26 Jan 2016, Simon Wood wrote: > >> On Sun, January 10, 2016 4:25 pm, Edwin Velds wrote: >> > This patch implements force feedback support for the Logitech >> > G920 Driving Force Racing Wheel. It is a generic

Re: [PATCH-V2 1/1] HID: Force feedback support for the Logitech G920

On Thu, Jan 28, 2016 at 2:33 PM, Jiri Kosina wrote: > On Tue, 26 Jan 2016, Simon Wood wrote: > >> On Sun, January 10, 2016 4:25 pm, Edwin Velds wrote: >> > This patch implements force feedback support for the Logitech >> > G920 Driving Force Racing Wheel. It is a generic implementation >> > of

Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel

On Thu, Dec 10, 2015 at 6:08 PM, Benjamin Tissoires wrote: > On Dec 09 2015 or thereabouts, Dmitry Torokhov wrote: >> On Wed, Dec 9, 2015 at 5:23 PM, Dmitry Torokhov >> wrote: >> > On Thu, Nov 19, 2015 at 10:31 AM, Dmitry Torokhov >> > wrote: >> >> On Thu, Nov 19, 2015 at 02:50:51PM +0100, Jiri

Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel

On Thu, Dec 10, 2015 at 6:08 PM, Benjamin Tissoires wrote: > On Dec 09 2015 or thereabouts, Dmitry Torokhov wrote: >> On Wed, Dec 9, 2015 at 5:23 PM, Dmitry Torokhov >> wrote: >> > On Thu, Nov 19, 2015 at 10:31 AM, Dmitry Torokhov >> >

Re: [PATCH 0/2] HID: Force feedback support for the Logitech G920 Wheel

rivers/hid/hid-logitech-hidpp-base.c > create mode 100644 drivers/hid/hid-logitech-hidpp-base.h > create mode 100644 drivers/hid/hid-logitech-hidpp-ff.c > create mode 100644 drivers/hid/hid-logitech-hidpp-ff.h > delete mode 100644 drivers/hid/hid-logitech-hidpp.c > > -- >

Re: [PATCH 0/2] HID: Force feedback support for the Logitech G920 Wheel

) > create mode 100644 drivers/hid/hid-logitech-hidpp-base.c > create mode 100644 drivers/hid/hid-logitech-hidpp-base.h > create mode 100644 drivers/hid/hid-logitech-hidpp-ff.c > create mode 100644 drivers/hid/hid-logitech-hidpp-ff.h > delete mode 100644 drivers/hid/hid-logitech-hidp

Re: [PATCH v3] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl

On Mon, Nov 9, 2015 at 8:50 AM, Benjamin Tissoires wrote: > > - Original Message - >> From: "Elias Vanderstuyft" >> To: "Benjamin Tissoires" >> Cc: "Dmitry Torokhov" , "David Herrmann" >> , "Peter Hutterer&

Re: [PATCH 5/6] HID: Add vendor specific usage pages for Logitech G920

these pages to the 'ignore' list. >> >> Reported-by: Elias Vanderstuyft >> Signed-off-by: Simon Wood >> --- >> drivers/hid/hid-input.c | 2 +- >> include/linux/hid.h | 2 ++ >> 2 files changed, 3 insertions(+), 1 deletion(-) >> >> diff --

Re: [PATCH 5/6] HID: Add vendor specific usage pages for Logitech G920

axis/buttons being detected. >> >> This patch adds these pages to the 'ignore' list. >> >> Reported-by: Elias Vanderstuyft <elias@gmail.com> >> Signed-off-by: Simon Wood <si...@mungewell.org> >> --- >> drivers/hid/hid-input.c | 2 +- &g

Re: [PATCH v3] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl

On Mon, Nov 9, 2015 at 8:50 AM, Benjamin Tissoires <btiss...@redhat.com> wrote: > > - Original Message - >> From: "Elias Vanderstuyft" <elias@gmail.com> >> To: "Benjamin Tissoires" <benjamin.tissoi...@redhat.com> >> Cc:

[PATCH v2 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF

elpful message and return -EINVAL in case the check fails. Signed-off-by: Elias Vanderstuyft --- Changes in v2: - Rebase on pending patches from David Herrmann and Benjamin Tissoires: - v3 Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl - Input: uinput - rework ABS vali

Re: [PATCH v3] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl

Hi, On Tue, Aug 25, 2015 at 5:12 PM, Benjamin Tissoires wrote: > diff --git a/include/uapi/linux/uinput.h b/include/uapi/linux/uinput.h > index 013c9d8..ef6c9f5 100644 > --- a/include/uapi/linux/uinput.h > +++ b/include/uapi/linux/uinput.h > @@ -20,6 +20,11 @@ > * Author: Aristeu Sergio

[PATCH v2 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF

elpful message and return -EINVAL in case the check fails. Signed-off-by: Elias Vanderstuyft <elias@gmail.com> --- Changes in v2: - Rebase on pending patches from David Herrmann and Benjamin Tissoires: - v3 Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl - I

Re: [PATCH v3] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl

Hi, On Tue, Aug 25, 2015 at 5:12 PM, Benjamin Tissoires wrote: > diff --git a/include/uapi/linux/uinput.h b/include/uapi/linux/uinput.h > index 013c9d8..ef6c9f5 100644 > --- a/include/uapi/linux/uinput.h > +++ b/include/uapi/linux/uinput.h > @@ -20,6 +20,11 @@ >

Re: [PATCH 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF

Hi Dmitry, Excuse me for the long delay. On Thu, Oct 15, 2015 at 2:52 AM, Dmitry Torokhov wrote: > On Thu, Sep 17, 2015 at 07:29:48PM +0200, Elias Vanderstuyft wrote: >> Currently the user can specify a non-zero value for ff_effects_max, >> without setting the EV_FF bi

Re: [PATCH 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF

Hi Dmitry, Excuse me for the long delay. On Thu, Oct 15, 2015 at 2:52 AM, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > On Thu, Sep 17, 2015 at 07:29:48PM +0200, Elias Vanderstuyft wrote: >> Currently the user can specify a non-zero value for ff_effects_max, >> with

Re: [PATCH] Input: input.h: Fix EVIOCSFF macro inconsistency by using _IOW()

On Thu, Sep 17, 2015 at 7:26 PM, Elias Vanderstuyft wrote: > Just like the EVIOCSABS(abs) macro, use the more compact > _IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type)) > for the EVIOCSFF macro. > > Signed-off-by: Elias Vanderstuyft > --- > include/uapi/linu

Re: [PATCH] Input: input.h: Fix EVIOCSFF macro inconsistency by using _IOW()

On Thu, Sep 17, 2015 at 7:26 PM, Elias Vanderstuyft <elias@gmail.com> wrote: > Just like the EVIOCSABS(abs) macro, use the more compact > _IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type)) > for the EVIOCSFF macro. > > Signed-off-by: Elias Vanderstuyft

[PATCH 0/2] Input: Improve handling of ff max_effects

This is a patch-set to improve the handling of max_effects in ff-core and uinput. Elias Vanderstuyft (2): Input: Document and check on implicitly defined FF_MAX_EFFECTS Input: uinput: Sanity check on ff_effects_max and EV_FF drivers/input/ff-core.c | 5 + drivers/input/misc

[PATCH 1/2] Input: Document and check on implicitly defined FF_MAX_EFFECTS

r exceed FF_GAIN. Define FF_MAX_EFFECTS as FF_GAIN and check on this limit in ff-core. Signed-off-by: Elias Vanderstuyft --- drivers/input/ff-core.c| 5 + include/uapi/linux/input.h | 8 2 files changed, 13 insertions(+) diff --git a/drivers/input/ff-core.c b/drivers/input

[PATCH 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF

ing a check in uinput_create_device() and omitting setup of ff-core infrastructure silently in case the check fails, perform the check early in uinput_setup_device(), and print a helpful message and return -EINVAL in case the check fails. Signed-off-by: Elias Vanderstuyft --- drivers/input/m

[PATCH] Input: input.h: Fix EVIOCSFF macro inconsistency by using _IOW()

Just like the EVIOCSABS(abs) macro, use the more compact _IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type)) for the EVIOCSFF macro. Signed-off-by: Elias Vanderstuyft --- include/uapi/linux/input.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux

[PATCH 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF

ing a check in uinput_create_device() and omitting setup of ff-core infrastructure silently in case the check fails, perform the check early in uinput_setup_device(), and print a helpful message and return -EINVAL in case the check fails. Signed-off-by: Elias Vanderstuyft <elias@gma

[PATCH 0/2] Input: Improve handling of ff max_effects

This is a patch-set to improve the handling of max_effects in ff-core and uinput. Elias Vanderstuyft (2): Input: Document and check on implicitly defined FF_MAX_EFFECTS Input: uinput: Sanity check on ff_effects_max and EV_FF drivers/input/ff-core.c | 5 + drivers/input/misc

[PATCH 1/2] Input: Document and check on implicitly defined FF_MAX_EFFECTS

r exceed FF_GAIN. Define FF_MAX_EFFECTS as FF_GAIN and check on this limit in ff-core. Signed-off-by: Elias Vanderstuyft <elias@gmail.com> --- drivers/input/ff-core.c| 5 + include/uapi/linux/input.h | 8 2 files changed, 13 insertions(+) diff --git a/drivers/input/ff-

[PATCH] Input: input.h: Fix EVIOCSFF macro inconsistency by using _IOW()

Just like the EVIOCSABS(abs) macro, use the more compact _IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type)) for the EVIOCSFF macro. Signed-off-by: Elias Vanderstuyft <elias@gmail.com> --- include/uapi/linux/input.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH 00/12] HID: hid-lg, hid-lg4ff: Mostly cleanup patches

which made use of effects with nonzero attack times, thus the ff-memless timer's timeout got modified often), and then unplugging the device while in use. Instead of crashing, the kernel behaved like it should, no panics or lockups were found. Tested with to following devices: - Logitech M

Re: [PATCH 00/12] HID: hid-lg, hid-lg4ff: Mostly cleanup patches

, the kernel behaved like it should, no panics or lockups were found. Tested with to following devices: - Logitech MOMO (Black) : PID 0xCA03 - Logitech Formula Vibration : PID 0xCA04 Tested-by: Elias Vanderstuyft elias@gmail.com Regards, Elias -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH v2 0/4] HID: hid-lg4ff: Improve handling of Logitech multimode gaming wheels

t; 2.3.0 > Applied cleanly on kernel 3.18.6, and retested with: - Logitech Formula Vibration Wheel - Logitech MOMO (Black) Wheel Everything keeps working like it was before, which is correct because these wheels are no multimode wheels. Tested-by: Elias Vanderstuyft Thanks, Elias -- To unsubsc

Re: [PATCH v2 0/4] HID: hid-lg4ff: Improve handling of Logitech multimode gaming wheels

with: - Logitech Formula Vibration Wheel - Logitech MOMO (Black) Wheel Everything keeps working like it was before, which is correct because these wheels are no multimode wheels. Tested-by: Elias Vanderstuyft elias@gmail.com Thanks, Elias -- To unsubscribe from this list: send the line unsubscribe linux

Re: [PATCH 0/4] HID: Improve handling of multimode Logitech handling wheels

tions(+), 76 deletions(-) > > -- > 2.2.2 > Applied cleanly on kernel 3.17.8, and tested with: - Logitech Formula Vibration Wheel - Logitech MOMO (Black) Wheel Everything keeps working like it was before, which is correct because these wheels are no multimode wheels. Tested-by: E

Re: [PATCH 0/4] HID: Improve handling of multimode Logitech handling wheels

(-) -- 2.2.2 Applied cleanly on kernel 3.17.8, and tested with: - Logitech Formula Vibration Wheel - Logitech MOMO (Black) Wheel Everything keeps working like it was before, which is correct because these wheels are no multimode wheels. Tested-by: Elias Vanderstuyft elias@gmail.com Thanks, Elias

Re: PATCH hid: Implement mode switching on Logitech gaming wheels accordingly to the documentation

la Vibration : PID 0xCA04 Behaviour didn't deviate from normal, which is as expected because these devices don't use the native versus compatibility mode, according to the documentation. So I consider this patch successful for these devices: Tested-by: Elias Vanderstuyft Elias -- To unsubscribe fr

Re: PATCH hid: Implement mode switching on Logitech gaming wheels accordingly to the documentation

-by: Elias Vanderstuyft elias@gmail.com Elias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Tue, May 20, 2014 at 11:26 PM, Elias Vanderstuyft wrote: > On Tue, May 20, 2014 at 10:58 PM, Michal Malý > wrote: >> On Tuesday 20 of May 2014 16:16:12 si...@mungewell.org wrote: >>> Regarding the question of emulated vs. real effects, can we extend the API >>>

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Tue, May 20, 2014 at 11:26 PM, Elias Vanderstuyft elias@gmail.com wrote: On Tue, May 20, 2014 at 10:58 PM, Michal Malý madcatxs...@devoid-pointer.net wrote: On Tuesday 20 of May 2014 16:16:12 si...@mungewell.org wrote: Regarding the question of emulated vs. real effects, can we extend

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Tue, May 20, 2014 at 11:38 PM, Roland Bosa wrote: > On 05/20/2014 12:00 PM, Michal Malı wrote: > There's a healthy amount of > code in the Windows driver that you would call 'quirks' which deals with > deciding how to allocate multiple springs and dampers to a single slot. But 2 Spring

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 3:35 PM, Elias Vanderstuyft wrote: > On Wed, May 21, 2014 at 4:13 AM, Michal Malý > wrote: >> Proper decoupling of the userspace and driver is the only important thing >> that >> is missing from the current code. > > Also dynamic updating

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 12:17 PM, Nestor Lopez Casado wrote: > Elias, Simon, Michal, > > It is unfortunate that we didn't get back to you in 2013 when you > asked for help in reverse engineering, oftentimes we have conflicting > priorities and a particular request may be left laying around for

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 4:13 AM, Michal Malý wrote: > On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: >> >> The file format of an IFR is probably easily deducible. There's a lot of >> textual clues to parameters and the values are also written out in >> string form. >> >> I don't have a

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 4:13 AM, Michal Malý wrote: > On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: >> In any case, the USB traffic should be decoupled from the app. Any force >> updates should only change state in the ff-memless[-next] driver. Any >> change there should trickle down to a

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 4:13 AM, Michal Malý madcatxs...@devoid-pointer.net wrote: On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: In any case, the USB traffic should be decoupled from the app. Any force updates should only change state in the ff-memless[-next] driver. Any change there

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 4:13 AM, Michal Malý madcatxs...@devoid-pointer.net wrote: On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote: The file format of an IFR is probably easily deducible. There's a lot of textual clues to parameters and the values are also written out in string form. I

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 12:17 PM, Nestor Lopez Casado nlopezca...@logitech.com wrote: Elias, Simon, Michal, It is unfortunate that we didn't get back to you in 2013 when you asked for help in reverse engineering, oftentimes we have conflicting priorities and a particular request may be left

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 21, 2014 at 3:35 PM, Elias Vanderstuyft elias@gmail.com wrote: On Wed, May 21, 2014 at 4:13 AM, Michal Malý madcatxs...@devoid-pointer.net wrote: Proper decoupling of the userspace and driver is the only important thing that is missing from the current code. Also dynamic

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Tue, May 20, 2014 at 11:38 PM, Roland Bosa rb...@logitech.com wrote: On 05/20/2014 12:00 PM, Michal Malı wrote: There's a healthy amount of code in the Windows driver that you would call 'quirks' which deals with deciding how to allocate multiple springs and dampers to a single slot. But 2

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Tue, May 20, 2014 at 10:58 PM, Michal Malý wrote: > On Tuesday 20 of May 2014 16:16:12 si...@mungewell.org wrote: >> Regarding the question of emulated vs. real effects, can we extend the API >> so that applications can know which effects are really supported, and >> enable/disable emulation

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Tue, May 20, 2014 at 10:58 PM, Michal Malý madcatxs...@devoid-pointer.net wrote: On Tuesday 20 of May 2014 16:16:12 si...@mungewell.org wrote: Regarding the question of emulated vs. real effects, can we extend the API so that applications can know which effects are really supported, and

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 14, 2014 at 10:35 AM, Michal Malý wrote: > Hi Dmitry, > > thank you for reviewing this. > > On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote: >> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote: >> > + >> > +/** DEFINITION OF TERMS >> > + * >> > + * Combined effect

Re: [PATCH v4 01/24] input: Add ff-memless-next module

On Wed, May 14, 2014 at 10:35 AM, Michal Malý madcatxs...@devoid-pointer.net wrote: Hi Dmitry, thank you for reviewing this. On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote: On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote: + +/** DEFINITION OF TERMS + * + *

Re: [PATCH v3 23/24] hid: Port hid-lg4ff to ff-memless-next

dbg_hid("Unsupported effect command"); > + return -EINVAL; > } > - return 0; > } > > /* Sends default autocentering command compatible with > @@ -610,7 +633,7 @@ int lg4ff_init(struct hid_device *hid) > for (j = 0;

Re: [PATCH v3 23/24] hid: Port hid-lg4ff to ff-memless-next

) return error; -- 1.9.2 You can add Tested-by: Elias Vanderstuyft elias@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: [PATCH 0/24] Introduce ff-memless-next as an improved replacement for ff-memless

On Mon, Apr 21, 2014 at 12:29 AM, wrote: > >> Did the WiiWheel have working FF_CONSTANT before this patchset? >> It would be weird if yes, because lg4ff is also used for MOMO-Black >> which works fine. > > Yes, I think that the force requested by fftest was just too weak to > actually move the

Re: [PATCH 0/24] Introduce ff-memless-next as an improved replacement for ff-memless

On Mon, Apr 21, 2014 at 12:29 AM, si...@mungewell.org wrote: Did the WiiWheel have working FF_CONSTANT before this patchset? It would be weird if yes, because lg4ff is also used for MOMO-Black which works fine. Yes, I think that the force requested by fftest was just too weak to actually

Re: [PATCH 13/24] Port hid-lg3ff to ff-memless-next

On Wed, Apr 9, 2014 at 1:24 PM, Michal Malý wrote: > Port hid-lg3ff to ff-memless-next > > Signed-off-by: Michal Malý > --- > drivers/hid/Kconfig | 2 +- > drivers/hid/hid-lg3ff.c | 56 > +++-- > 2 files changed, 37 insertions(+), 21

Re: [PATCH 0/24] Introduce ff-memless-next as an improved replacement for ff-memless

On Sun, Apr 20, 2014 at 7:27 PM, wrote: > Hi all, > I got a chance to build this series of patches and test with the > controllers I have (*). Without specific instructions I wasn't sure > exactly what to test, but it seems to be OK and the devices > rumbled/wobbled appropriately, > Simon > >

Re: [PATCH 12/24] Port hid-lgff to ff-memless-next

On Wed, Apr 9, 2014 at 1:24 PM, Michal Malý wrote: > Port hid-lgff to ff-memless-next > > Signed-off-by: Michal Malý > --- > drivers/hid/Kconfig| 2 +- > drivers/hid/hid-lgff.c | 63 > ++ > 2 files changed, 44 insertions(+), 21 deletions(-)

Re: [PATCH 12/24] Port hid-lgff to ff-memless-next

On Wed, Apr 9, 2014 at 1:24 PM, Michal Malý madcatxs...@devoid-pointer.net wrote: Port hid-lgff to ff-memless-next Signed-off-by: Michal Malý madcatxs...@devoid-pointer.net --- drivers/hid/Kconfig| 2 +- drivers/hid/hid-lgff.c | 63 ++

Re: [PATCH 0/24] Introduce ff-memless-next as an improved replacement for ff-memless

On Sun, Apr 20, 2014 at 7:27 PM, si...@mungewell.org wrote: Hi all, I got a chance to build this series of patches and test with the controllers I have (*). Without specific instructions I wasn't sure exactly what to test, but it seems to be OK and the devices rumbled/wobbled appropriately,

Re: [PATCH 13/24] Port hid-lg3ff to ff-memless-next

On Wed, Apr 9, 2014 at 1:24 PM, Michal Malý madcatxs...@devoid-pointer.net wrote: Port hid-lg3ff to ff-memless-next Signed-off-by: Michal Malý madcatxs...@devoid-pointer.net --- drivers/hid/Kconfig | 2 +- drivers/hid/hid-lg3ff.c | 56 +++--

Re: [PATCH] HID: lg2ff: add rumble magnitude clamping quirk

Since this patch haven't been applied yet, I withdraw this patch for the following reason: It will get in as a part of the move to ff-memless-next. Elias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH] HID: lg2ff: add rumble magnitude clamping quirk

Since this patch haven't been applied yet, I withdraw this patch for the following reason: It will get in as a part of the move to ff-memless-next. Elias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo

[PATCH] HID: lg2ff: add rumble magnitude clamping quirk

ame thing appears to happen in the Windows Logitech driver, except the max clamping bound is not 0xfd, but 0xfe. Experimentally, I proved this to be wrong. Tested-by: Hendrik Iben Signed-off-by: Elias Vanderstuyft Cc: Edgar Simo-Serra Cc: Michal Malý Cc: linux-in...@vger.kernel.org

[PATCH] HID: lg2ff: add rumble magnitude clamping quirk

thing appears to happen in the Windows Logitech driver, except the max clamping bound is not 0xfd, but 0xfe. Experimentally, I proved this to be wrong. Tested-by: Hendrik Iben hendrik_i...@web.de Signed-off-by: Elias Vanderstuyft elias@gmail.com Cc: Edgar Simo-Serra bobb...@gmail.com

[PATCH v2 1/1] Input: don't modify the id of ioctl-provided ff effect on upload failure

s been discussed on: http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html ("ff-core effect id handling in case of a failed effect upload") Suggested-by: Dmitry Torokhov Signed-off-by: Elias Vanderstuyft Cc: Anssi Hannula Cc: Michal Malý Cc: linux-in...@vger.kernel.org

[PATCH v2 1/1] Input: don't modify the id of ioctl-provided ff effect on upload failure

discussed on: http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html (ff-core effect id handling in case of a failed effect upload) Suggested-by: Dmitry Torokhov dmitry.torok...@gmail.com Signed-off-by: Elias Vanderstuyft elias@gmail.com Cc: Anssi Hannula anssi.hann...@iki.fi Cc: Michal

Fwd: [PATCH] input: ff-memless: don't schedule already playing effect to play again

-- Forwarded message -- From: Michal Malý Date: Sun, Mar 2, 2014 at 2:29 PM Subject: Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again To: Elias Vanderstuyft On Sunday 02 of March 2014 14:17:58 you wrote: > On Sun, Mar 2, 2014 at 12:35 PM, Fe

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg wrote: > When an effect with zero replay length, zero replay delay > and zero envelope attack length is uploaded, it is played and then scheduled > to play > again one timer tick later. This triggers a warning (URB submitted while > active) in

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg felix.rue...@gmail.com wrote: When an effect with zero replay length, zero replay delay and zero envelope attack length is uploaded, it is played and then scheduled to play again one timer tick later. This triggers a warning (URB submitted while

Fwd: [PATCH] input: ff-memless: don't schedule already playing effect to play again

-- Forwarded message -- From: Michal Malý madcatxs...@prifuk.cz Date: Sun, Mar 2, 2014 at 2:29 PM Subject: Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again To: Elias Vanderstuyft elias@gmail.com On Sunday 02 of March 2014 14:17:58 you wrote

Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it

On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý wrote: > On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote: >> >> I think we should extend the current ff-memless instead of duplicating >> its functionality (even on a "for now" basis). >> >> Having looked at ff-memless-next briefly, it seems

Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it

On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý madcatxs...@prifuk.cz wrote: On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote: I think we should extend the current ff-memless instead of duplicating its functionality (even on a for now basis). Having looked at ff-memless-next briefly,