USB camera compatibility question
freebsd-misuser at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Mon Dec 15 13:32:38 PST 2003
[Drop my (IPv6-only) address if replying; I'll catch the archives]
> On Fri, Nov 21, 2003 at 01:43:13AM +0100, Barry Bouwsma wrote:
> > Yes, because so far the images snarfed with my hacks are okay for the
> > first 4096 bytes, thereafter failing to match the perfect images I can
> > download with the `mtools' utilities from a printer cum card slot.
> > There seem to be chunks of NULs present regularly throughout the file.
> The "junk at byte 4097" symptom matches what I get with a Sony F707
> on -current using the OHCI usb controller. I believe it's a bug in
> the ohci driver but don't know more than that.
You may well be right. And either it fixed itself, or I've been `cmp'ing
against a mis-labelled ``bad/good'' reference file.
What I did in my frustration was to throw hardware around and swap in a
UHCI+EHCI controller card I had, also to verify my memory of my EHCI
performance. At that point, I saw no difference between the saved `good'
image and that downloaded directly from the camera. Other issues with
that driver caused me to revert to the OHCI+EHCI controller (also that
it has firewire that I need too).
Then it worked Just Right, and has never given me problems since, though
with relative little use.
This suddenly-working-after-trying-different-uhci-controller phenomenon
also sounds like what I saw when trying to use libusb to talk to the
printer I have, where I had no total success, until I swapped controller
cards, then it suddenly started working, and continued after switching
back to the ohci card.
Don't ask me to understand this. Also, for a USB1 device and an msdos
type filesystem, I see what I am led to understand is reasonable transfer
rates of more than half the theoretical maximum speed, about which I shall
not complain -- certainly beats the `mtools' access to the printer that
I had had to use previously. I have vague memories of the uhci card
giving transfer rates about ten times slower, but I could be confused
with all the hardware juggling going on and trying to keep track of all
the differences, expected and unexpected.
Others are welcome to comment on these observations. I also may have
used different usb-related kernel module sources, as I've been juggling
more of those around based on -stable and -current of various vintages.
Sheesh, I need to clean up my system -- I thought I was running the
code based on -current since the last boot, but it turns out it's
September-RELENG_4 ... Now I can't even remember what I was using when
I saw the 4k problem, furrfu.
More information about the freebsd-hardware