confirm 106691
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
I am developing a device which outputs absolute X and Y position information
like a graphics tablet. I would like to be able to use this device just
like a mouse from within the X windows environment. I have been able to get
it working with the Windows HID driver by modifying a basic mouse
When compiling this driver with WRITE_DEBUG defined (for extra debug output),
gcc outputs warnings for three similar printf statements.
The specifier in each printf statement is not totally correct.
This patch removes these warnings.
Patch attached and also available at
When compiling this driver with WRITE_DEBUG defined (for extra debug output),
gcc outputs warnings for three similar printf statements.
The specifier in each printf statement is not totally correct.
This patch removes these warnings.
Patch attached and also available at
)On Tue, 30 Sep 2003, Moe Wibble wrote:
hello,
i have a problem with a hdd in an external usb-ide-case.
the drive works fine when plugged into one of the onboard usb-ports (usb1.0).
when i try to use it with my pci usb 2.0 controller it behaves very strange.
it works for about a minute
Al Borchers wrote:
Greg, David --
Here is a USB gadget serial driver. It talks with Greg's
generic USB serial driver on the host side, and it looks
like a serial port on the gadget side.
Cool, I'm glad to see this! I'll take a look at it; though
likely Greg will have more insights from the
Moe Wibble wrote:
1. boot the machine with the drive plugged into the usb 2.0 controller
(it is properly recognized and works fine at first...)
2. mount the drive
3. copy a large file to the drive (which reproducably fails after about ~450M)
4. curse
can anybody make sense of this?
i have seen
On Wed, Oct 01, 2003 at 02:42:33AM -0500, Al Borchers wrote:
I have not yet merged it into the 2.4 gadget sources, nor
ported it to 2.6. The very first data sent to the host
after the host has just opened the port is lost. There
is no flow control. The gadget side is meant to support
David --
Question: why do you have your own versions of the
wait_event() macros? (From linux/sched.h on 2.4,
or linux/wait.h on 2.6 kernels.)
The macros are slighty different from linux/sched.h
(that is where I got them initially). The difference
is that these macros expect that the caller
Greg --
Looks nice (becides your tab setting is a bit wrong...)
Thanks. I will convert to 8 space tabs.
Mind if I port it to 2.6 and add it to my linuxusb.bkbits.net/usb-2.5
kernel tree so I can play around with it?
Please do. I was planning on porting to 2.6 myself (I need the
I'm writing a USB driver for a custom interface we are
developing for an astronomical camera. We are using the
Cypress FX2 USB chip. Most aspects of the system are working
fine but so far the throughput is not as high as required
to support the data rate. I have noted two limitations on
INTERRUPT
Hi,
Question: why do you have your own versions of the
wait_event() macros? (From linux/sched.h on 2.4,
or linux/wait.h on 2.6 kernels.)
The macros are slighty different from linux/sched.h
(that is where I got them initially). ..
This is a standard condition variable kind of synchronization
On Wed, 1 Oct 2003, Richard Stover wrote:
I'm writing a USB driver for a custom interface we are
developing for an astronomical camera. We are using the
Cypress FX2 USB chip. Most aspects of the system are working
fine but so far the throughput is not as high as required
to support the data
I'm going to try bulk transfers this afternoon.
I also just tried doing high bandwidth interrupt
transfers. I thought that perhaps I could get
three transfers per microframe.
In /proc/bus/usb/devices I see this for my interrupt
endpoint:
E: Ad=82(I) Atr=03(Int.) MxPS=3066 Ivl=125us
Note that
Richard Stover wrote:
I have noted two limitations on
INTERRUPT endpoints. First, the maximum packet size seems
to be 1023 bytes instead of 1024 bytes. This is a minor
problem, but it does seem to violate the USB 2.0 specs.
I get a urb status in my callback of -75 when I try 1024 bytes.
That
Richard Stover wrote:
I'm going to try bulk transfers this afternoon.
I also just tried doing high bandwidth interrupt
transfers. I thought that perhaps I could get
three transfers per microframe.
Not yet supported ...
In /proc/bus/usb/devices I see this for my interrupt
endpoint:
E: Ad=82(I)
I just tested bulk transactions. On the 3GHz P4 on which
I'm doing the development I can maintain one transaction
per microframe. Of course packet size is reduced to 512 bytes
from the (nominal) 1024 interrupt transactions packet size.
This gets me to 4Mbyte/s throughput. I really need 10Mbyte.
It
Hi David,
If I could get the one-microframe period to work with
interrupts that would get me very close to my original
goal of 10Mbyte throughput.
See the spec for wMaxPacketSize ... it makes more sense
in hex, since you're interpreting the high bandwidth
multiplier bitfield incorrectly.
Oh yes,
On Wed, Oct 01, 2003 at 09:58:24AM -0700, David Brownell wrote:
Moe Wibble wrote:
1. boot the machine with the drive plugged into the usb 2.0 controller
(it is properly recognized and works fine at first...)
2. mount the drive
3. copy a large file to the drive (which reproducably fails
19 matches
Mail list logo
