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

) > 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 <btiss...@redhat.com> wrote: > > - Original Message - >> From: "Elias Vanderstuyft" <elias@gmail.com> >> To: "Benjamin Tissoires" <benjamin.tissoi...@redhat.com> >> Cc:

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

[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 <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 <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 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

Uinput: Deadlock upon UI_DEV_DESTROY ioctl while a non-zero number of ff_effects is still active (uploaded)

Hi everyone, In the process of extending the libsuinput library (https://github.com/tuomasjjrasanen/python-uinput/tree/master/libsuinput/src) to support force feedback, I encountered some bugs in the kernel. For some bugs, I'm not sure for the right fix, so it's safer to first present the problem

Conversion between unsigned and signed for ff_effects_max in uinput and input.

Hi everyone, Making observations based on the following headers: uinput.h: (struct uinput_device).ff_effects_max is defined as unsigned int. uapi/uinput.h: (struct uinput_user_dev).ff_effects_max is defined as __u32. vs input.h: (struct ff_device).max_effects is defined as int, however,

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

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

(-) -- 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

EVIOCSFF macro inconsistency

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

Re: EVIOCSFF macro inconsistency

On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov dmitry.torok...@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

Re: EVIOCSFF macro inconsistency

On Mon, Sep 8, 2014 at 10:24 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote: On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Elias, On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias

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-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] lib: int_sqrt: add int64_sqrt routine

On Mon, Jun 23, 2014 at 11:43 AM, Barry Song 21cn...@gmail.com wrote: From: Yibo Cai yibo@csr.com Get square root of a 64-bit digit on 32bit platforms. CSR SiRFSoC touchscreen driver needs it. Signed-off-by: Yibo Cai yibo@csr.com Signed-off-by: Barry Song baohua.s...@csr.com ---

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 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 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ý 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ý 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

) 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-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

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 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-input in the body of a message to majord...@vger.kernel.org More majordomo

[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

Re: hid-lg2ff handling of zero/low magnitude rumble effects

On Sat, Apr 5, 2014 at 1:02 AM, Hendrik Iben hendrik_i...@web.de wrote: Hi Elias, First of all - thanks for caring about compatibility with old devices. It would be really annoying if something that worked once stopped working on an update. I just dug out my old Wingman Rumblepad (VID 046d

[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

hid-lg2ff handling of zero/low magnitude rumble effects

Hi, I noticed that my rumble wheel (Logitech Formula Vibration Feedback) reacts in a strange way when sending low rumble magnitudes to the device: Assume the following USB command to be send to emit rumble: report-field[0]-value[0] = 0x51; report-field[0]-value[2] = weak;

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

On Sun, Feb 23, 2014 at 3:18 PM, Elias Vanderstuyft elias@gmail.com wrote: From: Elias Vanderstuyft elias@gmail.com If a new (id == -1) ff effect was uploaded from userspace, ff-core.c::input_ff_upload() will have assigned a positive number to the new effect id. Currently, evdev.c

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ý 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,

Re: Questions about the documentation/specification of Linux ForceFeedback input.h

On Wed, Feb 19, 2014 at 7:54 PM, Elias Vanderstuyft elias@gmail.com wrote: Today, I noticed something strange: an explicit saturation of zero in DInput (or at least using the most recent driver for my Logitech MOMO wheel), appears to be transformed to max saturation! (This is why I chose

Re: ff-core effect id handling in case of a failed effect upload

:18PM +0100, Elias Vanderstuyft wrote: On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: (added Dmitry to CC) 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: Hi, Hi

Re: Questions about the documentation/specification of Linux ForceFeedback input.h

On Sun, Feb 16, 2014 at 12:04 AM, Anssi Hannula anssi.hann...@iki.fi wrote: 15.02.2014 22:32, Elias Vanderstuyft kirjoitti: On Sat, Feb 15, 2014 at 3:04 PM, Anssi Hannula anssi.hann...@iki.fi wrote: However, from what I can see, you can achieve the exact same effect with these parameters

Re: Questions about the documentation/specification of Linux ForceFeedback input.h

On Sat, Feb 15, 2014 at 3:05 AM, Anssi Hannula anssi.hann...@iki.fi wrote: 15.02.2014 01:28, Elias Vanderstuyft kirjoitti: Hi everyone, Hi! If you receive my mail, it is either because you: - are listed under the MAINTAINERS for /include/uapi/linux/input.h: http://git.kernel.org/cgit

Re: Questions about the documentation/specification of Linux ForceFeedback input.h

On Sat, Feb 15, 2014 at 3:04 PM, Anssi Hannula anssi.hann...@iki.fi wrote: 15.02.2014 14:14, Elias Vanderstuyft kirjoitti: On Sat, Feb 15, 2014 at 3:05 AM, Anssi Hannula anssi.hann...@iki.fi wrote: 15.02.2014 01:28, Elias Vanderstuyft kirjoitti: Hi everyone, Hi! If you receive my mail

Re: Questions about the documentation/specification of Linux ForceFeedback input.h

On Sun, Feb 16, 2014 at 12:04 AM, Anssi Hannula anssi.hann...@iki.fi wrote: 15.02.2014 22:32, Elias Vanderstuyft kirjoitti: On Sat, Feb 15, 2014 at 3:04 PM, Anssi Hannula anssi.hann...@iki.fi wrote: 15.02.2014 14:14, Elias Vanderstuyft kirjoitti: On Sat, Feb 15, 2014 at 3:05 AM, Anssi Hannula