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
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 combina
-- 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 P
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 unsu
default:
> + 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
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 -
The same 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.kerne
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
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(-)
>
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
>
> tes
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 deletions(-)
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 wh
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
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 so
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
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 FEdi
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 so
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
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 effects
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
>>>
644 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-hidpp.c
>
> --
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
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:
- Logit
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
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
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 fea
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 bit.
>&
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 Rozansk
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
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(-)
>>
>&g
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&
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
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
g 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
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
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
36 matches
Mail list logo
