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