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