Tough trick when some intervals come in microframes,
so they're less than a millisecond.
How would someone encode a 125 microsecond polling
interval in your preferred world, then?
My second option, FWIW, was to embed the conversion
in usb_fill_int_urb(), which is already in usbcore. USB 1.1
driv
Thanks to you guys for taking time to reply my question.
I just finished the test with kernel 2.5.8.
I think as both of you have said , the usb.h has been updated with the definition
#define USB_CLASS_CDC_DATA 0x0a
Sorry that I should have done more background works.
The /proc/bus/usb/devic
> So the question: Given this patch and an equivalent one that
> pushes the "which bInterval encoding" logic into
> and usb_fill_int_urb(), which should go into 2.5? 2.4?
I'd like to see it done in miliseconds with a conversion function
in usb core.
Regards
Oliver
_
Hi,
This patch applies against 2.5.8 (and, with minor fuzz, against
2.5.8 plus the ehci-0411.patch you resubmitted).
It fixes problems with interrupt transfers, which I think that
nobody else has run into (or I'd surely have heard of it :).
Looks like not many folk are using USB 2.0 hubs yet.
Attached is a patch against the 2.5.8 hub driver, making it
provide the correct polling interval. Something like this
needs to go into 2.5 (and also 2.4), and this works fine.
BUT: I'm wondering if maybe such logic shouldn't be put into
usb_fill_int_urb() instead, to reduce the number of mistak
> I'm 90% certain that they use jpeg-lite with this chipset. Here's some
> documentation on the compression:
>
>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ft00&s1=divio.ASNM.&OS=AN/divio&RS=AN/divio
Great link. I've n
Hello,
> Your driver should do like drivers/usb/usb.c (in this order):
>
> #ifdef CONFIG_USB_DEBUG
> #define DEBUG
> #else
> #undef DEBUG
> #endif
> #include
using DEBUG is *not* a good idea!
I have to change
#define DEBUG
into
+define DEBUG 1
because there are some kernel head
> Fortunately, it looks like all of the claims involve compression and not
> decompression, so you can probably implement a decompressor without
> being sued (you should ask a patent attorney to be sure, though).
Or live outside the United States of America and include a geographical
restrictio
