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
>>> so that applications can know wh
>> But 2 Spring effects with different offsets and non-zero effective
>> force can't be combined into a single slot (without streaming them
>> with Constant force), right?
>
> Yes - you cannot *download* two springs to a single slot. You need to
> choose (allocate) one of them. The winner gets the
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 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 of periodic effects is not yet su
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 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 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
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 some
time before being addressed. But please, don't hesitate to re-kick u
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 FEdit file at hand, but I suppose it will be similar.
I believ
On 05/20/2014 04:30 PM, si...@mungewell.org wrote:
> Sounds like these are the effect files produced by FEdit tool (from MS
> DirectX SDK), and/or played back by pressing buttons when configuring the
> Logitech driver on Windows ('wooden bridge', etc)...
Prior to the FEdit tool, there was Immersio
On Tuesday 20 of May 2014 19:45:44 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 somehow?
> >
> > I suppose that a few extra fl
>> 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 somehow?
>
> I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in
> "uapi/linux/input.h" should s
> IMO, there are two types of games. The "arcade" ones, which have a set
> of 'canned' force effects, which play whenever an event happens in game.
> And the "simulation" ones, which base the game on a physics engine. The
> latter can redirect some variables of their engine to the input layer
> an
On 05/20/2014 12:39 PM, si...@mungewell.org wrote:
> hopefully bring Linux into scope for force-feedback of AAA game quality.
^ That's my objective too.
> Mostly this has come from a small group of people reverse engineering the
> Logitech wheels, which leads to the 'tailor-made' situation. But w
On 05/20/2014 12:00 PM, Michal Malý wrote:
> Hi,
>
> "ff-memless-next" was designed with behavior of Logitech devices in mind,
> however it was always meant as a general replacement for the current "ff-
> memless". After some followup discussion it's unlikely that it will be
> mainlined in its c
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 Tuesday 20 of May 2014 16:16:12 si...@mungewell.org wrote:
> > To bring this to a conclusion we could go from, would this be an
> > acceptable
> > solution?
> >
> > - Have the HW-specific driver talk directly to ff-core and reimplement
> > upload(),
> > play(), etc.
> > - Rewrite "ff-memless-ne
> To bring this to a conclusion we could go from, would this be an
> acceptable
> solution?
>
> - Have the HW-specific driver talk directly to ff-core and reimplement
> upload(),
> play(), etc.
> - Rewrite "ff-memless-next" so that it is not a self-contained module but
> a
> library of functions.
> Allow me to introduce myself. I'm Roland Bosa and I work for Logitech,
> more specifically the gaming group. I have been tasked to look into
> gaming device support for Linux and I just started following this list
> and studying the kernel code related to the Logitech Force Feedback
> devices. Th
On Tuesday 20 of May 2014 11:32:14 Roland Bosa wrote:
> On 05/20/2014 02:27 AM, Michal Malý wrote:
> > On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:
> >> On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Malý wrote:
> >>> Hi Dmitry,
> >>>
> >>> thank you for reviewing this.
> >>>
> >
On 05/20/2014 02:27 AM, Michal Malý wrote:
> On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:
>> On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Malý wrote:
>>> Hi Dmitry,
>>>
>>> thank you for reviewing this.
>>>
>>> On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
On Sat
On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:
> On Wed, May 14, 2014 at 10:35:25AM +0200, 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
On Wednesday 14 of May 2014 11:14:02 Dmitry Torokhov wrote:
> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> > +
> > +/** input_ff_create_mlnx() - Register a device within ff-memless-next and
> > + * the kernel force feedback system
> > + * @dev: Pointer to
On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:
> On Wed, May 14, 2014 at 10:35:25AM +0200, 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
On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> +
> +/** input_ff_create_mlnx() - Register a device within ff-memless-next and
> + * the kernel force feedback system
> + * @dev: Pointer to the struct input_dev associated with the device.
> + * @data: Any dev
On Wed, May 14, 2014 at 10:35:25AM +0200, 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
> > > + *
> > > + * Com
On Wed, May 14, 2014 at 11:11:40AM -0400, si...@mungewell.org wrote:
>
> > If we ever come across a really memoryless device it should not be
> > particularly difficult to add another callback to ff-memless-next which
> > would emulate conditional effects with constant force.
>
> It should be not
> If we ever come across a really memoryless device it should not be
> particularly difficult to add another callback to ff-memless-next which
> would emulate conditional effects with constant force.
It should be noted that some (/many?) applications/games already use the
CF with position feedbac
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 -
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 - An effect whose force is a superposition of forces
> > + *
Hi Michal,
On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> +
> +/** DEFINITION OF TERMS
> + *
> + * Combined effect - An effect whose force is a superposition of forces
> + * generated by all effects that can be added together.
> + * Only one comb
Add ff-memless-next module
Signed-off-by: Michal Malý
Tested-by: Elias Vanderstuyft
---
drivers/input/Kconfig | 11 +
drivers/input/Makefile|1 +
drivers/input/ff-memless-next.c | 1037 +
include/linux/input/ff-memless-
32 matches
Mail list logo
