On Sat, 14 Nov 2009, Oliver Neukum wrote:
Am Samstag, 14. November 2009 18:47:04 schrieb Alan Stern:
The other is that the camera really is sending empty data packets.
Then one has to figure out why the camera behaves differently in the
two environments; presumably only the manufacturers have enough
information to make that determination.
Indeed. Therefore this route may be an unproductive path.
I'd suggest that you reset the camera when you get a lot
of empty packets. Maybe that helps.
Regards
Oliver
Reset the camera? By what means would you have in mind? Close the app and
re-plug the camera? It has been tried, of course.
Also, there is even so the more basic question that if this is the
particular manner of the failure, then why does the failure occur on 3
UHCI-based machines and it does not occur on 3 OHCI-based machines? Not to
mention that the camera worked on a Windows machine in the first place, so
that it was possible to make sniff logs in order to see how to write the
initialization steps. And the Windows machines around here are three: An
ancient Gateway Pentium3 and Intel motherboard, with Win98 on one
partition, a home-built Athlon Thunderbird sitting on an Acer VIA-based
board, with one Win2k partition on it, and a fairly recent Dell laptop
running WinXP, borrowed from the workplace to run sniffs on. I don't
remember on which of these I installed the driver in order to do the sniff
logs. I would have to fire them up one by one until I found it. But it
should be pretty clear from the descriptions that these are all UHCI-based
machines. And I do not recall having had any trouble with running the
camera on Windows, once I got the right driver files which will run a CIF
type 1 camera.
So what I see is evidence which is pointing almost completely in one
direction.
Within the Linux driver for the camera, it seems to me that the only
possible direction that suspicions could point might relate to the
detection scheme. This is obviously the kind of thing which could cause
problems, because one is in unknown territory and is guessing. As I said,
none of the OEM drivers for these cameras are doing any kind of detection
at all. They just wade in and initialize the camera. And if you hook up an
0x093a:0x010e camera in Windows and there is a mis-match of the driver
with the camera's type, the camera will be "detected" only by the USB ID
and it just won't work. More graphically put, a Windows user who has two
of these cameras, one of each type, and wants to use both of them, is
totally screwed and will not even be able to discover the reason why it is
happening. And any attempt to re-install the driver from the other CD will
cause the second camera to work, but then the first one will fail. Rinse,
lather, repeat. So, as I said, I had to hunt for something which would
detect and classify different cameras with the same USB ID. The need to do
that does not seem to have occurred to anyone writing the Windows drivers.
The proof of this statement lies in the fact that their drivers do not do
anything which will serve up such information.
Well, it feels good to bash Windows hardware drivers. I could not resist.
And I hope you enjoyed reading about that stupidity, too. But back to the
main point. It is apparent that the Windows driver appropriate for an
0x093a:0x010e camera of type 1 will run the camera on a UHCI-based Windows
system. Otherwise I could not have gotten the USB snoop logs to write this
driver in the first place.
But, wait a minute. Could it be that the detection scheme is killing the
data packets? Maybe. But, again, this is happening only on UHCI hardware.
And also one might assume that I tried lots of things. For example, is it
possible to bypass the detection scheme completely by writing code which
is "hard wired" to initialize only an mr97310a CIF type 1 camera?
Certainly it is. Have I done that and tested said code? Certainly, I have.
Did it make the camera to work on an OHCI machine, as one ought to expect?
Yes. Did it make the camera to work on a UHCI machine? No.
Another angle, which might provide another clue:
If you look at the code from the tree of Hans de Goede and from
2.6.32-rc6, you will notice that the file mr97310a.c is different. The
main reason for that which is relevant in the present context is, the
detection scheme is different. The code in 2.6.32-rc6 is older. It uses a
detection scheme which has since been discarded. Why was that detection
scheme discarded? Because it was screwing up. It was failing to detect the
camera's type properly. Where was it screwing up? On UHCI hardware, after
being developed on OHCI hardware and working pretty well there, though the
new detection scheme does work better on OHCI as well as on UHCI hardware.
The older detection scheme, just like the new one, relied upon the answer
returned from a query to the camera. But it was a different query from
what is used now. On UHCI hardware the results returned for that query
became totally chaotic, and that is the reason why the older detection
scheme was scrapped.
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
