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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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
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 slot.
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
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
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
>> 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
> 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
>
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
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
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
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
> 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.
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
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: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 Malý 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 Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
On Sat, Apr 26, 2014 at
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 Tuesday 13 of May
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. The
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.
- Have the
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-next so that it is
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
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 current
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
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
and
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 suffice.
The
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 flags
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 Immersion
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 believe
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
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
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
> > > + *
> > > + *
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
> 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
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
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 combined
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
+ *
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
+ *
+ *
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 feedback
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 noted that
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
+ *
+ * Combined effect - An
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
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 Malý wrote:
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 the
62 matches
Mail list logo
