I think a major problem with trying to use interrupt URBs from devio is
interrupt URBs (last time I checked) resubmit themselves.
Your patch uses usb_start_wait_urb() which (as far as I can tell)
assumes the URB will not resubmit, and then bad things will happen after the URB
is freed (and still in progress).
The way that I was told to get interrupts is use bulk URBs. You can
submit a bulk URB on an interrupt pipe from userspace (that's actually the only
way currently). That works fine except for 2 problems:
1)during light bus load, the polling period is much faster than expected.
This can cause cheap microcontrollers (that might do software NAKing)
to spend 100% of their time NAKing and effectively lock the device;
I have a Logitech mouse with exactly this problem.
2)during very heavy bus load, the polling period may be slower than expected.
This can lead to loss of data on the device side.
Am I incorrect that interrupt URBs will resubmit themselves?
On Sat, 31 Mar 2001, Adam J. Richter wrote:
> I guess it has been a few releases since I last thought
>about the /proc/bus/usb facilities, and it looks like
>linux-2.4.3/drivers/usb/devio.c contains some handy new ioctl's,
>like USBDEVFS_{SUBMIT,DISCARD,REAP}URB. It looks like it is now
>possible to write a user level USB driver that can read USB interrupt
>pipes using these ioctl's. This has been a roadblock to user level
>Human Interface Device drivers.
>
> I noticed this as I was writing a patch to implement a
>USBDEVFS_INTERRUPT ioctl for doing transfers from interrupt pipes
>(like USBDEVFS_BULK). I have attached the patch, in case anybody is
>curios (it compiles and seems harmless, but I don't know if it works).
>If this code is unnecessary, then there is no need to bloat the kernel
>with it. However, I figure that, in case it is needed, I will included
>for reference with this email.
>
> Anyhow, if someone could clarify the situation, that would
>be very helpful to me.
>
> I am currently interested in the USB user level drivers because
>I think it may be better to move all Human Input Device USB drivers
>to user land. The HID "report" descriptors are fairly complex, so
>they do not lend themselves easily to the design of a MODULE_DEVICE_TABLE
>structure for use in selecting kernel modules, plus they are complex
>enough so that you may be a fairly complex task for a driver to figure
>out what parts of the HID device it can control. The advantages of
>this would be that it would be easier to provide more elaborate support
>for different Human Input Devices (and other things that have nothing
>to do with human input but use the HID class, like uninterruptible
>power supplies).
>
> Since HID devices are pretty low bandwidth, I do not think there
>is a performance reason for including them in the kernel, although I
>would be more reassured in this feeling if I had some numbers on what kind
>of latency is needed for joysticks and the like in things like fast video
>games.
>
>
--
Dan Streetman
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
