linuxconsole-dev

Re: Custom-shaped periodic effects in force feedback

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

On Mon, 21 Jan 2002, Rodrigo Damazio wrote:

> >
> > 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 ?
> >
>        How about only having two different ioctls in the case of custom 
> effects(and leaving others unaffected, thus not moving the unions)?? 
> Then one ioctl would be to download the custom effect data, then the
> normal one which creates the effect just as it's done now, with a 
> FF_CUSTOM type...something like this:
> 
> ff_effect custom;
> ff_customdata *custom_data;
> size_t custom_data_size;
> 
> .... (malloc and assign data to these structs)
> 
> /* Upload custom data */
> ioctl(fd, EVIOCSCUSTOM, custom_data,  custom_data_size);
> 
> custom.shapeid = customdata->shapeid;
> 
> /* Upload effect */
> ioctl(fd, EVIOCSFF, &custom, sizeof(ff_effect));
> 
>    Then we'd have to write a little shapeid management(easy)...and 
> probably we'd delete a shape from kernel memory after it's used in an 
> effect(just so we don't need another ioctl for that), assigning -1 back 
> to shapeid in ff_effect(and to avoid bad programming, just make it 
> ignore any FF_CUSTOM where a shapeid is -1)...or even keep it and create 
> a EVIOCRMCUSTOM to remove it when desired...
> 
> Let me know what you think...

That's quite close to what I had in mind, except you apply it only for
custom effects. Deciding to keep or not the union looks like a rather
unimportant decision to me. I suggested to remove the union and use
parameter blocks to keep some kind of coherency in the API.

More important is the question about whether we should have parameter
blocks in the API at all.

The parameter block ioctl approach rises the following issues:
- One parameter block may be used by several effects. One may see that as
a feature, as it might allow for some memory to be saved. I am not
convinced it would be very useful, though.
- What should be put into parameters, and what should be put into the core
of the effect ? For example, the direction of a constant effect is encoded
in the core of the effect in the I-Force protocol, while the amplitude is
stored in a parameter block. It seems PID does the same. What if another
protocol chooses to put the direction into parameter blocks ?

This can lead to tricky situations. Imagine we put some attribute X into
the ff_effect, while a device really stores it in the parameter block. Now
the application decides to update the attribute X of an effect. The driver
has to change X in the parameter block (because that's what the device
wants). Imagine this parameter block is shared by another effect... If we
change it here, the attribute X of the second effect is also modified,
what is not the desired behaviour.

-- 
Johann Deneux

Custom-shaped periodic effects in force feedback

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

Johann Deneux wrote:


> 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 probl=
em
> would be how to pass the variable length data describing the shape of t=
he
> force ?
> One way would be to append it to the ff_effect:
>
> ff_effect* custom;
> s8* shape;
> custom =3D (ff_effect*)malloc(sizeof(ff_effect) + len_shape);
> shape =3D ((s8*)custom) + sizeof(ff_effect);
>
> /* Init custom */
> ...
>
> /* Init shape */
> for (i=3D0; i<len_shape; ++i) {
>  shape(i) =3D ...;
> }
>
> /* 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 th=
e
> new specs allowing for variable-size arrays to be placed at the end of =
a
> structure, which eliminates the initialization of the shape pointer.
>
       I personally think that wouldn't be very good, because it'd put a=20
restriction on what compilers or compiler options could be used for it...

>
> Another solution, which looks much better to me, would be to separate t=
he
> 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 ?
>
       How about only having two different ioctls in the case of custom=20
effects(and leaving others unaffected, thus not moving the unions)??=20
Then one ioctl would be to download the custom effect data, then the=20
normal one which creates the effect just as it's done now, with a=20
FF_CUSTOM type...something like this:

ff_effect custom;
ff_customdata *custom_data;
size_t custom_data_size;

.... (malloc and assign data to these structs)

/* Upload custom data */
ioctl(fd, EVIOCSCUSTOM, custom_data,  custom_data_size);

custom.shapeid =3D customdata->shapeid;

/* Upload effect */
ioctl(fd, EVIOCSFF, &custom, sizeof(ff_effect));

   Then we'd have to write a little shapeid management(easy)...and=20
probably we'd delete a shape from kernel memory after it's used in an=20
effect(just so we don't need another ioctl for that), assigning -1 back=20
to shapeid in ff_effect(and to avoid bad programming, just make it=20
ignore any FF_CUSTOM where a shapeid is -1)...or even keep it and create=20
a EVIOCRMCUSTOM to remove it when desired...

Let me know what you think...
Rodrigo

--=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...

[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

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

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

[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: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

[Vojtech P. <vo...@su...>]

On Sat, Jan 19, 2002 at 12:58:16AM +0100, Bj|rn Augustsson wrote:
> Quoting Vojtech Pavlik <vo...@su...>:
> > On Wed, Jan 16, 2002 at 05:38:56PM +0100, Bj|rn Augustsson wrote:
> > > 
> > > OK, longish status update time:
> > > 
> > > It's not really a button, but it could be useful to a game anyway. You
> > > could bind pause to it for example, or something. Do I report it to the
> > > API as a button, or do I add a new bit about this somewhere?
> > 
> > It's already defined: BTN_DEAD (The 'deadman' switch).
> 
> Aha! Good to know. (I thought it meant something like a dead key on a
> keyboard...)
> Good, that solves that.
> 
> > > Also, HID devices (can) have physical units bound to them, as in "This
> > > axis measues rotation, +- 30 degrees, 8bit resolution." There is no way
> > > for an app to get this information thru the input API, and it should
> > > probably be added at some point. It's not critical for game controllers,
> > > but other apps might want that information.
> > 
> > Yes, we may later add some IOCTLs to report and structures to hold that
> > information.
> 
> OK.
>  
> > > (But as I said, I'll have to look at the current hid code, as I've been
> > > working against what's in 2.4.18pre3. Maybe things have changed.)
> > 
> > There is a lot of differences, namely in the control URB handling.
> 
> OK, I got the new code from CVS (Actually, that crashed when init
> started on my box, so I went with Johanns input-only patch against
> 2.4.17 instead) and merged with it.

I've sent some newer input patches to the list, you may as well try
those or 2.4.2-dj4 when it comes out (it'll contain all the newest input
stuff).

> It doesn't help. I have a few questions:
> 
> The joystick has an interrupt output endpoint. The HID spec says an
> output pipe is optional, and that if one exists, output reports are to
> be sent over it. I can't see any initialization of output pipes in the
> HID code though, nor data structures in the hid_device struct.

The output pipe isn't implememented.

> Question #1: Are there any HID devices with output interrupt pipes that
>              work with this code?

Yes, and no. The WingMan ForceFeedback Mouse is known to work, but
without FF. But the driver does communication with it over the control
pipe and it works.

> If I understand this correctly I'll need another urb and some more
> stuff. I'll also rename the input URB to add some clarity there.

Yes, this is reasonable. You also should modify the report read/write
queue to use the output pipe in cas it's present.

> Second problem. When hid_probe() gets called, often the input pipe is
> aleady stalled. (And if it isn't, it stalls after the first call to
> hid_submit_report.) Attemting to get any input reports results in 
> "hid-core.c: ctrl urb status -32 received" messages.

This isn't the input pipe, this is the control pipe. The stall is bad
and probably means we did something the joystick didn't like.

> Question #2: Under what circumstances do pipes stall? I've read the
>              relevant parts of the USB spec, but I'm not sure about
>              the non-error stalls.

I don't think it can happen in a non-error case in HID. 

> Question #3: How can I clear the stall? Or rather what actually happens
>              when I do? I tried using usb_clear_halt() from 
>              hid_init_reports() and that wedged the kernel.
>              I'm guessing I can't do that when TASK_UNINTERRUPTIBLE?

No idea, never tried this, ask the USB guys.

> Oh yeah, and
> 
> Question #4: Do I send patches here or to usb-devel or where? I'm
>              confused...

Here. Although this is USB code, the main repository for it is here.

-- 
Vojtech Pavlik
SuSE Labs

Re: Input patch ...

[James S. <jsi...@tr...>]

> > Okay. Personally I hate the idea of drivers in bus directories but that is
> > my personal taste. 
> 
> Linus prefers it, and really I'm not going to be the judge here.

:-/

> Yeah. The only known way to solve this is to ssh into the CVS server and
> move both the files and their histories manually. Well, perhaps the
> history can be retrieved and stored from/to the CVS server as well some
> way without ssh access.

No ssh access to CVS on SF. Hm. I can find out. 

> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> 

Re: Input patch ...

[Vojtech P. <vo...@su...>]

On Sun, Jan 20, 2002 at 06:49:56AM -0800, James Simmons wrote:

> > Actually, I don't mind the USB stuff staying where it is. There are
> > always two places for a driver to be: with other drivers for the bus it
> > lives on (like USB), or with other drivers that have the same interface
> > (like V4L or SCSI or Input ...).
> 
> Okay. Personally I hate the idea of drivers in bus directories but that is
> my personal taste. 

Linus prefers it, and really I'm not going to be the judge here.

> 
> > I don't think there is anything like 'cvs move'. And if you do 'mv; cvs
> > remove; cvs add', you lose versions and the whole history of the file.
> 
> Yuck! 

Yeah. The only known way to solve this is to ssh into the CVS server and
move both the files and their histories manually. Well, perhaps the
history can be retrieved and stored from/to the CVS server as well some
way without ssh access.

-- 
Vojtech Pavlik
SuSE Labs

Re: Input patch ...

[James S. <jsi...@tr...>]

> > For now. Later we can move stuff. 
> 
> Actually, I don't mind the USB stuff staying where it is. There are
> always two places for a driver to be: with other drivers for the bus it
> lives on (like USB), or with other drivers that have the same interface
> (like V4L or SCSI or Input ...).

Okay. Personally I hate the idea of drivers in bus directories but that is
my personal taste. 

> I don't think there is anything like 'cvs move'. And if you do 'mv; cvs
> remove; cvs add', you lose versions and the whole history of the file.

Yuck! 

Re: Input patch ...

[Vojtech P. <vo...@su...>]

On Sun, Jan 20, 2002 at 06:44:25AM -0800, James Simmons wrote:
> 
> > Not sure, I didn't check with Linus yet. However I talked with DJ about
> > this for a long time and this seemed the only reasonable way to do it.
> 
> Okay. Also long as cross directory dependency are not a issues. 
> 
> > Note I didn't move the USB and ADB stuff which is still in the
> > respective directories. I only moved stuff out of drivers/char, which is
> > not a good place for input drivers anyway.
> 
> For now. Later we can move stuff. 

Actually, I don't mind the USB stuff staying where it is. There are
always two places for a driver to be: with other drivers for the bus it
lives on (like USB), or with other drivers that have the same interface
(like V4L or SCSI or Input ...).

> > I like it better than one big input directory as well - now the problem
> > is how to sync CVS to this layout without losing history on all the
> > files.
> 
> I don't picture that being to hard. It is a matter of moving files around
> with cvs commands.

I don't think there is anything like 'cvs move'. And if you do 'mv; cvs
remove; cvs add', you lose versions and the whole history of the file.

-- 
Vojtech Pavlik
SuSE Labs

Re: Input patch ...

[James S. <jsi...@tr...>]

> Not sure, I didn't check with Linus yet. However I talked with DJ about
> this for a long time and this seemed the only reasonable way to do it.

Okay. Also long as cross directory dependency are not a issues. 

> Note I didn't move the USB and ADB stuff which is still in the
> respective directories. I only moved stuff out of drivers/char, which is
> not a good place for input drivers anyway.

For now. Later we can move stuff. 

> I like it better than one big input directory as well - now the problem
> is how to sync CVS to this layout without losing history on all the
> files.

I don't picture that being to hard. It is a matter of moving files around
with cvs commands.
 

Re: Input patch ...

[Vojtech P. <vo...@su...>]

On Sat, Jan 19, 2002 at 08:26:45PM -0800, James Simmons wrote:
> 
> > Hi!
> > 
> > I've created a input-only patch for 2.5.3-pre1. I've sent it to Dave
> > Jones, too ...
> > 
> > http://atrey.karlin.mff.cuni.cz/~vojtech/input9.diff.bz2
> 
> Nice :-) One thing I noticed. You did manage to move all the input devices
> to drivers/input. Now when you did you created a bunch of directories. How
> does Linus feel about this? Was the subdirectories apart of the compromise
> for linus to allow all the drivers to be moved to drivers/input. The most
> important thing is the issue of many drivers needing serio.o handled
> properly. The cross directory thing was a pain to deal with. I will give
> it a try. 

Not sure, I didn't check with Linus yet. However I talked with DJ about
this for a long time and this seemed the only reasonable way to do it.

Note I didn't move the USB and ADB stuff which is still in the
respective directories. I only moved stuff out of drivers/char, which is
not a good place for input drivers anyway.

I like it better than one big input directory as well - now the problem
is how to sync CVS to this layout without losing history on all the
files.

> P.S 
>    Some of the stuff was already synced to DJ tree :-) 

I noticed only after I sent it out. I'll have to go through it again and
check what is different.

-- 
Vojtech Pavlik
SuSE Labs

Synced to 2.5.2

[James S. <jsi...@tr...>]

Hi folks!!

   Our tree has been synced to 2.5.2. Yeah!! Hopefully in the next few
kernel versions our tree will less to sync to linus's tree :-)

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: Input patch ...

[James S. <jsi...@tr...>]

> Hi!
> 
> I've created a input-only patch for 2.5.3-pre1. I've sent it to Dave
> Jones, too ...
> 
> http://atrey.karlin.mff.cuni.cz/~vojtech/input9.diff.bz2

Nice :-) One thing I noticed. You did manage to move all the input devices
to drivers/input. Now when you did you created a bunch of directories. How
does Linus feel about this? Was the subdirectories apart of the compromise
for linus to allow all the drivers to be moved to drivers/input. The most
important thing is the issue of many drivers needing serio.o handled
properly. The cross directory thing was a pain to deal with. I will give
it a try. 

P.S 
   Some of the stuff was already synced to DJ tree :-) 

Input patch ...

[Vojtech P. <vo...@su...>]

Hi!

I've created a input-only patch for 2.5.3-pre1. I've sent it to Dave
Jones, too ...

http://atrey.karlin.mff.cuni.cz/~vojtech/input9.diff.bz2

-- 
Vojtech Pavlik
SuSE Labs

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

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

Quoting Rodrigo Damazio <cu...@uo...>:
>         Okay, today I looked deeper into the specs, and I found out it's 
> *partially* compliant...almost everything works according to the PID 
> specs, with a few exceptions..02(set envelope) has 7 bytes after it 
> instead of 6...06(Set ramp) has 3 bytes after it instead of 4...is this 
> the I-Force protocol?? I'm attaching some commented dumps to this message...

No, this is OK data. The joystick uses the "Device managed" sceme for
memory management. Read sections 5.11 and 9 of the PID spec and 
you'll see.

Set envelope:
	Effect block index	8
	Attack level		8
	Fade level		8
	Attack time		16
	Fade time		16
Set Ramp:
	Effect block index	8 
	start ramp		8
	end ramp		8

>         I'm sending a bzip2-ed copy here...if you want more dumps please 
> let me know(I didn't save most of my tests, I just looked at them on the 
> screen and guessed the meaning of bytes by changing parameters in 
> Immersion Studio...

Thanks a lot for this data! As I said,it's really refreshing seeing 
this stuff "from the other side". 

/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...

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

Johann Deneux wrote:

>On Sat, 19 Jan 2002, Rodrigo Damazio wrote:
>
>>Bj|rn Augustsson wrote:
>>
>>>Quoting Rodrigo Damazio <cu...@uo...>:
>>>
>>[...]
>>        Regarding the HID-specific stuff which isn't supported through=20
>>the event API, such as binding physical units, how about using a=20
>>"/dev/usb/hidsomething" device which could control this?? I guess this=20
>>is more generic than creating it on the "jsx" device because it applies=
=20
>>to many kinds of HIDs, not just joysticks...
>>
>
>The event API is not fixed, as far as I know. It would be better to use
>this one. Indeed, we do not know for sure this is hid specific.=20
>
>>>>I don't know how to interpret some of the hex=20
>>>>data...I've realized some things, for example a phase that starts wit=
h=20
>>>>01 is to report buttons and axes, "02 32 00" is when you hold the=20
>>>>stick(there's a little sensor), "02 36 00" is when you release it, an=
d=20
>>>>so on...
>>>>
>
>Funny, this really looks like the I-Force protocol. May I have a copy of
>your dumps ? According to Immersion, Microsoft uses its own software and
>drivers, which Immersion knows nothing about. But maybe they actually us=
e
>the iforce protocol. I don't know. On the other hand, I notice that the
>pid spec does not differe much from the iforce one.
>
        Okay, today I looked deeper into the specs, and I found out it's=20
*partially* compliant...almost everything works according to the PID=20
specs, with a few exceptions..02(set envelope) has 7 bytes after it=20
instead of 6...06(Set ramp) has 3 bytes after it instead of 4...is this=20
the I-Force protocol?? I'm attaching some commented dumps to this message=
...

>>>Can you send me the dumps you have? That could really help me understa=
nd
>>>some problems I'm having. I started from the other direction, from the=
=20
>>>spec down, instead of from the wires up.
>>>
>>        I have looked at the specs too, but at first sight they didn't=20
>>help much, mostly because I had never looked at USB in a low level...bu=
t=20
>>I'll look at them better tonight...does this joystick follow those spec=
s=20
>>then? Or do we really have to guess how it works?
>>        I'll send you some dumps by e-mail(so as not to clutter up the=20
>>mailing list)...do have Immersion Studio?? If not you should get it,=20
>>
>
>Well, if you compress them, they should not be that big, should they ? A=
t
>least, please also send a copy to me.
>
        I'm sending a bzip2-ed copy here...if you want more dumps please=20
let me know(I didn't save most of my tests, I just looked at them on the=20
screen and guessed the meaning of bytes by changing parameters in=20
Immersion Studio...

Rodrigo

--=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...

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

On Sat, 19 Jan 2002, Rodrigo Damazio wrote:

> Bj|rn Augustsson wrote:
> 
> >Quoting Rodrigo Damazio <cu...@uo...>:
> [...]
>         Regarding the HID-specific stuff which isn't supported through 
> the event API, such as binding physical units, how about using a 
> "/dev/usb/hidsomething" device which could control this?? I guess this 
> is more generic than creating it on the "jsx" device because it applies 
> to many kinds of HIDs, not just joysticks...

The event API is not fixed, as far as I know. It would be better to use
this one. Indeed, we do not know for sure this is hid specific. 

> 
> >>I don't know how to interpret some of the hex 
> >>data...I've realized some things, for example a phase that starts with 
> >>01 is to report buttons and axes, "02 32 00" is when you hold the 
> >>stick(there's a little sensor), "02 36 00" is when you release it, and 
> >>so on...
> >>
> >

Funny, this really looks like the I-Force protocol. May I have a copy of
your dumps ? According to Immersion, Microsoft uses its own software and
drivers, which Immersion knows nothing about. But maybe they actually use
the iforce protocol. I don't know. On the other hand, I notice that the
pid spec does not differe much from the iforce one.

> >Can you send me the dumps you have? That could really help me understand
> >some problems I'm having. I started from the other direction, from the 
> >spec down, instead of from the wires up.
> >
>         I have looked at the specs too, but at first sight they didn't 
> help much, mostly because I had never looked at USB in a low level...but 
> I'll look at them better tonight...does this joystick follow those specs 
> then? Or do we really have to guess how it works?
>         I'll send you some dumps by e-mail(so as not to clutter up the 
> mailing list)...do have Immersion Studio?? If not you should get it, 

Well, if you compress them, they should not be that big, should they ? At
least, please also send a copy to me.

> because my dumps are all done while using it(I set it to use the SFF2 
> through DirectInput)...then you can know what was happening during each 
> dump...
> 

-- 
Johann Deneux

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

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

Bj|rn Augustsson wrote:

>Quoting Rodrigo Damazio <cu...@uo...>:
>
>>    Hello...I just joined this list...I'm interested in helping develop=
=20
>>support for the Microsoft Sidewinder Force Feedback 2...I have that=20
>>joystick
>>
>
>So do I, and I've been working on supporting it for the last week.
>Have a look at the archives of this list and usb-devel.
>
       I've read it...
        Regarding the HID-specific stuff which isn't supported through=20
the event API, such as binding physical units, how about using a=20
"/dev/usb/hidsomething" device which could control this?? I guess this=20
is more generic than creating it on the "jsx" device because it applies=20
to many kinds of HIDs, not just joysticks...

>>I don't know how to interpret some of the hex=20
>>data...I've realized some things, for example a phase that starts with=20
>>01 is to report buttons and axes, "02 32 00" is when you hold the=20
>>stick(there's a little sensor), "02 36 00" is when you release it, and=20
>>so on...
>>
>
>Can you send me the dumps you have? That could really help me understand
>some problems I'm having. I started from the other direction, from the=20
>spec down, instead of from the wires up.
>
        I have looked at the specs too, but at first sight they didn't=20
help much, mostly because I had never looked at USB in a low level...but=20
I'll look at them better tonight...does this joystick follow those specs=20
then? Or do we really have to guess how it works?
        I'll send you some dumps by e-mail(so as not to clutter up the=20
mailing list)...do have Immersion Studio?? If not you should get it,=20
because my dumps are all done while using it(I set it to use the SFF2=20
through DirectInput)...then you can know what was happening during each=20
dump...

>>    Anyway, I'm willing to help implement this...
>>
>
>Great! I hope to have some patches by tomorrow.
>
        Cool....

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Computing Engineering       *
* Polytechnic School          *
* USP - S=E3o Paulo             *
*******************************

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

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

Quoting Rodrigo Damazio <cu...@uo...>:
>     Hello...I just joined this list...I'm interested in helping develop 
> support for the Microsoft Sidewinder Force Feedback 2...I have that 
> joystick

So do I, and I've been working on supporting it for the last week.
Have a look at the archives of this list and usb-devel.

> I don't know how to interpret some of the hex 
> data...I've realized some things, for example a phase that starts with 
> 01 is to report buttons and axes, "02 32 00" is when you hold the 
> stick(there's a little sensor), "02 36 00" is when you release it, and 
> so on...

Can you send me the dumps you have? That could really help me understand
some problems I'm having. I started from the other direction, from the 
spec down, instead of from the wires up.

>     On the bottom of the joystick it says it uses I-Force licensed to 
> Microsoft from Immersion Corp....is it just basic I-Force? If so how do 
> we get it to work in linux?? Has anyone worked on this?

Nope, it's a HID/PID device. There's specs for that on www.usb.org, and
that will help you understand your dumps.

>     Anyway, I'm willing to help implement this...

Great! I hope to have some patches by tomorrow.

/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

hello...and MS-FF2...

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

    Hello...I just joined this list...I'm interested in helping develop=20
support for the Microsoft Sidewinder Force Feedback 2...I have that=20
joystick and have a working copy of Bus Hound(I cracked the demo version=20
to log past 4Kb), but I don't know how to interpret some of the hex=20
data...I've realized some things, for example a phase that starts with=20
01 is to report buttons and axes, "02 32 00" is when you hold the=20
stick(there's a little sensor), "02 36 00" is when you release it, and=20
so on...
    On the bottom of the joystick it says it uses I-Force licensed to=20
Microsoft from Immersion Corp....is it just basic I-Force? If so how do=20
we get it to work in linux?? Has anyone worked on this?
    Anyway, I'm willing to help implement this...

Rodrigo

--=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: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

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

Quoting Vojtech Pavlik <vo...@su...>:
> On Wed, Jan 16, 2002 at 05:38:56PM +0100, Bj|rn Augustsson wrote:
> > 
> > OK, longish status update time:
> > 
> > It's not really a button, but it could be useful to a game anyway. You
> > could bind pause to it for example, or something. Do I report it to the
> > API as a button, or do I add a new bit about this somewhere?
> 
> It's already defined: BTN_DEAD (The 'deadman' switch).

Aha! Good to know. (I thought it meant something like a dead key on a
keyboard...)
Good, that solves that.

> > Also, HID devices (can) have physical units bound to them, as in "This
> > axis measues rotation, +- 30 degrees, 8bit resolution." There is no way
> > for an app to get this information thru the input API, and it should
> > probably be added at some point. It's not critical for game controllers,
> > but other apps might want that information.
> 
> Yes, we may later add some IOCTLs to report and structures to hold that
> information.

OK.
 
> > (But as I said, I'll have to look at the current hid code, as I've been
> > working against what's in 2.4.18pre3. Maybe things have changed.)
> 
> There is a lot of differences, namely in the control URB handling.

OK, I got the new code from CVS (Actually, that crashed when init
started on my box, so I went with Johanns input-only patch against
2.4.17 instead) and merged with it.

It doesn't help. I have a few questions:

The joystick has an interrupt output endpoint. The HID spec says an
output pipe is optional, and that if one exists, output reports are to
be sent over it. I can't see any initialization of output pipes in the
HID code though, nor data structures in the hid_device struct.

Question #1: Are there any HID devices with output interrupt pipes that
             work with this code?

If I understand this correctly I'll need another urb and some more
stuff. I'll also rename the input URB to add some clarity there.

Second problem. When hid_probe() gets called, often the input pipe is
aleady stalled. (And if it isn't, it stalls after the first call to
hid_submit_report.) Attemting to get any input reports results in 
"hid-core.c: ctrl urb status -32 received" messages.

Question #2: Under what circumstances do pipes stall? I've read the
             relevant parts of the USB spec, but I'm not sure about
             the non-error stalls.
Question #3: How can I clear the stall? Or rather what actually happens
             when I do? I tried using usb_clear_halt() from 
             hid_init_reports() and that wedged the kernel.
             I'm guessing I can't do that when TASK_UNINTERRUPTIBLE?

Oh yeah, and

Question #4: Do I send patches here or to usb-devel or where? I'm
             confused...

Thanks,

/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: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

[Vojtech P. <vo...@su...>]

On Wed, Jan 16, 2002 at 08:16:50PM +0100, Johann Deneux wrote:
> On Wed, 16 Jan 2002, Bj|rn Augustsson wrote:
> 
> > > How far have you got ? Have you managed to make your joystick move yet ?
> > > Please also have a look at the input/event API. It would be nice if it was
> > > the one used to download effects to the device.
> > 
> > No, I haven't, but I'm close. (I think!)
> 
> Great !
> 
> > 
> > OK, longish status update time:
> > 
> > [...]
> > 
> > There's a few policy type things to consider. There's an Usage called
> > PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if
> > you hold the joystick or not (and if you let go, it turns the forces
> > off). Since the existing HID-input "parser" reports every one-bit input
> > usage as a button, this gets reported that way (except it's inverted, if
> > you let go of the stick, it goes 0 -> 1). 
> > 
> > It's not really a button, but it could be useful to a game anyway. You
> > could bind pause to it for example, or something. Do I report it to the
> > API as a button, or do I add a new bit about this somewhere?
> 
> I guess by the name BTN_DEAD (0x12f) could be used for that, but as I
> said, that's only a guess.

I-force has this as well (at least the WingMan Force has it).

-- 
Vojtech Pavlik
SuSE Labs

Re: [linux-usb-devel] [PATCH] Add some PID stuff and fix HID debug prettyprinting

[Vojtech P. <vo...@su...>]

On Wed, Jan 16, 2002 at 05:38:56PM +0100, Bj|rn Augustsson wrote:
> Quoting Johann Deneux <jo...@Do...>:
> > [cc to the linuxconsole list]
> > (Bj|rn is currently working on support for force feedback for microsoft
> > joysticks, and sent a patch to the usb-devel ML concerning the debugging
> > system of the hid driver)
> > 
> > On Wed, 16 Jan 2002, Bj|rn Augustsson wrote:
> > 
> > > Nope, 1.8 is what I've got here.
> > > 
> > > I'll certainly look into that. Thanks for the heads up!
> > > 
> > > I have quite a lot more written, but there's still some bugs and stuff
> > > that I haven't implemented yet, so I split this part out.
> > 
> > How far have you got ? Have you managed to make your joystick move yet ?
> > Please also have a look at the input/event API. It would be nice if it was
> > the one used to download effects to the device.
> 
> No, I haven't, but I'm close. (I think!)
> 
> OK, longish status update time:
> 
> I am using the event API. The joystick now reports almost all of it's 
> features to the event stuff, but actually writing stuff to the it 
> doesn't work yet.  I haven't started on uploading effects, but I thought
> I had the "set device gain" thing working last night, but I ran into 
> problems where this happens:
> 
> Jan 16 03:49:06 localhost kernel: Setting device gain to 127, span = 255
> Jan 16 03:49:06 localhost kernel: hid-debug: input PhysicalInterfaceDevice.Device_Gain = 127
> Jan 16 03:49:06 localhost kernel: hid-core.c: ctrl urb status -32 received
> 
> -32 is EPIPE, and I'll have to look into why that happens a bit later today.
> 
> The joystick actually seems to be a proper PID device, so that's what
> I'm aiming for, and trying not to hard-code anything MS-FF2-specific in
> there.
> 
> There's a few policy type things to consider. There's an Usage called
> PhysicalInterfaceDevice.Safety_Switch, which is a switch that notices if
> you hold the joystick or not (and if you let go, it turns the forces
> off). Since the existing HID-input "parser" reports every one-bit input
> usage as a button, this gets reported that way (except it's inverted, if
> you let go of the stick, it goes 0 -> 1). 
> 
> It's not really a button, but it could be useful to a game anyway. You
> could bind pause to it for example, or something. Do I report it to the
> API as a button, or do I add a new bit about this somewhere?

It's already defined: BTN_DEAD (The 'deadman' switch).

> Also, HID devices (can) have physical units bound to them, as in "This
> axis measues rotation, +- 30 degrees, 8bit resolution." There is no way
> for an app to get this information thru the input API, and it should
> probably be added at some point. It's not critical for game controllers,
> but other apps might want that information.

Yes, we may later add some IOCTLs to report and structures to hold that
information.

> (But as I said, I'll have to look at the current hid code, as I've been
> working against what's in 2.4.18pre3. Maybe things have changed.)

There is a lot of differences, namely in the control URB handling.

-- 
Vojtech Pavlik
SuSE Labs