[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    Re: Re[2]: Re[2]: [linux-usb-devel] Questions about HID and USB Monitor Control
From:       "..tom" <tom () wingmanteam ! com>
Date:       2000-06-30 17:48:31
[Download RAW message or body]

[snip]

> >At one time we didn't have interrupt-OUT support
> >(before URBs), but with URBs we can do interrupt-OUT
> >transfers, at least theoretically.  Has anyone
> >done any interrupt-OUT transfers?
>
> >~Randy
>
> Hi Randy,
>
> Tom made a Linux based demonstration box for some of our upcomming Force
> feedback gaming peripherals (watch for it in stores around Christmas! And
> while you're there, check out the new devices ;-)). I know that he had to
> patch a few things to get it to work right.

I *had* to patch a few things is the right word. Thanks to going through
that experience and using some part of the linux-usb subsystem that haven't
been used very much (int out), I was able to submit a few
patches/suggestions to the list. Now, everything should work out of the box.
(I have fallen behind, though, and still stuck in my 2.3.99-pre9 world. That
works for me, and at the moment I have tons of other things to do - you know
that David ;-)

> I also know that he wrote some
> kind of dedicated driver for it: not something you would like to see in
the
> kernel tree!

And looking at the hackedness of this driver, it's definitely *not*
something that you would want in the kernel tree anyway!
I decided to go this route because I had to get it done really quickly, and
it is a very "embedded-style" application. I needed to write the driver
which does some special (very non-generic ;-) things, an application which
connects to the driver, and provide the content - all in a very short time.
I couldn't be bothered messing around with other code apart from the host
controller driver.

One thing I had looked at very briefly but don't remember what I found: For
FF devices, you need to be able to write to them. Some writes occur
spontaneously, some of them have more of a bursting nature. My driver does
this in a very simple manner; handling the continuation by using the
interrupt out completion. For the cases where I have to wait, I just send a
number of commands without effect to the firmware - this gives me a nice
timing. (and I still set bInterval to 0 to stop the loop - as discussed a
while ago on the list)

What I didn't seem to find was a way to do output with HID, and do it in a
"streaming" way, where you'd write (blocking), it returns, you immediately
write again. Sort of like extending the completion routine to the app in
user mode. It's also not practical to transfer down a chunk of transmissions
to the driver, as you don't necessarily know beforehand what there is going
to be to transmitted. Contents might change on a user interaction basis, or
even on something beyond your user mode solution (for example a game which
decides to change a force *right now*).

> I'm sure that as soon as he gets in today he will give you more details...

I hope this was not too confusing.
Bottom line:
Interrupt OUT works ;-)

cheers,
..tom


_______________________________________________
linux-usb-devel mailing list
linux-usb-devel@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/linux-usb-devel

[prev in list] [next in list] [prev in thread] [next in thread]