linuxconsole-dev

Re: hello...and MS-FF2...

[Johann D. <jo...@Do...>]

On Sun, 20 Jan 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> >
> >I checked it. It's not the iforce, protocol, what would have been
> >surprising anyway. The bit used for the deadman sensor just happend to be
> >the same bit as I-Force uses, but that was just luck.
> >
>         I supposed it is the standard PID protocol then?? I realized it 

Probably.

> should be something other than I-Force, because I tried adding the 
> joystick to iforce-main.c and iforce-usb.c and it just didn't work. Then 
> I suppose we must implement a non-I-force PID driver, am I correct?? If 
> so I suggest we use the same base API and ioctls that are being used for 
> I-Force, just sending different data to the device...perhaps (to be 
> better organized), take the common part of the current I-force code and 
> put it as generic force feedback code, then add I-force and standard PID 
> as sub-options...

Vojtech and I designed the ff API so that it's not I-Force specific. We
may need to add/change some parts of the API, but what the ff_effect
struct is supposed to be generic enough to be used with other kinds of
devices. Have a look at input.h. Nothing in it should be I-Force specific.
Now, it's true there are parts that could be re-used or adapted from
iforce.c (the parameter blocks allocation and handling, for example).

-- 
Johann Deneux

Re: hello...and MS-FF2...

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

>On Sun, 20 Jan 2002, Rodrigo Damazio wrote:
>
>>Johann Deneux wrote:
>>
>>>I checked it. It's not the iforce, protocol, what would have been
>>>surprising anyway. The bit used for the deadman sensor just happend to=
 be
>>>the same bit as I-Force uses, but that was just luck.
>>>
>>        I supposed it is the standard PID protocol then?? I realized it=
=20
>>
>
>Probably.
>
        What else do we need to check to see if it is?? (I have a lot of=20
free time these days, I can do it)

>>should be something other than I-Force, because I tried adding the=20
>>joystick to iforce-main.c and iforce-usb.c and it just didn't work. The=
n=20
>>I suppose we must implement a non-I-force PID driver, am I correct?? If=
=20
>>so I suggest we use the same base API and ioctls that are being used fo=
r=20
>>I-Force, just sending different data to the device...perhaps (to be=20
>>better organized), take the common part of the current I-force code and=
=20
>>put it as generic force feedback code, then add I-force and standard PI=
D=20
>>as sub-options...
>>
>
>Vojtech and I designed the ff API so that it's not I-Force specific. We
>may need to add/change some parts of the API, but what the ff_effect
>struct is supposed to be generic enough to be used with other kinds of
>devices. Have a look at input.h. Nothing in it should be I-Force specifi=
c.
>Now, it's true there are parts that could be re-used or adapted from
>iforce.c (the parameter blocks allocation and handling, for example).
>
        Yes, I had realized that - everything is quite generic...
        I'll try to create a ff_pid.c file based on iforce*.c, and make=20
it send the data according to the PID specs and the dumps I have...or=20
have any of you already started that?
        Btw, how do custom effects work??

Rodrigo  =20

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************

Re: hello...and MS-FF2...

[Bj|rn A. <d3a...@dt...>]

Quoting Rodrigo Damazio <cu...@uo...>:
> Johann Deneux wrote:
> >On Sun, 20 Jan 2002, Rodrigo Damazio wrote:
> >>>
> >>        I supposed it is the standard PID protocol then?? I realized it 
> >
> >Probably.
> >
>         What else do we need to check to see if it is?? (I have a lot of 
> free time these days, I can do it)

Implement the PID spec and see if it works... :)
 
No, really, I have no reason to doubt that it is really a PID device. It
says it is, it has very plausible reports in it, and the dumps you sent
looks good. (at least the parts I've read.)

> >Vojtech and I designed the ff API so that it's not I-Force specific. We
> >may need to add/change some parts of the API, but what the ff_effect
> >struct is supposed to be generic enough to be used with other kinds of
> >devices. Have a look at input.h. Nothing in it should be I-Force specific.
> >Now, it's true there are parts that could be re-used or adapted from
> >iforce.c (the parameter blocks allocation and handling, for example).
> >
>         Yes, I had realized that - everything is quite generic...

I agree. It's a good interface.

>         I'll try to create a ff_pid.c file based on iforce*.c, and make 
> it send the data according to the PID specs and the dumps I have...or 
> have any of you already started that?

Yes, I have. As of now I can upload (some) effects, but I haven't been 
able to play on yet. Hopefully tonight... I'll try to get some patches
sent as well - there's a few more generic fixes in there as well. 

>         Btw, how do custom effects work??

Just like any other effect, all you have to do is send that data along
in another report. Look at the diagram on page 44 of the PID spec, it's
fairly clear.

/August.
-- 
Wrong on most accounts.  const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo.  const Foo const *foo; would mean the same but is
illegal (double const).  You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system

Re: hello...and MS-FF2...

[Johann D. <jo...@Do...>]

On Sun, 20 Jan 2002, Rodrigo Damazio wrote:

>         Btw, how do custom effects work??

They are not supported by the current API. We need to add it. The problem
would be how to pass the variable length data describing the shape of the
force ?
One way would be to append it to the ff_effect:

ff_effect* custom;
s8* shape;
custom = (ff_effect*)malloc(sizeof(ff_effect) + len_shape);
shape = ((s8*)custom) + sizeof(ff_effect);

/* Init custom */
...

/* Init shape */
for (i=0; i<len_shape; ++i) {
  shape(i) = ...;
}

/* Upload effect to device */
ioctl(fd, EVIOCS_FF, custom, sizeof(ff_effect)+len_shape);

If we can use ISO C instead of ANSI C, I think there is a feature in the
new specs allowing for variable-size arrays to be placed at the end of a
structure, which eliminates the initialization of the shape pointer.

Another solution, which looks much better to me, would be to separate the
downloading of parameters and the creation of the effect with two
different ioctls. We would move the union out of ff_effect to
ff_constant_param, ff_interactive_param...
First the parameters would be downloaded, then the effect itself.
In ff_struct, we would add a "pointer" to the parameter block to use.

Opinions ?
-- 
Johann Deneux