The he has to accept that some data will be “stuck” in the process of read (actually, in the HCD’s buffer).
OR, he COULD just hang a bunch of 512 byte packets out there… since his device isn’t transferring short blocks, those packets would be completely filled by a transfer, right?? Isn’t that what we’re talking about??
The he gets all the data that’s pending… (or his device works properly and he gets a short packet)… no?
Peter
OSR
Tim Roberts wrote:
“The device needs to be modified.” You make it sound so simple.
Haven’t you ever worked with a hardware team? Can’t you already
hear the response? “Well, it works on Linux. It’s a valid design
according to the spec. It’s a Windows problem, go make it work.”
Well, I have the luxury of not having to deal with hardware teams (or even customers) now, so, easy for me to say. However, I’ve been asked to do far worse (making an OID in my CDC ethernet driver that would issue CYCLE_PORT because the device would, in the words of the hardware guys, “get confused sometimes”).
Also, depends on what “spec” you’re referring to. If you mean the USB spec, well, refer to Hagen’s post. If you mean the spec that was shared between hong zhong and his hardware team, well, if the hardware guys say they are not going to terminate their transfers with a short packet, then he can only submit read URBs that are equal in size to the endpoint’s maximum packet size, as PeterGV suggests … then he’s guaranteed to hear every packet and get all his “dada”, but at what cost? I think we all know the answer…
Here’s my tale of two hardware teams faced with this same problem, one of them relatively smart, the other morons:
Back in the day, the Win2k version of usbser.sys would only issue PeterGV-style reads (that is, of the endpoint’s maximum size, 64 bytes for USB 1.1). It also had another critical flaw: if you sent it a zero-length packet, it would just hang forever and stop reading from the device (as far as I know this was never fixed).
So, both teams were faced with the situation where they needed to send exactly 64 bytes to the host. The smart team, knowing they couldn’t send 64 bytes + ZLP, but also knowing they needed to properly terminate their transfers, modified their code to send 63 bytes and then 1 byte. Done and done.
The moron team, however, just changed their code to just not send the ZLP at all. This worked fine, though, because Win2k usbser never read more than 64 bytes, so there was never any risk of a hung transfer.
Well, fast forward to the XP version of usbser.sys which issues 4K reads. Instantly, thousands of devices in the field immediately start failing in bizarre ways and pages like this[1] are born out of the utter confusion. Hacks are made where the Win2k usbser.sys is shipped for use on XP machines (renamed of course) because that’s the only flavor of the driver that will work. Customers complain that the throughput on the “hack” devices are terrible because tiny 64-byte reads are being issued, one at a time.
Then the hardware team ships another device with the ZLP added back in, but with the same PID. Now you have two different devices, indistinguishable by the OS, that can only work with one driver or the other.
I could go on, but the point is, it pays to follow the spec, early on… (duh.)
[1]
xxxxx@osr.com wrote:
The he has to accept that some data will be “stuck” in the process of read (actually, in the HCD’s buffer).
That seems to be the situation. I find that an unfortunate limitation.
I have been under the impression there was a way to tell the HCD “stop
the transfer on endpoint X and send me what you have already
collected.” As I said, that’s possible in Linux.
OR, he COULD just hang a bunch of 512 byte packets out there… since his device isn’t transferring short blocks, those packets would be completely filled by a transfer, right?? Isn’t that what we’re talking about??
So, you’re proposing that his driver could submit a boatload of 512-byte
requests? That would solve the problem, but the overhead is so
incredibly high that it is impractical. For a 2M transfer, you’re
talking about 4,000 IRPs, and they will be completed at a rate of 120
per millisecond. For one frame, you could do it, but if you’re
streaming, it can’t be done. You can’t sustain it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
wrote in message news:xxxxx@ntdev…
> I’ve been asked to do far worse (making an OID in my CDC ethernet driver
> that would issue CYCLE_PORT because the device would, in the words of the
> hardware guys, “get confused sometimes”).
>
Won’t cycling the port kick the device off the bus and cause surprise
removal?
> I could go on, but the point is, it pays to follow the spec, early on…
> (duh.)
Any hardware problem fixable by a driver is always
seen by the management & marketing as a driver bug been fixed,
and driver devs get blamed for having the bug, in the first place.
Been there…
–pa
Pavel A wrote:
Won’t cycling the port kick the device off the bus
and cause surprise removal?
Yes, this was the whole point. Re-enumeration would “un-confuse” the device.
Yes. After all, he’s talking about hardware that is, by definition, broken. It would take a very small firmware change to fix this behavior.
In tis case, I beleive he’s talking about a STILL camera. So he’s not streaming this data (er, well, at least I don’t THINK he is!)…
TOTALLY right. Shit flows down hill, and it’s us driver devs who are perennially at the bottom of that hill looking up. OS problem? We get to work around it. Bug in the silicon? We get to compensate for it. Firmware deficiency? Fix it up. And when these things don’t work, it’s ALWAYS our fault.
It’s just our fate, fellas… But, oh, it CAN be amusing at the same time, don’t you think?
Peter
OSR
to Peter Viscarola :
it is a STILL camera,and the driver is based on wdm’s the bulkusb or wdf’s usbsamp
zhonghong200@163.com wrote:
to Peter Viscarola :
it is a STILL camera,and the driver is based on wdm’s the bulkusb or wdf’s usbsamp
As far as I can tell, this thread has been inactive for 3 weeks. What
question were you answering here?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.