On Sun, 15 Nov 2009, Hans de Goede wrote:
Hi,
On 11/15/2009 08:07 PM, Alan Stern wrote:
On Sun, 15 Nov 2009, Theodore Kilgore wrote:
That doesn't explain why the old code worked with OHCI but not UHCI.
We may never know the answer.
No, it does not explain. But I am somehow less curious about that than I
was 12 hours ago. What about you? Feel that way, too?
No, I am just as curious as before. Maybe more so, knowing it has
become even less likely that I will ever learn the answer. It's
frustrating.
One possible explanation: UHCI always carries out its periodic
transfers at the beginning of each frame. OHCI doesn't, or least, it
doesn't have to. Now there's no good reason why this should make any
difference to the cameras, but perhaps it does anyway.
FWIW, these chips are found in dirt dirt cheap camera's think 5 euros
including
keychain + keychain ledlight + bateries + usb cable, and that for a still cam
camera, which can also be used in streaming mode.
Very true, but think how the mighty dollar has fallen. Five euros? Ten
dollars? Ouch.
We've discovered some other interestings things during driver development
too,
like the camera being so cheaply made it has so little internal buffering,
it can run out of bandwidth, when a single row of the image does not compress
well.
Hans,
About this one, I will reserve some skepticism. We know about the symptom.
But are we sure of the cause?
Precisely where and how does it get decided that a 352x288 image gets
allocated a certain amount of space for data? It is obviously true that if
the data size overruns whatever allocation of the space there was, we get
those short frames, chopped off at the bottom. It is equally true that any
scheme of differential Huffman encoding can be bollixed by giving it a
difficult set of data, such as the infamous half-open venetian blinds with
sunlight outside, and the size of the data after "compression" suddenly
burgeons to some amount larger than one thinks it should be. But how do we
know that the max data size for the camera to use can not be adjusted to
accommodate this situation? Perhaps it can. Actually, we don't know.
Theodore Kilgore
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
