From: Nathan H. <hj...@un...> - 2003-05-20 20:05:33
|
> So what "problems" did you run into "reading large amounts of data"? > For me, this code causes a timeout on a read that comes up short, and > an error code returned, which is different, and undesirable, behavior > from under Linux. I dont really recall at this point. > Is there any way we can make it work just like Linux? I just added a line which should correct your problem. It breaks from the loop in the event of a short read (bytes are read, but a timeout error was returned from a pipe read). Let me know if this fix makes the procedure work the ways you expect. |
From: Beat B. <bea...@il...> - 2003-06-19 01:35:52
|
>NB: A "set configuration" will reset to using the first interface on >the device; I think the "claim interface" call should really occur >after "set configuration". Hi I have a strange behaviour of usb_set_configuration(). If the debug level is >= 4 then the code calling usb_set_configuration() and usb_set_configuration() works: usb_set_configuration: called for config 1 Interface 0 of device is 0x0 claim_interface: No interface found; selecting configuration claim_interface: device has 1 configuration claim_interface: configuration value is 1 claim_interface: Interface 0 of device is 0xf5f claim_interface: Interface 0 of device from QueryInterface is 0xa3170 usb_claim_interface: called for interface 0 Interface 0 of device is 0x0 claim_interface: No interface found; selecting configuration claim_interface: device has 1 configuration claim_interface: configuration value is 1 claim_interface: Interface 0 of device is 0x1303 claim_interface: Interface 0 of device from QueryInterface is 0xa29e0 But with a lower debug level the app fails with a USB error: usb_claim_interface: couldn't claim interface and the usb logger says 1267.020 [1] IOUSBInterface[0x40c3000]::handleOpen failing because super::handleOpen failed (someone already has it open) 1267.020 [1] IOUSBInterface[0x40c3000]::open super::open failed (0x0) I didn't find a bug that could explain this. Anyway: How about reclaiming the interface in usb_set_configuration() only if it was claimed before the SetConfiguration() call? Regards Beat H. |
From: Nathan H. <hj...@un...> - 2003-06-19 06:55:41
|
> I didn't find a bug that could explain this. Anyway: How about > reclaiming the interface in usb_set_configuration() only if it was > claimed before the SetConfiguration() call? Sounds like a reasonable request :). Ill commit that change as soon as I have finished testing my current set of changes (btw, if you can test you suggestion that would be really helpful :) -nathan ------------------------------------- | Nathan Hjelm | Senior, UNM School of Engineering | email: hj...@cs... | aim : hjelmnt ------------------------------------- |
From: Stephen H. W. <we...@gr...> - 2003-05-21 12:37:53
|
> Date: Tue, 20 May 2003 14:00:47 -0600 (MDT) > From: Nathan Hjelm <hj...@un...> > cc: lib...@li... > X-UIDL: 3*6!!1@S!!W"^!!fW1e9 > > > So what "problems" did you run into "reading large amounts of data"? > > For me, this code causes a timeout on a read that comes up short, and > > an error code returned, which is different, and undesirable, behavior > > from under Linux. > > I dont really recall at this point. > > > Is there any way we can make it work just like Linux? > > I just added a line which should correct your problem. It breaks from the > loop in the event of a short read (bytes are read, but a timeout error was > returned from a pipe read). No, the timeout is the problem. Under Linux, I just get back a short buffer with no timeout. > Let me know if this fix makes the procedure work the ways you expect. I'll try it, but I doubt that this will help. -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. |