Re: [Libusbx-devel] [Libusb-devel] libusb is dead - long live libusbx!
Jose Pablo wrote: > > I think Vincent is right. I am pretty sure you guys have a lot of good > ideas for the library but if you keep that attitude you will not get > it serious. It seen you guys are taking the project by force I think that's the intent, yes. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] usbclerk: Windows service for signing and installing usb device drivers
Arnon Gilboa wrote: > As some of you may already know, Spice supports native USB device > redirection from client machine to VM (see http://www.spice-space.org). > For our Windows client we use libwdi for installing driver (currently > winusb) for the redirected devices. > Since we don't want the user to be asked for admin rights for each > install, we have written a dummy service for this job. The user still has to have admin rights to install your service, so from that standpoint I suppose it's not nefarious, although I suspect it would be easier just to rewrite the Enum registry entry to switch to the new service. Do you put the original drivers back when I'm through using the Spice client? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] usbclerk: Windows service for signing and installing usb device drivers
Arnon Gilboa wrote: > Tim Roberts wrote: >> although I suspect it >> would be easier just to rewrite the Enum registry entry to switch to the >> new service. >> > Can you pls explain this point? Assuming you don't need to change the device's install class, you can change the driver for a device just by changing the "Service" entry in the Enum key for the device. In my machine, in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_0204&Pid_6025\6&8ft2c8f&-&1, the Service value is "USBSTOR". If I change that to some other service and then restart the device, it will come up with the other service's driver. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] usbclerk: Windows service for signing and installing usb device drivers
Arnon Gilboa wrote:
>
> Do we still need to prepare the driver (patch the inf for the specific
> vid-pid and sign a cat file) or just replace "USBSTOR" to "WinUSB"?
> How does it know where to find the new driver ("service")?
If you're are dinking with driver installation, you really should know
this. You wouldn't need an INF in this case. The "Service" name is a
key in the CurrentControlSet\Services registry tree. You would want to
use Service Control Manager to create the service. That service entry
includes the path to the binary.
> Don't we need to call any "refresh" API?
Yes, I said that -- you'd need to restart the device. The service key
is only checked when the driver stack is built. I use "devcon restart",
but you can do that in your own app, since the source for devcon is in
the WDK.
> Seems also like a reasonable way to uninstall WinUSB and get back to
> USBSTOR, right?
If you were able to install it that way, yes. You might also need to
dink with the UpperFilters and LowerFilters values in the registry, too.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] usbclerk: Windows service for signing and installing usb device drivers
Arnon Gilboa wrote:
> Seems like much more than setting the service.
> Any idea if some of this changes can be dropped?
Many of them just don't matter. They are copied here from the INF file
and are used only for the Device Manager user interface.
> $ diff usbstor1307.reg winusb1307.reg
> 20,24c20,23
> < "ClassGUID"="{36FC9E60-C465-11CF-8056-44455354}"
> < "Class"="USB"
> < "Driver"="{36FC9E60-C465-11CF-8056-44455354}\\0046"
> < "Mfg"="Compatible USB storage device"
> < "Service"="USBSTOR"
Interesting, that's not right. It shouldn't be Class=USB. That's
supposed to be used only for hubs and controllers. The "Driver" entry
might be problematic.
> 29a30,33
> >
> "DeviceInterfaceGUIDs"=hex(7):7b,00,45,00,36,00,43,00,37,00,46,00,39,00,30,00,\
> >
> 43,00,2d,00,30,00,32,00,45,00,32,00,2d,00,34,00,36,00,39,00,39,00,2d,00,41,\
> >
> 00,37,00,36,00,44,00,2d,00,34,00,38,00,32,00,39,00,30,00,32,00,42,00,44,00,\
> > 43,00,38,00,42,00,33,00,7d,00,00,00,00,00
> 34c38
> < "ActiveService"="USBSTOR"
> ---
> > "ActiveService"="WinUSB"
You'd need to add the DeviceInterfaceGUIDs key so WinUSB knows which
device interface to register.
Perhaps this is a bit too much magic just to save a little bit of effort.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Microsoft's view on the perceived WinUSB limitations
Hans Petter Selasky wrote: > Why Microsoft can't use the BSD or Linux USB stack then, which supports all > of > this. Sounds like very bad internal USB design to me! Oh, please. The Microsoft internal USB design is fine, and kernel drivers can do ALL of the things in that post. The restrictions mentioned in that list apply to WinUSB, which is the user-mode wrapper. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Microsoft's view on the perceived WinUSB limitations
Hans Petter Selasky wrote: > In the answers from the Microsoft guy, there were some arguments about > security. Many kind of device drivers could have been made more secure by > moving out of the kernel, for example webcam drivers, which is a class of > devices which are especially using a lot of isochronous endpoints. The use > case is there for sure, but probably nobody saw it. I have long argued that code should never be in the kernel unless it absolutely MUST be in the kernel, but isochronous drivers almost always have performance and latency issues. The primary disadvantage of moving drivers to user-mode is that latency goes up and throughput goes down. Microsoft quotes a 10% performance penalty. There are many classes where that doesn't matter, but webcam drivers aren't one of them. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] USB port number
Janko Kolar wrote: > I am new to libusbx and I have one basic question > > I would like to determine to which usb port particular device is attached. Why? Of what possible use is this information? USB hubs are not externally labeled. If I tell you "you are in port 3", what good does that do you? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] USB port number
Xiaofan Chen wrote: > On Sat, May 5, 2012 at 1:02 AM, Tim Roberts wrote: >> Janko Kolar wrote: >>> I am new to libusbx and I have one basic question >>> >>> I would like to determine to which usb port particular device is attached. >> Why? Of what possible use is this information? USB hubs are not >> externally labeled. If I tell you "you are in port 3", what good does >> that do you? > Many users ask for this feature. I know they do, because they don't understand what they're asking. Providing this information is merely an opportunity to reinforce those misunderstandings and spread urban legends. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Add topology calls
Pete Batard wrote: > Thus, as part of the overall topology, I have to very much disagree with > anyone who wants to pretend that providing a port number or hub location > has little use. ... > > Finally, I'd like to remind everyone that we are purveyors of a generic > library. As long as we don't have clear and precise information on an > user's specific intended usage, it is really not our damn job to > question what people would like to do with it or assume that they are > planning to use it "wrong". Instead, our job is to ensure that our > library can be used in every imaginable way, including the ones we may > not necessarily approve of... "Every imaginable way." I hope you have some clue to the size of the can of worms you've opened up there. Whether you like the terminology or not, there ARE paths that people want to follow that are wrong, either because they don't fully understand the technology, or they don't understand the implications of their actions, or they have a flawed mental model of the system. I think you're doing a disservice to people by reinforcing a defective mental model, instead of "guiding" them to a correct and sustainable solution. What does the "topology" concept mean in a VM environment? You're depending on interfaces that are system-specific but not promised by contract. Are you sure the mechanisms you need will still be there in three years? However, you're fully entitled to set policy, so I won't say any more on the topic. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx, xusb and ST-Link V2
Xiaofan Chen wrote: > There is a warning, not so sure if it is really of importance or not. > ... > C:\work\libusbx\libusbx-1.0.11-win\examples\bin32>xusb.exe -d 0483:3748 > Using libusbx v1.0.11.10499 > > Opening device... > [timestamp] [threadID] facility level [function call] > > > [ 0.00] [04a0] libusbx: warning [init_device] could not get node > connect > ion information for device '\\.\USB#VID_&PID_#5&2D0620DE&0&1': [87] > The > parameter is incorrect. You understand this is not the same device, right? / is what you get when a device fails to enumerate at the hardware level. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx, xusb and ST-Link V2
Peter Stuge wrote: > Xiaofan Chen wrote: >> I think the warning message is a bit miss-leading. If libusbx found >> /, then it should probably warn against unrecognized device. > If Windows says that there is a 0:0 device when there is actually an > error, and if this case is indistinguishable from an OK device with > 0:0 in the device descriptor, then the Windows backend should not > discard the device. Well, this is a philosophical issue. The USB spec says there is no such thing as "an OK device with 0:0 in the device descriptor", because a device descriptor needs to have a VID from the USB IF. However, we all know it's possible to create descriptors that violate the spirit of the spec and still operate. That would be the case here. The issue arises because libusb and libusbx are relying on undocumented behavior (actually, "explicitly disrecommended behavior") by cracking and assigning meaning to the fields of the hardware ID. That makes a policy decision a bit awkward. Libusb sees USB\VID_&PID_ and assumes this represents a real device with in the VID and PID fields, but that is a conclusion based on a faulty assumption. > However, if Windows always considers a device with 0:0 in the device > descriptor an error, then the Windows backend should discard them. I don't think the Windows USB stack does any such thing, although if I were a real man I would have burned a device with / to test this. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] New to libusbx ... possibly idiot question
g...@novadsp.com wrote: >> please be aware that the Windows driver we use at the >> moment doesn't support isoch (see "Known Restrictions" for WinUSB at >> [1]), > Indeed. Why on earth make WinUSB without isoch support. Microsoft's answer is because (1) it's hard to abstract it in a reasonable and bullet-proof way, (2) the performance penalty of handling things in user mode matters in isochronous use cases, and (3) the only uses for isochronous are audio and video, and those device classes can't be done in user-mode in Windows anyway. When news of this limitation first came out 5 or 6 years ago, the USB team at Microsoft sent out a blast saying "We will add this if you have a legitimate use case for it. Let us know." No one has let them know, or at least no one that matters. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] interrupt transfer linux
Fabian Weiss wrote: > I try to communicate with an USB device: http://nopaste.info/bc655859b3.html > I want to read the 42 bytes of bEndpointAddress 0x83 EP 3 IN. > Therefore I installed libusb(x) under my Linux and wrote this little > programm: http://nopaste.info/98c35ab092.html > > I dont understand why it doesnt work, so I am asking you. My output is: > .. > Device Opened > Claimed Interface > libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=2 > read Error: -1 > Data read: > Released Interface > > :( > Can somebody tell my what I am doing wrong? Yes: r = libusb_interrupt_transfer(dev_handle, 3, buf, 10, &transferred, 10); If you want endpoint 0x83, then you need to ask for 0x83, not 3. Those are two completely different endpoints. There is no relationship between endpoint 0x03 and 0x83. It's NOT "two directions of the same endpoint", as many people seem to think. Also, if you want 42 bytes, you should ask for 42 bytes, not 10. In general, you should ALWAYS ask for a multiple of the endpoint's packet size. That's a HID endpoint. Are you certain there will be HID traffic waiting for you, and that you don't need to send a report request first? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.12-RC1 now available
Xiaofan Chen wrote: > I think I have mentioned this before, the new VS11 Beta can > not convert the existing VS2010 project properly. I think this > is not a real problem for now but we may need to create > a new VS11 solution in the near future. Yes, I think you would certainly want to wait until the retail release to take any action. VS11 is still undergoing changes. I'm guessing VS11 is not going to catch on very quickly. There are a number of very unpopular changes, including the fact that it will no longer build binaries that work on Windows XP. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_control_transfer() stalls
Markus wrote: > As of now, I can read and write memory by using vendor request > control transfers. According to the manufacturer this is the way > to go for firmware dump and download. That's a common mechanism. > wValue (LSW) and wIndex (MSW) make up the address offset to write > the data to within device memory. Are you sure you have the ordering correct? (It probably is, because that lets those two fields be treated as a single little-endian dword.) > In both cases (r/w), the maximum value for wValue is 0x4000, after > that libusb_control_transfer() returns pipe errors. As it is > possible with the original tool to write beyond this address, I > suspect it's not the device that produces the stall. What is the actual error code you get from WinUSB? If the error really is a stall, then has to come from the device. What is the bmRequestType? Is it a vendor request to the device? Would you mind showing us the code? > As I don't have any known-good device where I could meaningfully > test a control transfer with wValue > 0x4000, I'd also be happy > for any hint towards how to reproduce this behaviour. I have certainly done vendor device requests with wValue larger than 0x4000. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_control_transfer() stalls
Markus wrote: > int CypressFX3Device::WriteRAM(size_t addr, > const unsigned char *data, size_t nbytes) OK, please allow me to ask a foolish question. Do you really have an FX3, and not an FX2? The FX2 only has 16kB of RAM, which is where you are hitting the problem. The FX3 is supposed to have 512kB, so it shouldn't be an issue. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_control_transfer() stalls
Markus wrote: > Thanks, Pete. As Wireshark doesn't capture USB on Windows, it > looks as I'll have to resort to a proprietary tool. > > Can you (or somebody else reading the list) recommend something worthwhile in > a price range < 500$ ? I've used USB Monitor from HHD Software for many years. Their GUI is a little more video-game-like than I prefer, but it does the job. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.12 has been released
philip.jos...@microchip.com wrote: > Just a note in regards to WinUSB and Windows 8. It would appear that a > device will not need to provide an INF as long as it provides Windows > specific info in its OS descriptors... When we talked about this before, it was mentioned that it would be possible to write a filter driver for usbport.sys on the existing operating systems to provide this same functionality. Did anyone ever undertake that project? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx v1.0.12 has been released
Pete Batard wrote: > But wouldn't that require at least one manual installation of the filter > driver by the user, and therefore equate what we can already provide > with WCID on non Windows platforms, where one WCID WinUSB driver > installation is enough the make the platform behave the same way as > Windows 8 in terms of detecting and automatically installing drivers? You're right. I hadn't thought that through sufficiently. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Question about libusb_get_pollfds?
Kevyn-Alexandre Paré wrote: > So by calling the libusb_get_pollfds It return 3 file descriptor. > > So my question is why 3? > > 2 files descriptor (POLLIN) that could be read. > 1 file descriptor (POLLOUT) that could be write. > ... > So I can see that POLLOUT could be the endpoint8 and 1 of the POLLIN the > endpoint6? If this is correct what is the other POLLIN file descriptor? If timerfd is available on your system, to manage timer expirations through a file descriptor, that's added to the POLLIN list. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Isochronous error on mac
Ellis Whitehead wrote: > I had hoped that I could make some progress by investigating this > further myself, but wasn't able to figure much out... > ... > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 0 (Defined at Interface level) A custom device should have 0xFF here. A class of 0 in the interface descriptor is reserved in the spec for future use. > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes1 > Transfer TypeIsochronous > Synch Type None > Usage Type Data > wMaxPacketSize 0x0258 1x 600 bytes > bInterval 1 Isochronous endpoints are only supposed to be included in an alternate setting other than 0. The way you have it here, your device will reserve bandwidth as soon as it enumerates. In Windows, if your bus doesn't have enough bandwidth, the device will fail enumeration. By moving this to an alternate setting, the device will enumerate, and you can detect in the driver/application that the problem is insufficient bandwidth. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Question about libusb_get_pollfds?
Kevyn-Alexandre Paré wrote: > >> >> If timerfd is available on your system, to manage timer expirations >> through a file descriptor, that's added to the POLLIN list. > thx, The linux kernel that I'm using have timerfd enable! > > One question remains, how to distinguish the files descriptor from each other? Why would you need to? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_get_string_descriptor_ascii always fail.
John Chen wrote: > Peter, > Yes, you are right, this is a custom device, Here is the legacy code > to get the serial number > > if ( ::DeviceIoControl(m_hDeviceObject, IOCTL_EZUSB_GET_SERIAL_NUMBER, > NULL, 0, serial, cb, &cbOut, NULL)) > ... > do you know what I should do to map > the DeviceIoControl to libusb_control_transfer in this case? That's a command to the Cypress generic driver for the FX2 chip. That generic driver converts this to a GET_DESCRIPTOR control message, exactly like the one in your code. I noticed the following lines in your log: > [ 0.159532] [09c0] libusbx: debug [get_api_type] driver(s): WUDFRD > [ 0.160032] [09c0] libusbx: debug [get_api_type] lower filter > driver(s): WINUSB So, it looks like this device has a UMDF driver, with WINUSB as a lower filter. Is libusbx trying to talk to this WINUSB instance? That is, does it assume that, if there is a WINUSB driver, it must be one it can chat with? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_get_string_descriptor_ascii always fail.
John Chen wrote: > > Yes, I already installed the UMDF driver on windows, I do not know > exactly what libusb is trying to do here, I looked some of libusb's > source code, looks like it is using some of winusb api. from the > legacy code (that works), I noticed that it passes > IOCTL_EZUSB_GET_SERIAL_NUMBER to windows api DeviceIoControl , but I > do not see anywhere I could pass this parameter > to libusb_get_string_descriptor_ascii, does that > mean libusb_get_string_descriptor_ascii will not working for me on > this device? if yes, how do I map the call > from DeviceIoControl to libusb_control_transfer You are confusing two things here. IOCTL_EZUSB_GET_SERIAL_NUMBER is a custom command to a custom driver. It is not a USB function. It is a command that Cypress' custom driver understands. When the Cypress driver receives that ioctl, it sends a standard USB GET_DESCRIPTOR command to the device. When you are using libusbx, you are not talking to Cypress' driver. You are talking to one of the libusbx back-end drivers. They have their own set of commands, but you never see those commands. The library sends those commands based on the libusbx functions you call. In this case, the libusbx request you are making will produce exactly the same USB request that the IOCTL_EZUSB_GET_SERIAL_NUMBER ioctl produces in the Cypress driver. Your problem is not the command. Your problem is the way the drivers are configured. Pete B is much more current on this process than I am. He is well on his way to having a solution for you. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_get_string_descriptor_ascii always fail.
John Chen wrote: > Thanks Peter, it worked!! I got the serial number from > libusb_get_device_descriptor!! I have the following questions: > 1) So I do not have to install Windows Driver for the devivce at all? > what is Zadig ? You installed a driver-based product without understanding what it was??? You are far too trusting. Zadig is an installer that installs a generic USB driver, which libusbx can use. A driver of some kind is always required for USB devices. > 2) I need to have the same code work on Linux, is there a > equivalent Zadig in Linux? It's not needed in Linux. The kernel includes a functional generic driver. > 3) I have the some legacy code call ::DeviceIoControl in windows, how > do I map all the parameters to libusb_control_transfer. It's not that easy. As I said in the other post, the IOCTL_EZUSB_xxx commands are part of the custom Cypress FX2 driver. They are not USB commands. Many of them do map to single USB requests, but someone of them are more complicated. Cypress used to release the source code for ezusb.sys, or you could post the ioctls that you need here and I can offer advice. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Map DeviceIoControl calls to libusb_control_transfer
John Chen wrote:
>
> I need to convert a legacy app from win api calls to libusbx, most of
> the legacy app is using DeviceIoControl , from libusbx docs, the I
> believe I need to use libusb_control_transfer, but I am not sure how
> to change the calls from DeviceIoControl calls to
> libusb_control_transfer as the parameters for those api are total
> different.
>
> Would anyone give me some advice how to do that? maybe some examples?
Honestly, you should be able to figure this out on your own. Did you
even notice that the parameter names in the
VENDOR_OR_CLASS_CONTROL_REQUEST structure are exactly the same as the
parameter names to libusb? RequestType, Request, Index, Value? A few
minutes reading would tell you how to combine direction, recipient and
request type into the bmRequestType field for control requests, but I
will tell you that a device-to-host vendor request to an endpoint has a
bmRequestType of 0xC2.
When you use libusbx, you are writing a driver. It may not feel like
it, but it is a driver. You need to understand something about USB in
order to drive a USB device, and right now you don't seem to have that.
> Below is some of our legacy calls in window api.
No, this is exactly one legacy call.
> {
> enError = SendVendorRequest(
> VENDOR_REQUEST_DIRECTION_DEVICE2HOST,// direction
> VENDOR_REQUEST_REQUESTTYPE_VENDOR,// request type
> VENDOR_REQUEST_RECEPIENT_ENDPOINT,// recipient
> VR_I2C_COMMAND,// request
> c_usDeviceId,// device id
> c_usOffset,// offset
> c_uiLength,// size
> reinterpret_cast(pszAssNum));// buffer
bmRequestType = 0xC2
bRequest = VR_I2C_COMMAND
wValue = c_usDeviceId
wIndex = c_usOffset
length = c_uiLength
You should be able to figure the parameters out from that.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Map DeviceIoControl calls to libusb_control_transfer
John Chen wrote: > Tom, > Would you please show me how did you get bmRequestType to value 0xC2. I did this so often that I finally created a "cheat sheet" that I keep in a text file. +---+---+---+---+---+---+---+---+ | d | type | | recip | +---+---+---+---+---+---+---+---+ | | | | +- 0 Standard +- 0 Device |1 Class 1 Interface |2 Vendor2 Endpoint |3 Other +- 0 To device 1 From device 00 Standard device, outgoing 01 Standard interface, outgoing 02 Standard endpoint, outgoing 03 Standard other, outgoing 20 Class device, outgoing 21 Class interface, outgoing 22 Class endpoint, outgoing 23 Class other, outgoing 40 Vendor device, outgoing 41 Vendor interface, outgoing 42 Vendor endpoint, outgoing 43 Vendor other, outgoing 80 Standard device, incoming 81 Standard interface, incoming 82 Standard endpoint, incoming 83 Standard other, incoming a0 Class device, incoming a1 Class interface, incoming a2 Class endpoint, incoming a3 Class other, incoming c0 Vendor device, incoming c1 Vendor interface, incoming c2 Vendor endpoint, incoming c3 Vendor other, incoming All other values of bmRequestType are invalid. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Async API question:
Kevyn-Alexandre Paré wrote:
> Here's the code and output of my test. I'm trying to understand what's going
> wrong! I mean that I'm expecting the callback function "cb_xfr" from my bulk
> transfer to be called after libusb_submit_transfer is called. I'm
> communicating to a FPGA through a Cypress USB (FX2) and It's working with the
> synchronous API but not yet with the Asynchronous one??? I have put the
> usbmon output that I'm still reading and learning about it. If you see
> something let me know!
> ...
> static int benchmark_in(uint8_t ep)
> {
> static uint8_t buf[6] = {0x2,0xa0,0x3c,0x23,0x3,0x0};
> static struct libusb_transfer *xfr;
> int num_iso_pack = 0;
>
> xfr = libusb_alloc_transfer(num_iso_pack);
> if (!xfr)
> return -ENOMEM;
>
> libusb_fill_bulk_transfer(xfr, devh, ep, buf,
> sizeof(buf), cb_xfr, NULL, 0);
>
> gettimeofday(&tv_start, NULL);
> printf("-->SUBMIT length:%d\n", sizeof(buf));
> return libusb_submit_transfer(xfr);
> }
When you are doing a bulk IN transfer, you always need to specify a
buffer that is as large as your endpoint size. Remember that a USB
device is never told how much data to send. It is merely given a signal
that says "GO!". At that point, the device has the perfect right to
send 512 bytes. However, the host controller will only have allocated
enough bus time for 6 bytes. Your device steps on the next device's
slot. That's a protocol violation called "babble".
> int main(int argc, char **argv)
> {
> ...
> rc = libusb_set_interface_alt_setting(devh, 1, 0);
It is not useful to select an alternate setting unless you have more
than one. If you only have bulk pipes, then you have no need for
alternate settings.
> libusb_clear_halt(devh, 0x06);
> libusb_clear_halt(devh, 0x88);
Why do you call clear_halt here? In virtually every case, that's
unnecessary superstition.
Are you sure your device has queued up data to send? What is it that
tells your device to put data in the FX2 FIFO?
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Access garmin devices using libusb on linux and windows
Luiz Andrade wrote: > Hi again, I just installed Zadig in my computer and I installed the > garmin driver 0x091E/0x0003 for my garmin Etrex Vista HCX. > But i still get the -12 error when i try to access my gps. I'm using > libusbx-1.0.12 now, I included the source files into a qt4 project. > My project compiles and runs ok, what I'm missing now. Sorry again, > but I'm a beginner in libusb. Look, if you want to use the Garmin driver, then you need to use Garmin's API to access the device. If you want to use libusbx, then you cannot use Garmin's driver. One or the other. If you are just a beginner, then why do you want to use libusbx? Why not just use Garmin's API, which is defined, documented, and tested? They have a Device Interface SDK that should be able to get you whatever you need. http://developer.garmin.com/web-device/ Libusbx is usually not the right answer when there is already a well-defined way to access the device. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Access garmin devices using libusb on linux and windows
Luiz Andrade wrote: > The Garmin SDK is very hard to use in my point of view... I promise you that will be easier to use than going direct to USB. > I tryed to use it but i can't find almost anything on the web about it > so, Then you haven't been looking. I gave you the URL. > I don't wanna work with web applications, I need a desktop application > in c++ So, you didn't actually read the link I gave you? http://developer.garmin.com/web-device/device-sdk/ That is not a web API. It's a C interface. That zip includes a specification in PDF form, and sample C program that shows you the exact interface to the Garmin DLL. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Access garmin devices using libusb on linux and windows
Luiz Andrade wrote: > > using WinUSB I was able to open my garmin gps device. Thanks for your > help!!! > Now let ask you one more thing, can you help me read informations from > my gps, give some sample code, some internet page to read, anything? I am generally a patient person, but I am finding it very difficult to remain civil. You are asking us to write your code for you, apparently without making any effort to do so on your own. You can use Google just as well as the rest of us. I would like to point out that, before you asked your first question, I had never looked at a Garmin device. I learned the information I gave you by using Google and reading snippets of the Garmin documentation. You can do the same. I will repeat my previous question: did you READ the documents on the page I sent you last time? The Garmin SDK documentation contains a detailed description of the data formats produced by their devices. Their driver is not very complicated -- it mostly just passes requests straight through to the device. YOU ought to be able to figure out from that document what the data is you are receiving from USB. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Access garmin devices using libusb on linux and windows
Luiz Andrade wrote: > > If you don't wanna help, you do not have to answer my questions. You are not being fair. I have been very helpful. I've looked up references, pointed out the appropriate documents, and suggested web pages. I didn't write your code for you, but I have certainly pointed you in the right direction. > Keep to yourself your thoughts about people who don't know how to use > libusbx. > I was thinking that this forum was made to help people use libusbx. It is. But you are not asking for help on how to use libusbx. You are asking for help on how to talk to your Garmin. We don't know more about that than you do. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Windows CE backend and driver
Pete Batard wrote: > and it seems Microsoft can't stick to a naming convention anyway (For > instance, in latest WinUSB redistributables [1] MS replaced "amd64" for > "x64" for the x86_64 binaries)... Well, they do have to worry about pressure from their partners. When AMD first proposed the 64-bit extensions, it made a certain amount of sense to call the architecture amd64. After all, Intel had ia64, and there was no guarantee at the beginning that amd64 would end up being the de facto standard. By the time Intel "borrowed" the concept and named it EM64T, the Windows build tree already had the amd64 name embedded throughout. I assume this irritates Intel every time they see it, and so they keep having guys in nice suits whisper in the ears of Microsoft management that "it would really be more fair and accurate if you dropped the amd64 name". That's gradually happening over time. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Windows CE backend and driver
Pete Batard wrote: > Of course it would be quite ironic if intel were the ones who pushed MS > and others to use ia64 in the first place, in order to push brand > recognition (ia = "Intel Architecture"), and got bitten at their own > game when their competitor both followed suit with amd64 and actually > managed to set the course for mainstream 64 bit adoption. Karma's a bitch ain't it? ;) -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Handles for Windows WaitForXXX API?
g...@novadsp.com wrote: >> No good since there can be no data from device until you initiate a >> transfer. > ? err, no. My device might well start to write back down the pipe as > soon as it has been configured. No, although it may be a matter of semantics. Your device can queue up data to be sent, but it is not allowed to put anything on the wire until it gets an IN token from the host, and that will only happen if the host controller driver has a pending request from you. If you don't ask for it, the device is never given the opportunity to send. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN
Chris McClelland wrote: > Basically, the supplied FX2 firmware (in libusbx/fx2/fw/firmware.hex) > enumerates with two IN endpoints, EP1IN and EP2IN. Endpoint 1 is the poor stepchild in the FX2. The functionality is limited, the buffering is fixed and limited, and it uses different registers from the other endpoints. As a general rule, you'll be much happier if you forget about it, and always restrict yourself to the even-numbered endpoints. Your descriptors have the max packet size set to 64 for endpoint 1. That's not valid. In a high-speed devices, bulk endpoints must ALWAYS have a max packet size of 512. That's required by the spec. Because the FX2 only has a 64-byte buffer for endpoint 1, that presents a philosophical problem, and the FX2 data sheet points this out. You have to report it as 512 bytes, but make sure you never try to do a packet larger than 64. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN
Chris McClelland wrote: > The EP2&6 pair seems to require quad-buffering in order to get the best > throughput (I measure 43MiB/s when quad-buffered and about 33MiB/s when > double-buffered),... Yes. You should also be aware that those speeds are highly dependent on the quality of the host controller, and the other devices on the bus. We, also, have sustained 45 MB/s through an FX2 bulk pipe, but only on certain host controllers. The same hardware in another machine won't push beyond about 30 MB/s. And bulk transfers, of course, are last priority, and compete for bandwidth equally amongst themselves. If you have a USB keyboard or mouse or speakers or camera, all of those get their pieces first. As long as your buffering can handle that, you're fine, but it's dangerous to make assumptions about bulk throughput... > Since the JTAG streams are limited by the speed of the 8051, keeping the > send/receive chunks down to 64 bytes is perfectly fine, and possible > because I control the code on both sides. Yes. It is easy to forget how abysmally slow the FX2's 8051 is. At best, you get 3 MIPS. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] question on libusb_bulk_transfer and libusb_fill_bulk_transfer
John Chen wrote: > > The device I am working right now demanding sending and receiving data > in unsigned int, and every bit has to be in exact position, in windows > it is easy as the DeviceIoContorl takes a void pointer, but in libusb, > both libusb_bulk_transfer and libusb_fill_bulk_transfer only takes > unsigned char*. You may treat those two types (void* and unsigned char*) as identical. Partly, this is historical. The whole "void" type concept was not introduced to C until the standardization process. Before that, "unsigned char *" was the way you identified a generic buffer of unknown type. For some people, old habits die hard. Don't assign too much meaning to the word "char". In C, it does not refer to letters and numbers. It refers to a unit of memory one byte in size, with no other inherent meaning. > when writing, I am combine all the unsigned int into string char>, (no sure if this will work or not) but when reading, there > could be so many different combinations, e.g. if libusb returns the > following: > 125 > 126 > 210 > > how do I know how to pack the data into unsigned int and how many > unsigned int? If you have your data as an unsigned int, and you need to send that as a 4-byte quantity to your device, just use (unsigned char *) &myUnsignedInt You need to be aware of endianness issues, however. Windows is exclusively little-endian, so your device might be the same, but Linux runs on systems that are big-endian. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] asynchronous code in mufti-threading app
John Chen wrote: > Hi, > My app needs be able to read & write (to different enpoint) at same > time, and my code is not working. but if I change the call to > Synchronous , everything works fine, could any one tell me what I did > wrong here? Is LibUSBDevice::WriteCallback declared as static? What DO you see? Is there an error, or does it simply never return? How many bytes are you trying to read? What is the value of "endpoint"? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Trouble with USB communication Windows
Eric Lundby wrote: > > I have spent hours now trying to get communication working with a > custom USB device on Windows using libusbx. I have communication > working through a virtual com port so I believe the device is > functioning as expected. > > My device reports that it has 3 interfaces (0, 1, 2) and a total of 5 > open pipes (see below for the complete output). However my calls to > libusb_claim_interface return -12 for all interfaces except 2 which > is HID. I am able to get two way communication over HID, but the USB > device i'm using only supports minimal functionality over HID (or > atleast thats my understanding). I'm not sure if this is due to some > driver configuration, bugs in my code, bugs in windows backend etc. > My code is as follows: > > r = libusb_init(&ctx);//Success > libusb_set_debug(ctx, 3); > dev_handle = libusb_open_device_with_vid_pid(ctx, 0x04D8, > 0x00DF);//Success > r = libusb_claim_interface(dev_handle, interface_number);//Returns -12 > for interfaces 0 and 1, Interfaces 0 and 1 are CDC (communication class). It's possible those interfaces are already being claimed by a virtual COM port driver. How did you install the libbusb driver? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] asynchronous code in mufti-threading app
John Chen wrote: > > Here is the problem > 1) in the following code. > ... > for some very simple multi-threading , it works, but in more > complicate case, the code stuck in the loop and I am getting the > following: > ... > somehow the callback is never called. We can't diagnose this. There is just way too much of the code that we don't have. Are you suggesting that events are somehow getting lost? You'd need to do some tracing to match up requests-in with events-out to make sure of that. > 2) If I lock a shared critical_section in the beginning of the > transfer function,(That means I am running single thread, I am > serialize the call) it takes 4-5 calls for > libusb_handle_events_timeout to call the callback and exit the loop. > this is the case even when 0 byte is read. Well, when 0 bytes are read, it should time out. Right? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] asynchronous code in mufti-threading app
John Chen wrote: > Tim, I attache the usb debug trace and USB_Trace here. Yes, I did get > a timeout, but if you look at USBTrace.txt, it have the following: > > [libusb_get_next_timeout] no URB with timeout or all handled by OS; no > timeout! > do you need what it means? It looks like you are running multiple simultaneous event loops. Is that correct? You don't need to do that. You can see how the log output is garbled, apparently because the log output is intermixed with another thread writing at the exact same time. My best guess is that you have some kind of multithreading problem, but there's not much we can do without seeing the whole code, and I'm not sure you really want to do that. You need to think about what order things are happening, remembering that asynchronous operations will always arrive at the most inconvenient time. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] LibUSB bulkread always got a TIMEOUT
Ricardo Villamil wrote: > I have the exact same problem, did you find a solution? You don't have the exact same problem. You might be getting a timeout, but that's almost certainly because you're using the device incorrectly. Every device is different. Show us your code, and tell us what you expected. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] asynchronous code in multi-threading app
john smith wrote: > > Hi, > > This is a continuation my previous post a few weeks ago, (BTW, I was > never to resolve that problem), I read the manual many time and read > all the related post, I believe I did everything right, now I am > running my on Linux (Ubutu 11), this time, it did not crash but the > behavior is very similar, the READ and WRITE did not return and > finally the app bail out. would anyone please tell me what I did > anything wrong here? > > > I am not doing any hot plug here. I do not understand why it is show > the following: > > _[44.690983] [266b] libusbx: debug [handle_bulk_completion] device > removed_ > Your log shows you get these errors, in this order: -121 EREMOTEIO -104 ECONNRESET -108 ESHUTDOWN (repeatedly). The libusbx code handles ESHUTDOWN by printing the "device removed" message. EREMOTEIO indicates that the endpoint had been disabled because of a previous error. ECONNRESET usually means the URB was canceled while in progress. ESHUTDOWN indicates that something in the device's path is shutting down (controller, hub, device). My guess, based on the limited evidence, is that you have a device problem that is causing the host controller to raise error conditions on your endpoint. Is this a device you are developing? Do you have a USB analyzer, so you can watch the traffic when this happens and see if there are any unusual packets? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] asynchronous code in multi-threading app
John wrote: > This is the device that is working on Windows and has been in production for > years (with Windows API calles), I am not develop the device, what I am > doing is use the device, simple read & write. > > The exactly the same code work when running in single-threaded app. > > when look at my libUSB code, did you see anything that should be changed? Honestly, the app was too long for me to desk check. You should only call libusb_claim_interface once at the beginning of your application, and libusb_release_interface once at the end of your application. You need to own the interface during the entire period that you are using it. You don't claim and release for every operation. libusbx does not throw any exceptions. Your try/catch is pointless. It looks like your read code claims the interface, submits the transfer, then releases the interface and returns, without ever entering the event loop. Who is going to reap the completed URB? > I do not currently have a USB Analyze for Linux Right, I really meant a hardware analyzer, but I'm thinking now that's not necessary. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] asynchronous code in multi-threading app
john smith wrote: > > But I got another "performance issue" I need your help again. > > My test app is doing a loop, it seem that every time it loops, it > takes SIGNIFICANT SLOWER than last time, if you look at debug trace, > on the Throughput (Please see attached) > > 1) Throughput : 1.37353082311847E-06 MB /sec > 2) Throughput : 1.47827364610777E-05 MB /sec > 3) Throughput : 0.00014234189339164 MB /sec > 4) Throughput : 0.00142455477006608 MB /sec > 5) Throughput : 0.014406354683313 MB /sec > 6) Throughput : 0.0431200269210705 MB /sec Actually, this is showing things getting increasingly FASTER over time. Higher throughput means better performance. The log shows that each transfer takes exactly the same amount of time (about 2.7 seconds), but each one transfers ten times as much data as the last (10, then 100, then 1,000, then 10,000, etc). That naturally produces the results you see. So, basically, you aren't measuring what you think you are measuring. For example, it looks like you might have a fixed delay of 2.5 seconds somewhere between your "start" and your "stop". You can't measure throughput if you are blocking in your timing code. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Selecting a composite device interface?
g...@novadsp.com wrote: > ProductID: 0xA00A > Interfaces: 2 > Number of alternate settings: 1 > Interface Number: 0 > Number of endpoints: 2 > Descriptor Type: 5 > EP Address: 133 > Descriptor Type: 5 > EP Address: 6 > Number of alternate settings: 1 > Interface Number: 1 > Number of endpoints: 0 > > What I don't get is how to write to the second interface. If the second interface has no endpoints and no alternate settings, what's the point? You can write to the device's control endpoint without claiming an interface at all. Remember that interfaces are just ways of collecting endpoints. Endpoint requests on the bus do not include an interface number. Claiming an interface just grants you ownership of the endpoints within that interface. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Help needed with deployment issues on Windows
therau2000 wrote: > > 2-my Java Program is currently being used by well over 1600 people > world-wide. Installing libusb-win32 driver is not an option because: > a-it disables the default Windows removable-drive driver USBSTOR, > therefore making it impossible to access recorded Videos/Photos; > b-the competing program (32-bit Windows only) does not require > User to install anything to work correctly. > Question: how can libusbx piggy-back its communication to USB > devices over driver USBSTOR ? It is possible that your "competing program" installs a filter driver. That can be done silently and does not require the normal PnP installation process, although the device has to be restarted or unplugged/replugged. I don't believe any of the libusbx back-ends operate as a filter driver. However, I thought that the libusb-win32 COULD act as a filter. Am I wrong? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Help needed with deployment issues on Windows
therau2000 wrote: > On Mon, 2012-10-29 at 01:15 +0100, Peter Stuge wrote: >> Find out exactly how those commands get sent, and find a method to >> send them which is outside the USB domain if possible, since that >> will be both simpler for you to implement *and* will provide a >> significantly better user experience. > The "competing program" uses a .dll to communicate with the Device's > Firmware. By examining that .dll file, I just discovered that it is > calling "DeviceIoControl" in kernel32.dll. MS documentation about > "DeviceIoControl" states "An application can use the DeviceIoControl > function to perform direct input and output operations on, or retrieve > information about, a floppy disk drive, hard disk drive, tape drive, > or CD-ROM drive.". Somewhere else I read that "SCSI Pass Through" is > implemented using "DeviceIoControl" direct (meaning un-buffered). There are exactly five fundamental I/O operations on Windows (copied from the original Unix model): open, close, read, write, and ioctl. (Linux adds mmap to that list.) The APIs for those operations happen to be spelled CreateFile, CloseHandle, ReadFile, WriteFile, and DeviceIoControl. DeviceIoControl does not necessarily mean unbuffered. It's just the general-purpose way to send requests to a driver. One key thing to remember here is that SCSI passthrough is a disk concept, not a USB concept. The ioctl is sent to disk drivers, not to USB drivers. They are at different layers of abstraction. Even SATA disk drives accept SCSI passthrough commands. > So I imagine this is how the "competing program's" .dll communicates > with the Device's Firmware. > > Writing Java and C code using the libusbx API is doable for me; I have > done it and it does work nicely. But I am afraid that writing code for > "DeviceIoControl" is beyond my capabilities. So unless someone helps > in one way or another I am afraid I will have to... give up. Ioctls are not conceptually difficult. A read has one buffer. A write has one buffer. An ioctl has a command code and two buffers. That is quite literally the only difference between the three operations. There are examples on the web showing how to open a disk device and send SCSI passthrough ioctls. However, just like with USB, you have to know what you're sending in the passthrough to achieve the results you want. You can discover that -- you have to have a reference. We don't know what commands the disk firmware expects, and there's no good way to find out. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx and Windows 8 and Windows 8 RT
Xiaofan Chen wrote: > Now that Windows 8 and Windows RT have been released to the > general public and new computers/tablets/hybirds are being > released with Win8 and WinRT as the OS. It will be interesting > to see how libusbx work under Windows 8. It shouldn't be an issue at all. Internally, Windows 8 is not all that different from Windows 7. All of my USB drivers have just plugged-and-played. Only the UI is different, although the UI is DRAMATICALLY different. Even for a Microsoft fanboy like me, there is much to hate here. There is one small installation difference. In Windows 8, all driver packages must have a CAT file. I don't know whether the non-WinUSB back-ends were using a CAT file before, but that may be an issue. > Right now I assume libusbx will not work under Windows RT. Right, and it never will. You cannot run standard Win32 applications or DLLs in Windows RT at all. The APIs are blocked. Unless you get special blessing from Microsoft (and so far only the browser makers have that blessing), RT will only run "Windows Store" applications that run under the control of the WinRT runtime, and the runtime is the only component that can do I/O. > But maybe it is worth looking at how to get it work there. > WinUSB apparently works under Windows RT. The only way to use USB is through the WinRT runtime. That runtime uses WinUSB. At this point, there is no other way to do it. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Which removable drive matches which USB device?
therau2000 wrote: > > Several USB devices [all with different vendor/product-id, all > removable drives with different Volume names, all formatted FAT32] are > already connected when program starts. Windows does NOT display Volume > names; it displays only "removable drive" and the Drive letter for > each of them. > > I can easily list all USB devices and all Drive letters, BUT... > > How can I associate each USB device to its proper removable Drive letter? > i.e.: device 1234:abcd ==> is really Drive letter F: Xiaofan's link is the right place to start, but I want to warn you that this is a much more difficult task than you might suspect. Remember that the mapping of drive letters to volumes is not 1-to-1 -- a single removable drive can host multiple volumes, and a single volume can span multiple drives. The WMI solution is the easiest. There is an API solution, but it involves opening the raw devices, sending ioctls to query their partition IDs, and then matching up the partition IDs. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Which removable drive matches which USB device?
therau2000 wrote: > > In my case, it is always a one-to-one match; all USB devices have only > one partition formatted as FAT32. Today, maybe. Will your software never be used on other systems? > What is the API solution you were referring to? I might have to use > ioctls for another purpose... You run through each allocated drive letter, and use IOCTL_STORAGE_GET_DEVICE_NUMBER to get a STORAGE_DEVICE_NUMBER for the device. Then, you use the SetupDi APIs to enumerate through all of the disk devices, fetch the hardware ID from each, find the one that matches your device, use IOCTL_STORAGE_GET_DEVICE_NUMBER on that, and match that to the list you got from the drive letters. It's a pain. http://forums.codeguru.com/showthread.php?499595-RESOLVED-Need-to-get-name-of-a-USB-flash-drive-device It's also possible to extract this information from the registry, but that's even worse. In HKLM\System\CurrentControlSet\Enum\USB\Vid_&Pid_ there will be one subkey for each unique device, by serial number. If that key has a subkey called "Control", then it is mounted. Then, under: HKLM\System\CurrentControlSet\Enum\USBSTORE you'll find a subkey with the same name as the subkey above. In that key, there will be a ParentIdPrefix that identifies the device. Then, in the list of mounted devices in HKLM\System\MountedDevices you'll see the list of mounted drive letters as \DosDevices\A: \DosDevices\B: One of those values will contain the ParentIdPrefix from USBSTORE. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_claim_interface() error with usbK driver
Markus wrote: > I'm not entirely sure if this topic belongs to this list, but as > it might affect usbK integration, it seems the best place to ask first. > > I've got a custom composite device with 3 interfaces for which I created > a usbK driver package by means of the usbK wizard (interface 0x0). > > When using libusbx, the device works as expected if I'm just accessing > interface 0, however as soon as I try to claim one of the other > interfaces, I receive an error -12 from libusb_claim_interface. > ... > Is it a misconception on my side, that it suffices to have a > driver registered for interface 0x0 of the device? It is a misconception. With the exception of a few device classes where interfaces are grouped (like audio and video), every interface in a USB device stands alone as a separate device, and needs a separate driver. If you register a driver for the composite device (without an interface number at all), then you only need one driver. But if you don't register for the composite device, the system supplies one (usbccgp), which creates N separate subdevices, each of which starts crying for its own driver. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] problem reading configuration descriptor, win xp, selfmade usb device
Arne Pagel wrote: > > currently I have a proplem getting my embedded selfmade usb device > running together with libusbx under win32 (xp) > > I think the major point is that for some reason the configuration > descriptor of my device (16D0:05BE) can not be accesed. > Under Linux I am using this device for yers now with different > versions of libusb without problems. > Also a about an year ago, I got it running on some other xp machine, > but I can't rember the libusb version. > It might be that the usb device it self has some error, which is just > appearing in the xp environment. > > My goal is first to determine if my usb device is the root cause or > the xp environmet. Each version of Windows has grown more and more strict about USB spec compliance. Have you ever run the USB Command Verifier test suite on this device? It does a pretty good job of exercising the generic behavior of your device: http://www.usb.org/developers/tools/ Is your device based on some common USB interface chip? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] problem reading configuration descriptor, win xp, selfmade usb device
Arne Pagel wrote: > No, it is a TI LM3s9B90 micro controller, and to get USB running I used some > lib provided by TI (or Luminary Micro at this Time) > I didn't spend so much time to this in the past since it was running from the > beginning (under Linux). Well, the Luminary/TI/Stellaris USB library is interrupt-driven, and with an 80 MHz core, it ought to be able to keep up, unless you are intercepting the GetDescriptor request in some way. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] problem reading configuration descriptor, win xp, selfmade usb device
Arne Pagel wrote: > That is right, also Usbview doesn't show any Configraution Descriptors, just > Device and Endpoints. The fact that it shows endpoints says that, at SOME point in time, the system was able to read your configuration descriptor. Endpoint descriptors do not exist on their own -- they are part of the configuration descriptor. The device descriptor and endpoint information shown at the top of the usbview output is cached in the kernel -- it's not read from the device. The configuration descriptor it shows does require a hardware response. > I started some test with the USB Command Verifier Tool suggested by Tim and > Indeed it shows some Errors. > I still have to get familiar what the tool is saying to me, up to now I have > 3 Items: > - It says that I have no Configuration and I should have at least One > Configuration > - there is something with some BOS Descriptors, which are not available on > Full Speed, but t least some > error Message should be returned > - I am consuming current, and the Configuration is that I shouldn't > (which is indeed a wrong setting, but I think not the cause) Here's my guess, from a distance, based on almost no data, with large caveats about jumping to conclusions and reading between the lines. My guess is that you are responding correctly at enumeration time, but after your device gets configured once, SOMETHING you are doing in the firmware is preventing the device from responding to another GetConfiguration request. Maybe you are doing too much work in an interrupt handler, so that it can't respond to the request in time. Maybe you are trashing the memory that holds the configuration descriptor. > Now I am wondering if I could at least reproduce what is wrong also on my > linux system, > I have no windows System available where I can work on the Embedded device. > Does anyone know some Linux USB Device Test tool? The USBCV tool actually replaces the host controller driver with a special one that enables the sending of invalid commands and allows for additional instrumentation. As a result, it's tightly coupled to Windows. This page might help you: http://www.linux-usb.org/usbtest/ -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] problem reading configuration descriptor, win xp, selfmade usb device
Xiaofan Chen wrote: > On Fri, Nov 30, 2012 at 3:06 AM, Arne Pagel wrote: >> Anyway, >> here is the output from USBView, with the Configuration Descriptor Flag on. >> (Other devices show something there) >> >> Device Descriptor: >> bcdUSB: 0x0110 >> bDeviceClass: 0xFF >> bDeviceSubClass: 0x00 >> bDeviceProtocol: 0x00 >> bMaxPacketSize0: 0x40 (64) >> idVendor: 0x16D0 >> idProduct: 0x05BE >> bcdDevice: 0x0100 >> iManufacturer:0x01 >> iProduct: 0x02 >> iSerialNumber:0x03 >> bNumConfigurations: 0x01 >> >> ConnectionStatus: DeviceConnected >> Current Config Value: 0x01 >> Device Bus Speed: Full >> Device Address: 0x08 >> Open Pipes: 2 >> >> Endpoint Descriptor: >> bEndpointAddress: 0x81 IN >> Transfer Type:Bulk >> wMaxPacketSize: 0x0040 (64) >> bInterval:0x00 >> >> Endpoint Descriptor: >> bEndpointAddress: 0x01 OUT >> Transfer Type:Bulk >> wMaxPacketSize: 0x0040 (64) >> bInterval:0x00 > You forget to CC the list. Anyway, the USBView > output seems normal and at least your device > enumerated properly. No, it doesn't seem normal! That's the whole point. Go look at a usbview output yourself and you can verify that. The usbview output is in two parts. The output we see up there is all cached in structures within the host controller driver (or maybe the hub driver). None of that required a trip to the hardware. Notice, for example, that there is no interface descriptor -- only the currently open endpoints. With a normally operating device, that output would be immediately followed by the entire Configuration Descriptor, which does require a round trip. The fact that the Configuration Descriptor is missing says that usbview got an error while trying to fetch it. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Asynchronous transfers without C-callbacks
Wolfgang Pupp wrote:
> I've been working with libusbx for some time now --I'm primarily very
> happy with it-- but one design trait gave me trouble: Being forced to
> use C-callbacks for dealing with asynchronous transfers.
> It would be *really* nice if there was a "push style" API one could
> resort to,
It's interesting you would call this "push style"; in my mind this is
"pull style", because I have to pull the events from libusbx, instead of
having the library push them to me.
> like this:
> /* inside the main-loop: */
> libusb_check_events_timeout_completed(ctx, timeout, &evt_cnt);
> for(int i = 0; i < evt_cnt; ++i) {
> libusb_transfer *transfer;
> libusb_handle_next_transfer(ctx, &transfer);
> /* do something with the transfer */
> }
I don't see the point of the added complexity of the event count, which
would be outdated as soon as it was returned. Why not just:
libusb_transfer * transfer;
while( libusb_get_completed_transfer( ctx, timeout, &transfer) ==
some success value )
{
// Do something with transfer
}
In both cases, you'd have to loop back around to check later anyway.
This would not be too hard to add, although I suspect you could do the
same thing yourself with a small C module.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] persisting LIBUSB_ERROR_NO_MEM on burst condition
Mohamed HAMZAOUI wrote: > > From the main thread i call this function every 500micro second on > average : That's way too much overhead. You need to submit larger transfers at longer intervals. For example, think about having 10ms or 20ms kin each request. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] persisting LIBUSB_ERROR_NO_MEM on burst condition
Mohamed HAMZAOUI wrote: > Solution, as pointed out Tim, is to buffer more data in a single > request. It's like nagle algorithm that I will implement, but I think > it is not a good solution in my case. > Firstly, there's several threads that send CAN frames in accordance > with specific conditions... and I should never delay the emission of > any frame. Secondly, A CAN frame has a small size ! Please remember that USB is not an asynchronous bus. Everything is scheduled in advance. No matter how fast you submit your requests, they will all be gathered up and scheduled for the next frame, at the next millisecond boundary. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx and Windows 8 and Windows 8 RT
Xiaofan Chen wrote: > Since WDK 8 will not support Windows on ARM (WinRT) driver > development, I am not so sure how many vendors will really > support WinRT, especially for small device vendors who > want to leverage things like generic HID, no change that > will work now. Yes. For now, if you want to play in the Windows ARM arena, you have to be working with an OEM partner who has a direct relationship with Microsoft. That's the only way to get the tools. > So even though Windows RT seems to support more USB device > than iOS and maybe Android out of the box, Android actually > has less restriction to let users develop their own USB drivers. That's correct. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx and Windows 8 and Windows 8 RT
Pete Batard wrote: > Last time I tried with VS2012, it seemed to produce ARM binaries > alright, but since Microsoft decided to go all Apple in terms of pricing > and control of RT hardware, I doubt there's going to be much point > trying to test on a closed/defective by design platform... This is a nice summary of the situation. I'm especially fond of your phrase "going all Apple" -- I will have to work that into a New Year's Eve party conversation. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Isochronous test problem
Wander Lairson Costa wrote: > I am trying to do a isochronous loop transfer, I can write the data > but I am getting an error when trying to read it. Following are the > logs: Isochronous endpoints have peculiar rules for reading. Each packet in an isochronous transfer maps to one microframe in real time. It's not like a bulk or interrupt transfer where it just hangs around until it's full. If you have 8 packets in your transfer, you'll cover 8 microframes. If the device doesn't send anything in one of those microframes, you'll get zero bytes back for that packet. The endpoint packet size is 32 (in the header), and your request is for 128 bytes, so you should be covering 4 microframes. It's quite normal for one of those packets to fail when the other ones succeed. That what it looks like here -- packet 0 failed, but the other three did not. Error -71 is EPROTO, suggesting a protocol violation. I guess that implicates the firmware. Have you done an lsusb to make sure the descriptors match what you expect? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Isochronous test problem
Wander Lairson Costa wrote: > I observed that benchmark firmware always expects isochronous transfer > of a size multiple of packet size. Is this just a convention on the > firmware or is there something about isochronous that I am missing > out? Isochronous requests are different from other requests. The "multiple of packet size" thing really only applies to isochronous IN requests. The reason is that isochronous data is not packed into your data buffer. Instead, each packet in your isoch request stands alone, and gets mapped directly to a single microframe in time. If your device has an interval of 1, so that you get a shot in each microframe, and you include 16 packets in your request, those 16 packets will span exactly two milliseconds. The first packet gets whatever is read in the first microframe, the second packet gets whatever is read in the second microframe, and so on. So, if your device skips one interval, you will have a gap in your buffer. If your device sends short data in one interval, again you will have a gap in your buffer. Remember, in the USB protocol, a device is never told how large the read buffer is. All it sees is a signal that says "GO!". Thus, at every interval, the device has the right to send up to its maximum packet size. As a result, your buffer has to be ready to accept that much data, every time. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Isochronous test problem
Tim Roberts wrote: > Wander Lairson Costa wrote: >> I observed that benchmark firmware always expects isochronous transfer >> of a size multiple of packet size. Is this just a convention on the >> firmware or is there something about isochronous that I am missing >> out? > Isochronous requests are different from other requests. The "multiple > of packet size" thing really only applies to isochronous IN requests. > The reason is that isochronous data is not packed into your data > buffer. Instead, each packet in your isoch request stands alone, and > gets mapped directly to a single microframe in time. If your device has > an interval of 1, so that you get a shot in each microframe, and you > include 16 packets in your request, those 16 packets will span exactly > two milliseconds. The first packet gets whatever is read in the first > microframe, the second packet gets whatever is read in the second > microframe, and so on. I see now that you're doing a full-speed device, so you should modify that paragraph to eliminate the mention of "microframes". Instead, each packet in your isoch request stands alone, and gets mapped directly to a single frame in time. If your device has an interval of 1, so that you get a shot in each frame, and you include 16 packets in your request, those 16 packets will span exactly 16 milliseconds. etc. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Isochronous test problem
Wander Lairson Costa wrote: > > AFAIK, if the host request less than a packet size for bulk or > interrupt and the data packed is larger than that, the host will > receive an error. Yes. That's called "babble", and it is a protocol violation. The device can actually trample over the top of the device that was scheduled to immediately follow it. A USB microframe is all scheduled in advance based on the requests the host controller had at the time. The host controller allocates the time very carefully, and assumes everyone behaves. If this babble happens to occur at the end of a microframe, so that it steps on the frame boundary, it can actually cause the upstream hub to shut down. I've seen it happen. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Isochronous test problem
Xiaofan Chen wrote: > For isochronous OUT request, since the host know (at least it > should know) the size of each packet, so this is not an issue, right? Yes. >> So, if your device skips one interval, you will have a gap in your >> buffer. If your device sends short data in one interval, again you will >> have a gap in your buffer. > How does the host program deal with this kind of gap in the buffer? The host program has to reconstitute it. If you need a packed buffer (as most programs do), you end up with a loop like this: buffer pointer = 0 for( each packet ) if( there is data in this packet ) copy packet length bytes to buffer pointer buffer pointer += packet length > So it is clear that the host program should use multiple of the > isochronous IN endpoint max packet size as the read buffer. > > But isn't it the same for interrupt transfer or bulk IN transfer in the > case you do not know the expected data the device will send? > In that case, you will have to use multiple of the IN endpoint > max packet size as the read buffer. You are absolutely correct. *Every* IN request, regardless of pipe type, should always be a multiple of the maximum packet size. > Right? On the occasion > that you know exactly how many data to expect, then of course it > is okay to use the that. Yes, assuming everything always goes as planned... It doesn't cost anything to round your buffer sizes up in EVERY case. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] WinUSB Pipe Policy ALLOW_PARTIAL_READS and USBD_SHORT_TRANSFER_OK
Alan Stern wrote: > ALLOW_PARTIAL_READS is Microsoft's way of letting programmers use the > USB protocol in ways it was not intended to be used. It specifically > evades the convention (which is documented in the spec) that bulk > transfers are complete when either the desired number of bytes have > been sent or when a short packet is received, whichever comes first. In Microsoft's defense, this is implemented in the WinUSB wrapper DLL, not at the USB kernel level. It's a convenience. The DLL turns this into spec-compliant requests at the kernel level. > This feature is not available on Linux, or presumably on other > platforms. I don't see any reason why libusb or libusbx should support > it. I agree. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] WinUSB Pipe Policy ALLOW_PARTIAL_READS and USBD_SHORT_TRANSFER_OK
Xiaofan Chen wrote: > On Fri, Jan 25, 2013 at 2:40 AM, Tim Roberts wrote: >> In Microsoft's defense, this is implemented in the WinUSB wrapper DLL, >> not at the USB kernel level. It's a convenience. The DLL turns this >> into spec-compliant requests at the kernel level. > That is interesting to know. > > Just wonering how does the DLL do to turn this into a spec-compliant > requests at the kernel level? They just make normal full-packet requests, then pack any short packets into the output buffer and continue reading, instead of terminating the request at the first short packet. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Windows: libusb_claim_interface fails on 1.0.13 and higher
Eric Lundby wrote: > The main reason for not using the Microchip provided package is we > don't want our end users to have to specify a com port to be able to > use our device. Then why would you make this CDC ACM, instead of just using a custom interface that you control completely? > Being able to use the same code base (or close to it) > across platforms was also an enticing factor. Let me know if you think > I am off base with this. How are you going to avoid specifying a COM port across platforms? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Windows: libusb_claim_interface fails on 1.0.13 and higher
Eric Lundby wrote: >> How are you going to avoid specifying a COM port across platforms? > Not sure how to take this. Sounds a bit cynical. That was not my intent at all -- I must have worded my question poorly. Allow me to try again. > I'm currently using > libusb/WinUSB on Windows to communicate with my device w/o specifying > a COM port. Considering COM ports are in general a Windows only topic, > I guess this is already accomplished. Your second sentence is not true, and that was my original point. If you have a device that gets exposed as a virtual COM port, it gets assigned a COM port number on all of the operating systems. Windows calls it COM4 (or whatever). Linux has a different naming convention, but the number is still there. You were objecting to dealing with the COM port number on Windows, but the same problem exists everywhere. > However, I do appear to be able to accomplish what > I want using bulk transfers via Libusbx. Are there major issues with > this that I'm not aware of? I'm with Alan. If it works for you, bulk traffic is the most common kind. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
GORAN RADIVOJEVIC wrote: > > My previous experience with USB was PIC 18F4550 and HID device so > sorry if I ask something obvious. > I have a problem with AVR32 UC3A0512 device and Vendor class. Hardware > is EVK1100 clone (WaveShare EVK3A). > I manage to build firmware with AtmelStudio 6 and install driver > (libUSBwin32 or libUSBK). Device is visible by > Windows without any warning. When I try xusb.exe from example folder > my device is listed with two interfaces > (0 without endpoints and 1 with two endpoints: interuput and isochronous). Is it really two interfaces? Or is it one interface with two alternate settings? There is a big difference. > In my host PC application when I try > to set active interface 1 I got error (from UC3A debug printout > message is USB_REQ_TYPE_STANDARD). What was the error? > From what I read my host app must activate Vendor device by sending > USB_REQ_TYPE_VENDOR request with > appropriate alt configuration number? No. Vendor requests have nothing to do with vendor-class devices. You can have vendor requests even on standard class devices. My blind guess is that you were trying to claim interface 1, when you should have been claiming interface 0 with alternate setting 1. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [SPAM] - Re: opening generic device EP in bulk transfer - difference between Linux and Windows - Email found in subject
Wim De Kimpe wrote: > Going to try it now with 0x81. > could you please tell me why nEndpoint needs to be 0x81 rather than 0x01, and > on EP2 this needs to be 0x02? Endpoint 0x01 and 0x81 are two entirely different and unrelated endpoints. Endpoint 0x01 happens to be an OUT endpoint. Endpoint 0x81 happens to be an IN endpoint. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
Is someone actually coding up a first-draft hotplug solution to do some experimentation? There are two ways to design standard libraries. One way is to take software that someone has been working on and using, clean it up, and release it. This is the Linux model -- more or less how libusb* has operated throughout its life. This is also how the original C standard was created -- they standardized existing practice. The other way is to have design committees debate arcana endlessly for months at a time, and then once the arcana are settled, go implement something to the spec. This is the way the C++ standard committees have worked since the original spec -- specify innovation. It looks to me like the current hotplug debate is using the latter approach. I'm not sure that's a path to success. Hotplug is a minefield; I'm afraid we're going to find that the real world does not so neatly fit the nice specification. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [SPAM] - Re: opening generic device EP in bulk transfer - difference between Linux and Windows - Email found in subject - Email found in subject - Email found in subject
Wim De Kimpe wrote: > Another question: if kernel attach and detach only has effect in Linux, why > does libusb_kernel_driver_active(handle,0) > return true on Windows? Shouldn't it return false then? It's not a Boolean. It returns LIBUSB_ERROR_NOT_SUPPORTED. If you're checking for zero/not-zero, that will compare as true. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] opening generic device EP in bulk transfer - difference between Linux and Windows
Wim De Kimpe wrote: > I have been doing some more experiments. Apparently, if I increase the > nTimeout to 2000, and I use libusb_bulk_transfer then I can also communicate > with the device in Linux. > > So I do not know exactly what this is caused by. From the documentation, I > also do not understand clearly what the difference between the bulk and the > interrupt transfer is. To put it succinctly, you use an interrupt transfer with an interrupt endpoint. You use a bulk transfer with a bulk endpoint. You use a control transfer with a control endpoint. You use an isochronous transfer with an isochronous endpoint. The choice is determined by the descriptors, not by the application writer. (From a driver perspective, a bulk transfer and an interrupt transfer are identical. In Windows, the two actually share the same request code. The only difference is the way the host controller driver schedules them.) -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
GORAN RADIVOJEVIC wrote: > > I made typo error: my USB device have only one interface with one > Alternate settings (my first attempt was > HID+Vendor, HID part working correctly). At the moment I don't have > CPU card (only bare motherboard) so > I can't send you exact Xusb.exe printout. I hope in the next few days > spare CPU card will be returned to me. > In the meanwhile I have question about exact procedure to activate > Vendor class. Is this correct order: > 1. find device by VID and PID; > 2. claim interface; > 3. set configuration (is this step necessary?); > 4. set Alt. configuration; > 5. send/receive data through endpoints. Setting the configuration determines what the interfaces are, so if you do SetConfiguration, you must do that before claiming the interface. There is no such thing as an "alternate configuration". Claiming the interface will set alternate setting #0, so you only need to set the alternate setting number if you have more than one, and you will (almost) never have more than one unless you have isochronous pipes. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
GORAN RADIVOJEVIC wrote:
>
> interface[0].altsetting[0]: num endpoints = 0
>Class.SubClass.Protocol: FF.FF.FF
> interface[0].altsetting[1]: num endpoints = 6
>Class.SubClass.Protocol: FF.FF.FF
>endpoint[0].address: 81
>max packet size: 0040
> polling interval: 01
>endpoint[1].address: 02
>max packet size: 0040
> polling interval: 01
>endpoint[2].address: 83
>max packet size: 0040
> polling interval: 00
>endpoint[3].address: 04
>max packet size: 0040
> polling interval: 00
>endpoint[4].address: 85
>max packet size: 0100
> polling interval: 01
>endpoint[5].address: 06
>max packet size: 0100
> polling interval: 01
What are the types of the pipes here? Bulk pipes in full-speed are
limited to 64 bytes, so those last two (at least) must be either
interrupt or isochronous. Is it possible you don't have enough
bandwidth to reserve that much?
> When libusb_set_interface_alt_setting command is send on my serial
> console instead expected USB_REQ_TYPE_VENDOR received
> is USB_REQ_TYPE_STANDARD with alt settings set to 0:
>
> udi_vendor_disable alt_settings 0
> udi_vendor_setup_out
> USB_REQ_TYPE_STANDARD
You are making the mistake of assuming that "vendor class device" and
"vendor requests" are somehow related. That is simply not true, and you
must unlearn that. There are two bits in the request code that identify
whether the request is a "standard" request, or a "class" request, or a
"vendor" request. All possible standard and class requests are spelled
out in the USB specs. Vendor requests can be anything at all. ANY type
of device can have its own vendor requests.
> ...
> This is from udi_vendor_setup function generated by Atmel ASF 3.5.0:
> ..
> if (Udd_setup_is_out())
> {
> if ((Udd_setup_type() == USB_REQ_TYPE_VENDOR)
> && (udd_g_ctrlreq.req.bRequest == 0)
> && (0 != udd_g_ctrlreq.req.wLength))
> {
> return UDI_VENDOR_SETUP_OUT_RECEIVED();
> }
> return false; // Not supported request
> }
>
> Clearly this function only expect USB_REQ_TYPE_VENDOR request with
> altsettings set to 1.
Your conclusion is not supported by the code. Your firmware probably
has a section of code that says:
if( request type is "standard" )
go handle standard requests;
else if( request type is "class" )
go handle class requests;
else
go handle vendor requests;
and the code above is probably in the "vendor request" section.
It is clear that your firmware handles the SetInterface request. The
"set alternate setting" function sends the EXACT SAME REQUEST. There's
just one field that identifies the alternate setting to enable.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
GORAN RADIVOJEVIC wrote: > > Few minutes after I send previous message I remove last two endpoints > (Iso) and now SetAltInterface working as > expected (in libusbx and libusbK). That's revealing. Are you quite sure that your Atmel device supports isochronous endpoints? Which Atmel chip are you using? > Now I have working Interrupt (for commands) and Bulk endpoints (audio > stream), both 64 byte but with Iso EP problems returns. As I recall, you had two interrupt endpoints with 64-byte packets and two isochronous endpoints with 256-byte packets. Right? That's a total of 640 bytes per frame. That's 50% of the total available bandwidth for full-speed devices. If you had any other interrupt or isochronous devices reserving bandwidth, that could have been enough to cause your allocation to fail. Did I already ask if you were you doing this in a virtual machine? Do you happen to have a video camera set up? > I managed to loop through uC stereo audio stream 48k/24bit using Bulk > transfer but on higher rates audio is choppy. Atmel controller is only > full speed capable, is this my problem? Bulk gets whatever bandwidth is left over after all of the other reservations. The timing is unpredictable. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] OT driver signing in Win7 / Win8
Kustaa Nyholm wrote: > sorry to abuse this list with OT but since > I know a few members know about the driver > signing so I was hoping for a helpful word. > > I'm using a home brew USB CDC AMC virtual > serial port like device on Windows with > the Windows serial.sys driver and my own > .inf file. > > Now will this approach work out of the box > in W7 / W8 and if not what can / should I do? There are two signing requirements in Windows. The KMCS (kernel mode code signing) requirement will prevent a driver from being loaded unless the driver or the driver package is signed. This check is done every time the driver loads, but is only done on the 64-bit systems. Since you are using Microsoft's driver, which is already signed, this is not a problem for you. The PnP check is done when your driver is installed. This is what puts up the dreaded "unsigned driver!" warning, or the less dreaded "do you trust this publisher?" warning. This check is done on all systems, but ONLY at installation time, and as long as the user agrees to the dialog, things proceed smoothly. So, as long as you know you'll get the "unsigned driver" warning, your driver should work fine. Note that Windows 8 now requires a CAT file for all driver packages. Look up the "inf2cat" tool. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] OT driver signing in Win7 / Win8
Xiaofan Chen wrote: > On Thu, Feb 28, 2013 at 2:32 AM, Tim Roberts wrote: >> Note that Windows 8 now requires a CAT file >> for all driver packages. > Does this cat file needs to be signed? Where is > this documented? I couldn't find it written down. I learned it empirically. > I find one info here which states that the cat > file needs to be signed for Windows 8 64bit. > Is that true? To be honest, I don't know, because I always sign both the SYS and the CAT. In previous systems, one or the other had to be signed in order to pass 64-bit KMCS, but you had to sign the CAT file in order to change the "unsigned driver" warning to the "do you trust this publisher" warning. Thus, there has always been a rather strong incentive to sign the CAT file, assuming you shipped one. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libftdi async transfer
Xiaofan Chen wrote: > Ref thread: > http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00157.html > > libftdi1 git repo source: > http://developer.intra2net.com/git/?p=libftdi;a=blob;f=src/ftdi.c > Just need to read the following functions: > ftdi_write_data_submit(), ftdi_read_data_submit() and > ftdi_transfer_data_done(). > > I need a sanity check whether the assesment that current libftdi1 codes > will limit to only have one outstanding async read request. Is this > correct? I admit I have not a good understanding of libusbx's > async API and event handling. I don't see anything in that code that serializes read requests. > If not, then what could be the problem? That FTDI code does set the default read buffer size to 4096. That's settable, using ftdi_read_data_set_chunksize. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
GORAN RADIVOJEVIC wrote: > uC is Atmel UC3A0512. According to Atmel docs USB controller is Low/Full speed > device capable to do ISO transfer with up to 256 bytes for endpoint > (wizard created INT and BULK endpoints 64 byte and ISO 256 byte). After many > experiment I can make it work with only 64byte for ISO plus 64byte INT but > without BULK. Maximum average speed is around 670KB/s for BULK write > and only 58KB/s for ISO write (libusb-win32 1.2.6.0 driver and LibUsbDotNet > Benchmark example). If your iso packet size is 64 bytes, then you obviously can't do any better than 64kB/s, but you should be able to do exactly 64kB/s. > I have a question: is ISO transfer works with libusbx or not? Yes. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Feature request: plug-in notification.
Bent Bisballe Nyeng wrote: > In the time I have been using libusb there has always been a single > feature that I was missing: The ability to get a notification when a new > device is connected (or disconnected for that matter), and thereby > remove the need for continuous rescans of the usb bus. > > In a specific project that I once made a rescan actually interrupted an > active filetransfer on a MSD. Probably due to a bug in the MSD (some > custom thiny, not made by me) but it still points to the fact tha a bus > rescan is a quite "agrssive" thing to do in order to simply find out if > a device has been connected. Well, I guess this depends on your level of abstraction. SOMEONE has to rescan the bus. In Windows, for example, you can subscribe to a "device changed" event from the PnP provider. However, that merely tells you that, somewhere in the system, some bus driver has reported a change in its set of child devices. The only way to find out WHICH devices came or went is to go rescan the bus you're interested in and compare the current list to your own list. Further, the notion of reattaching to a lost device is a tricky one. You're talking to a driver. That driver happens to be assigned to a particular hardware device. When that hardware device goes away, that driver instance is unloaded (or at least orphaned). When that hardware device comes back, it's seen as a brand-new device, and gets a brand-new driver set, with absolutely no connection to the orphaned driver you were talking to before. Certainly at the kernel level, there is simply no way to move those old driver connections to the new driver. Someone in user mode has to be using heuristics to make that connection. Some apps wouldn't want to be automatically reconnected. Thus, this ends up being an application-specific process. This is why hotplug has not already been added to libusb/libusbx. You have suggested a mechanism that would work for your application, but it's not at all clear that it is the right solution for every application. It's a very tricky problem. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Samples: Add FX3 firmware upload support for fxload
Pete Batard wrote: > Absolutely. It shouldn't be that difficult to produce a CY7C68013A like > FX3-based board, and sell it for at least an order of magnitude less > than the CYUSB3KIT. I don't know about that. The chips themselves are still running about $30 in volume. Plus, the circuit board and connector tolerances are a LOT less forgiving at 5 GHz than they are at 480 MHz. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Add HID capability detection for all backends
Hans de Goede wrote: > > Let me try to explain why, just as there is a huge difference between > internal functionality and something only available when doing extra > stuff outside of libusbx, there is a huge difference between being > able to access a device without detaching the driver, and accessing it > with detaching the driver. Lets say we've a keyboard with some extra > functionality, ie an lcd display, or whatever. And the functionality > is available through custom hid reports on the same hid interface as > where the actual keyboard functionality is. Then surely having a tool > for the lcd display detaching the driver is a bad idea, since that > will mean that the lcd can now be used, but at the cost of loosing the > keyboard ... I'm not sure I buy that argument. Everything on that keyboard HID interface should be keyboard HID related. If the LCD isn't keyboard related, then it should be on a separate interface. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Fix HID descriptor creation code in Windows backend
Toby Gray wrote: > Hi, > > I've been investigating a STATUS_STACK_BUFFER_OVERRUN (0xc409) > exception when running the latest libusbx in Windows XP. I believe it's > due to a bug in how the fake USB descriptors for HID devices are > created. The location of the second endpoint was being calculated > incorrectly in _hid_get_config_descriptor. > > I've attached a fix for it. The only thing I'm not entirely happy with > about the fix is the use of ed2 as a variable name, feel free to suggest > a better alternative. Do we need the additional pointer at all? It seems like it violates 3rd Normal Form. Why not just advance the pointer in place? ed = (struct libusb_endpoint_descriptor *)((unsigned char *)ed + LIBUSB_DT_ENDPOINT_SIZE); -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] OT Right clickable .inf file for usbser.sys on Win7
Orin Eman wrote: > > > I didn't think right-click/Install worked for driver inf files. It > never has for me anyway. Specifically, right-click install cannot be used for plug-and-play driver packages. All that a right-click install does is run the section called [DefaultInstall]. You can copy files, create services, and create registry entries, but it will not associate your driver with the device you're trying to drive. Right-click installs can be used for so-called "legacy" drivers, but it doesn't do anything that can't also be done with a batch script or a trivial C program. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] How libusb(x) know which interface to talk to
Wander Lairson Costa wrote: > You mean, I cannot have endpoint 1 both on interface 0 and interface > 1? I was not aware of that. Correct. Endpoints are global, and interfaces are just a software mechanism for collecting the endpoints into related groups. Packets on the USB wire do not have an interface number in them. All they get are an endpoint number. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Strange warning when enumerating device
Xiaofan Chen wrote: > Somehow I got a strange warning under Windows 8 x64. The device > is a USB composite device (Amontec JTAGkey-2), both interface > use the WinUSB driver installed using Zadig. Not so sure if this > has something to do with the fact this is a virtual machine (using > VirtualBox under Mac OS X). I'm a little confused here. Do you have one driver matching the composite device, or do you have two drivers, one for each interface? For example, in this snippet: > Opening device 0403:CFF8... > libusbx: error [init_device] device > '\\.\USB#VID_0403&PID_CFF8&MI_01#6&222886B8& > 0&0001' is no longer connected! the "MI_01" implies that you have a separate driver for each interface. In that case, I don't understand the log entries about claiming interface 0 and interface 1. When you have one driver per interface, the composite driver rewrites the descriptors so that each function driver sees a single interface device. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Strange warning when enumerating device
Pete Batard wrote: > On 2013.04.08 19:12, Tim Roberts wrote: >> For example, in this snippet: >>> Opening device 0403:CFF8... >>> libusbx: error [init_device] device >>> '\\.\USB#VID_0403&PID_CFF8&MI_01#6&222886B8& >>> 0&0001' is no longer connected! >> the "MI_01" implies that you have a separate driver for each interface. >> In that case, I don't understand the log entries about claiming >> interface 0 and interface 1. > That's just how xusb is set [1]. It'll always try to claim all > interfaces. Yes, but if this is a driver matching MI_01, then there will only be one interface, numbered 0. The usbccgp driver, which owns the composite device, rewrites the configuration descriptor. When the MI_01 driver goes to read the configuration descriptor, it will only contain interface 0 (which is really interface 1). The other interface will simply not appear. That's my confusion. If libusbx has (also) claimed the composite device, then I believe this. If not, then it shouldn't be possible for the MI_01 driver to learn or access the other interfaces. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC] Windows event handling improvements
Toby Gray wrote: > We've been looking into the performance of the Windows desktop and > Windows CE versions of libusbx compared to Linux on the same hardware. > The event handling in Windows and Windows CE appears to take > considerably longer than for Linux. > > This is understandable given the way that the windows backends need to > pretend to have fds for the core of libusbx to process. Can you share with the performance numbers you have and a short description of how you got them? You've made me really curious here. Intuitively, I would have guessed that whatever fd futzing was going on was absolutely insignificant when compared to the overhead of user/kernel transitions and user event processing. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC] Windows event handling improvements
Toby Gray wrote: > The only numbers which would probably make sense to others are that we > noticed that there was a long time between the short packet of the end > of a transfer and the host issuing the next IN token for that endpoint. > The gap is multiple milliseconds in length on WinCE, but not when the > same board is running a Linux image. There must be about a dozen causes behind that, and Libusbx's event handling has to be about #11 on that list in terms of importance. My guess is that the #1 cause is the design of the USB host controller driver. The WinCE USB stack is primitive. It hasn't received anywhere NEAR the attention or the real-world stress testing that either the Windows or the Linux USB stack has had. I suspect, for example, that it only asks for an interrupt at end of frame, and it submits the next frame's schedule immediately. In that case, unless you have multiple concurrent requests, you will NEVER get more than one request every two milliseconds. It's impossible, and there is nothing you can do in user-mode code to fix that. > We have finally got around to making sure that we have multiple > concurrent bulk in transfers to eliminate this latency. I know that we > should have been doing this from the start, but higher priority things > had always got in the way and the event handling in Linux was fast > enough for us to get away with it. Sometimes. Even when it works, it's very delicate, and highly dependent on system load. It wouldn't take an awful lot of competing CPU activity to make it break on Linux as well. The ONLY robust solution is multiple pending requests. > So it's now a case of reducing the CPU time that we see in the > processing of events. We've not drilled down fair enough yet to discover > exactly where the time goes. You are free to chase this line of investigation if you want, of course, but it is my educated opinion that you are wasting your time. You are solving a problem that simply cannot be solved in the general case. You are bucking Amdahl's Law here. The libusbx event handling is such a small part of the problem that, even if you completely eliminated all of the libusbx overhead, you would have improved the overall performance so slightly that it makes no difference. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] winusb, can't open device
Daniel Goertzen wrote: > I have libusbx compiling under cygwin now and can look at the device > descriptors for all attached devices, but I cannot libusb_open() my > device. The error given is -12 (LIBUSB_ERROR_NOT_SUPPORTED). > > I ran zadig and bound my device to WinUSB, but still no luck (I have > to admit, I don't exactly understand how that all works). > > One thing of note, zadig shows the WinUSB version number as > 6.1.76000.16385, whereas the version number on my Windows 8 system > is 6.2.9200.16384. 7600 is the master build number for Win 7. 9200 is the master build number for Win 8. The WinUSB installation process only installs the DLL and driver if the version is newer than what's already on the system. > Also of note, I am trying to connect to a LPC11u24 with unproven > firmware. The uC is seeing GET_DESCRIPTOR and SET_ADDRESS commands > and nothing else. My device descriptor is below. What does the configuration descriptor look like? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bulk transfer queueing order problem
qse drf wrote: > > I am trying to communicate with a device via a simple bulk transfer > protocol under 64-bit Win7, it doesn't require high bandwidth. I > don't have access to to the device firmware, but I know it is working > properly because I have some software that communicates with it > correctly under WinXP. Well, just because it happens to work in one location does not necessarily mean it is working properly. However, in this case, I don't think that's relevant... > I installed libusbx 1.0.15 using the WinUSB driver, and it works until > command 2, when I get an error response. I used a USB sniffer and > discovered that I'm getting a sequence like: > > [reset device] > > [initiate communication] > bulk out - 16 bytes start command > bulk in - 16 bytes ready response > > [start processing data] > bulk out - 2KB command 1 with data followed immediately by command 2 > with it's data > bulk in - 16 bytes command 1 response (OK) > bulk in - 16 bytes command 2 response (error) > > Looking deeper, I noticed that the 1KB transferrs should consist > of two 512byte packets followed by a zero byte packet. What I'm > seeing are four 512 byte packets. I'm using synchronous API calls > so I expected each of the transfers to complete before the next call, > but it seems that the data is being queued somehow and sent as a > single concatenated transfer so the device doesn't recognize the > second command. Well, wait a minute here. If you are waiting for the "bulk in" in the middle, how could you possibly get the sequence you just described? You wouldn't even send the second 1KB until you'd read the first response. Are you sending the two "bulk out" calls consecutively, without waiting for the "bulk in" in the middle? If so, then what you show is quite possible. There is a flag to ask for a zero-length terminator (LIBUSB_TRANSFER_ADD_ZERO_PACKET), but I'm not sure it's available on Windows. You should, however, be able to do another bulk out transaction with a zero-length buffer. So, send 1K, send 0, send 1K, send 0. This is a tricky problem. USB allows arbitrarily large "transfers", terminated by a short packet. The operating systems libusb supports do not all support arbitrarily large memory buffers. So, if you want to send a 16MB transfer, you can't do that in a single call. You have to chop it up into a series of multiple-of-512-byte calls. Because of that, libusb cannot tell whether your 1K transfer is a single transfer, or part of a larger transfer. It cannot know when it should send a ZLP. > I also tried using the WinUSB API directly, but it only finds the > interface with endpoint 0, rather the interface the bulk endpoints, so > I have been unable to even establish communication with the device. > I'd rather use libusbx, but WinUSB will be fine if I can figure out > how to get a handle to the bulk endpoints. Do you actually have multiple interfaces? Did you write your INF to match the composite device, or did you match the specific interface you want (with #MI_01, for example)? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bulk transfer queueing order problem
qse drf wrote: > I just installed the driver with Zadig. Yes there are two interfaces, > interface 0 has a single endpoint and interface 1 has the two bulk end > points. What confused me was that using libusbx I am able to use the bulk > endpoints, but with the WinUSB API I can't. I don't know how Zadig creates the INF file. Windows allows you to write an INF file that claims the entire device: %MyDeviceDesc% = install.section, USB\VID_1&PID_ With that, you can get a handle to the other interfaces using WinUSB_GetAssociatedInterface. But Windows also allows you to write an INF that only claimes one interface: %MyDeviceDesc% = install.section, USB\VID_1&PID_&MI_00 or %MyDeviceDesc% = install.section, USB\VID_1&PID_&MI_01 If you use that option, then the system rewrites the descriptors so that your driver doesn't even KNOW there is a second interface. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
Hans de Goede wrote: > Sorry no code (yet), as I would first like to get some buy in for > the concept before spending time on coding this. > > For apps which show a list of usb devices to the user, it is useful > to have some userfriendly description of the device to show. > > I've code for this in spice-gtk, which I think really should be in > libusb, as it is useful for other apps too. > > Therefor I would like to suggest to add these functions: > > char *libusb_get_vendor_string(libusb_device *device); > char *libusb_get_product_string(libusb_device *device); I'm not fond of this concept. In USB terms, the "vendor string" is the string descriptor designated by iManufacturer in the device descriptor, and "product string" is the string descriptor designated by iProduct in the device descriptor. This is extending the meaning of those terms in a possibly unexpected way. Apps that need the usb.ids lookup should go do the lookup. Beyond that, this becomes a maintenance headache. However, I may not be in the majority. I also think the project will come to regret the introduction of libusb_strerror. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bulk transfer queueing order problem
qse drf wrote: > I checked the inf created by Zadig, and it claims the entire device. I > assumed this had to be the case, since libusbx is able to acces both > interfaces. You can modify that INF... > I'm going to keep trying to figure out how to use WinUSB directly. WinUsb_GetAssociatedInterface should be the magic you need. > So this seems like a bug in libusbx that it doesn't seem to honor the > synchronous API expectations in this case, as evidenced by the concatenating > of the > buffers from multiple calls. Or am I missing something? It's still hard for me to figure out understand how this could happen. If you don't SEND the second buffer until you have RECEIVED the first result, how could you even get the first result unless the first buffer was already gone? -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] RFC: Add libusb_get_vendor_n_product_string function
Hans de Goede wrote: > I would like to give libusb using applications to os cached string > descriptors, so that those can be accessed without the need to open a > device and do io on it. The device is already open, because your API requires a libusb_device, right? So, you're saving the cost of one device descriptor read, and two string descriptor reads. I don't know. The API is well-defined and simple enough, but it doesn't require any information private to the library. Would it be used often enough to justify including it in the library, as opposed to having it in a code sample? I can't judge that. I am, admittedly, a minimalist. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
