Re: [Libusbx-devel] [libusbx] persisting LIBUSB_ERROR_NO_MEM on burst condition
Mohamed HAMZAOUI wrote: Is this a bug on the libusb/WinUsb or a limitation ? Yes, I consider it a bug. Others might not. //Peter -- 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
Pete Batard wrote: We do have a maximum limit on the number of (fake) fds Why is that? Are there considerations (timing? something else?) related to asking Windows for memory as needed vs. using the current fixed size internal array? Thanks //Peter -- 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] problem reading configuration descriptor, win xp, selfmade usb device
Arne Pagel wrote: As far as I understood libusb_get_config_descriptor gives my just cached values, can I force this function to perform an actual read from the Hardware? No, but libusb_get_descriptor() will do a hardware access. char buf[64]; libusb_get_descriptor(dev, LIBUSB_DT_CONFIG, 0x00, buf, sizeof(buf)); 0x00 is the index of your configuration descriptor. Note that this index is a simple increasing number, and not bConfigurationValue. //Peter -- 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] How to unload libusbx dll?
therau2000 wrote: libusb-1.0.dll is getting loaded by the interface class with the following command: MyLib libUSB = (MyLib) Native.loadLibrary(usb-1.0, MyLib.class); I don't even know what programming language that is? :\ I need to unload libusb-1.0.dll to load another one. Question: How can I unload libusb-1.0.dll while keeping my program running? I guess it's possible to do something like that on Windows too, but you should ask in another forum in order to get a useful reply. The issue isn't specific to the particular library that was loaded, it's a general question about the programming language that you're using, so look for a forum somewhere for that language. //Peter -- 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] How to unload libusbx dll?
therau2000 wrote: libusb-1.0.dll is getting loaded by the interface class with the following command: MyLib libUSB = (MyLib) Native.loadLibrary(usb-1.0, MyLib.class); I don't even know what programming language that is? :\ Fair enough. It is Java. Ok. I googled: http://www.google.com/search?q=java+native+loadlibrary The first hit seems to be the relevant documentation, for JNA. I guess you know it inside out. The closest thing to unload seems to be the two variants of unregister(), but there's no saying if that will indeed unload the library or what it does. I think you have to look for some JNA experts.. //Peter -- 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] Example udev rules file
David Grant wrote:
Rebooting is necessary for the add user to group change to take effect.
Once the user has been added to the group, it's very easy to upgrade
a running shell to use the new gid:
exec su ${USER}
(What it does is of course to *replace* the current shell with a new
shell, but beyond command line history not neccessarily making it
across the difference is not very noticeable.)
//Peter
--
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] Bug in get_string_descriptor?
Stefano Di Martino wrote: What now? My program has to run under windows. If you want to communicate with the HID class interface then I suggest to try out HIDAPI. HIDAPI was created specifically to abstract OS-native HID class APIs on Linux, Windows, and Mac OS X. While the Windows-specific HID class code for emulating USB transfers over HID in libusbx does use the same OS-native API as HIDAPI (maybe even some code from HIDAPI?) it isn't (currently) as portable. I don't know what the longer-term plan in libusbx is regarding HID class support. One idea would be to integrate HIDAPI wholesale in order to emulate USB transfers over HID also on Linux and OS X. I don't believe there were suggestions in any direction so far, but I think using more of HIDAPI in libusbx would be a logical extension. //Peter -- 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] Bug in get_string_descriptor?
Pete Batard wrote: I don't believe there were suggestions in any direction so far, but I think using more of HIDAPI in libusbx would be a logical extension. Considering that libusbx is the lower level library here, theoretically, the most logical thing would be for HIDAPI to rely on libusbx rather than the opposite The theory in this case is just that, theory. Since libusbx replicates what HIDAPI (and libusb-win32) does, and then adds onto that, libusbx is indeed higher level than HIDAPI. unlike libusb, we don't see it as beneficial to force users to go through 2 libraries when one should do. That is confusing. HIDAPI doesn't depend on libusb. HIDAPI can optionally use libusb, but that's only useful on old Linux systems where the OS-native HID API was insufficient. //Peter -- 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
Xiaofan Chen wrote: You need to fork libusbx and create your own SCSI Pass Through backend by yourself if you really want to use libusbx. On the other hand libusbx already does this for HID class, so I don't see why mass storage would be less worthy. therau2000 wrote: Before I tried to use libusbx, I investigated (and many times unsuccessfully tried) just about every USB library I could find. You were unsuccessful because you're trying to solve what is sometimes called an X-Y problem. You want X but you're trying to accomplish it by doing Y. If you want to send raw SCSI commands to a storage device then you need to look at what is available to accomplish this in a portable way. All USB libraries have failed for you because your problem actually is not about USB. This is all assuming that it is indeed raw SCSI commands that need to be sent to the device. I don't know that for certain, but it seems highly likely. I would not spend any more time on the USB domain, and instead look at the storage subsystem and SCSI domain. //Peter -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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: You need to fork libusbx and create your own SCSI Pass Through backend by yourself if you really want to use libusbx. On the other hand libusbx already does this for HID class, so I don't see why mass storage would be less worthy. In that case, will you please add SCSI Pass Through capability to libusbx? I won't, but maybe someone else will. You can wait for that, or you can do it yourself (or of course find someone to pay). If you want to send raw SCSI commands to a storage device then you need to look at what is available to accomplish this in a portable way. All USB libraries have failed for you because your problem actually is not about USB. This is all assuming that it is indeed raw SCSI commands that need to be sent to the device. I don't know that for certain, but it seems highly likely. Sending raw SCSI commands is the conclusion you experts concluded as the most likely possibility. I had no idea. Before choosing a tool I think you should get to the bottom of what you actually need to do, in terms of operating system interaction. I would not spend any more time on the USB domain, I am NOT giving up on libusbx! But unless what you need to do is one of the things it is intended for then it is not a very good choice of tool for solving your problem. As a matter of facts, I do need libusbx for certain functions... What are those functions? I believe it is a great project and it is easy to use the API, even from Java. I would rather have only ONE library to deal with, and that is libusbx. It's great that you like the libusb-1.0 API, but why spend more time trying to use it if it doesn't do what you need? That's a confusing approach. and instead look at the storage subsystem and SCSI domain. Where would you suggest I look? I'm afraid I don't have a suggestion for a library that abstracts raw SCSI commands across many different systems. In any case, the very first thing I suggest that you do is to get to the bottom of what exactly you need. While that is still unclear it's much too early to consider individual tools. //Peter -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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: In that case, will you please add SCSI Pass Through capability to libusbx? I won't, but maybe someone else will. Sorry, I thought you were making all decisions regarding where libusbx is going... Pete Batard might tell you that I have no authority in this project. I can only speak for the approach taken by libusb, and just like the HID class special case code for Windows in libusbx isn't something that libusb will include, another special case for mass storage class devices will also not be included. It's outside the scope of libusb. I once watched a film together with some friends, and we discussed afterwards. I said that I liked the film, but that I would have liked it even more if the characters were different. A friend pointed out you basically want a different film - which was spot on! You basically want a different library. :) Who do I ask? Regardless of where the code would be, I don't think you can really ask anyone to do it for you. If you want it done you have to do it yourself. The only other way is if you can get someone else so excited about your idea that they want to do the work for you. So far there aren't many enthusiastic comments, but who knows, maybe Pete, Hans, or Ludovic are interested. As a matter of facts, I do need libusbx for certain functions... What are those functions? Checking for the presence of my USB Device (every 200ms or so) on Linux, Mac OS X, and Windows; ejecting the Device's removable drive; checking if/when Device is actually disconnected. I think all those things are also possible, if not easier, if you use storage subsystem APIs instead of USB APIs. In any case, the very first thing I suggest that you do is to get to the bottom of what exactly you need. While that is still unclear it's much too early to consider individual tools. There is nothing unclear about my needs; on the contrary, my needs are very clear and simple: 1-maintain USB Device's removable drive read/write capability; 2-momentarily communicate synchronously with USB Device's Firmware during a maximum of 1 to 2 seconds to do the following: [a] get Firmware Version; [b] get configuration parameters; [c] set the Device's internal clock; [d] set configuration parameters; [e] send the format storage command to make the Device format its SD card; The above needs are only very high level. You'll have to drill down in particular into the momentarily communicate synchronously part, and find out exactly *how* it is done. Currently that's not really known, and you'll need to know before you can look for tools to help. 3- while doing actions #2, USB Device's removable drive capability may not be available during 1 to 2 seconds maximum. This contradicts 1- above, but being able to disconnect the storage device from the system of course gives you more options for how to reach the goal, regardless of how the non-storage communication works. Replacing drivers is quite invasive, and can take several minutes on Windows if you are unlucky, never mind the authorization prompts on Vista and up. SD card accesses may also take a very long time, and if you replace the driver while sending the non-storage commands the storage device will disappear from the system, meaning that no files can be kept open on the device while you send commands, and that if the user had not saved some open files then their data is lost. Angry user. Hence the notion of SCSI passthrough, where it can be possible to pass a SCSI command through the storage subsystem, directly to the device, as long as that command doesn't modify the storage device behind the back of the storage subsystem. Since libusbx does exactly this for HID class devices on Windows maybe there will be interest in including emulation of USB transfers also on top of the storage subsystem, but even if that is the case I think you will have to implement it yourself. 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. //Peter -- 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: There is visibly something similar to Linux's detach_kernel_driver followed by claim_interface followed by lets-do-business followed by a release_interface followed by a re-attach_kernel_driver which then resumes normal removable drive operations. How did you determine that? 1-how can we detach/re-attach the default USBSTOR driver under Windows? 2-how can we load and attach libusb0 (.dll and/or .sys) WITHOUT doing an install? This CAN be done; the proof is that the competing program is doing it. I think you're way off. The more likely explanation is that the competing program uses some random API in the Windows storage subsystem. //Peter -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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: There is visibly something similar to Linux's detach_kernel_driver How did you determine that? 2-More intensive testing showed What testing? 1-how can we detach/re-attach the default USBSTOR driver under Windows? 2-how can we load and attach libusb0 (.dll and/or .sys) WITHOUT doing an install? I think you're way off. Allow me to disagree. I think I am right on: the Device is communicating with two different parties, one at a time. It makes perfect sense that the default OS driver is somehow suspended then resumed. Unless you see the New device bubble above the system tray I don't think there is any driver action going on. Let's try another approach: Tell us everything you know about the device, and show some kind of capture of the non-storage communication. //Peter -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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-More intensive testing showed What testing? My own testing; who else's? Of course, but how did you do it? Let's try another approach: Tell us everything you know about the device, and show some kind of capture of the non-storage communication. Find attached files: xusb-output.txt device-sniffer-output.txt Thanks. Although this is not very detailed, it still has some interesting information. Device commands are op code C5; they are all the same with different parameter values. Nothing interesting there. I'm not sure if these are visible in the sniffer output? The sniffer output is from the competing program using default OS driver USBSTOR. It contains BOTH types of communication and the switch over is quite visible. Where would you say that it happens in the log? Also, do I understand correctly that you snipped part of the log out - from URB 45 up until URB 153, the response to URB 152? Without looking very closely at any of the data being sent, it's clear from the log that the only Driver Name values are USBSTOR and usbhub. This means that you will need to talk to those drivers in order to replicate what the competing program does, rather than trying to use libusb. I still think the storage subsystem has your answer. //Peter -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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
Alan Stern wrote: I still think the storage subsystem has your answer. Speaking as someone who knows practically nothing about the various APIs in Windows, the impression I get is that the competing program is using a raw SCSI interface. Right, I think so too. Does Windows provide this sort of raw SCSI interface? On google msdn scsi raw the first hit is: http://en.wikipedia.org/wiki/SCSI_Pass_Through_Interface //Peter -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ 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: Interfaces: 2 .. Interface Number: 0 Number of endpoints: 2 .. Interface Number: 1 Number of endpoints: 0 What I don't get is how to write to the second interface. Using anything other than an index of 1 for libusb_claim_interface() returns LIBUSB_ERROR_NOT_SUPPORTED. I'm missing something crashingly obvious - can anyone point out what? As Alan points out, Interface Number in the output above is the number you use with libusb_claim_interface(). The first interface can't be claimed because it is using a driver other than WinUSB (the storage class driver I think you said). //Peter -- 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] Selecting a composite device interface?
Tim Roberts wrote: You can write to the device's control endpoint without claiming an interface at all. I'm not sure this is true with WinUSB on Windows. //Peter -- 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] Building git code on Mac; CMake support?
Sean McBride wrote: I just forked libusbx on github and tried to build it. README.git says run either ./autogen.sh or ./bootstrap.sh but both result in: libtoolize or glibtoolize was not found! Please install libtool. autotools used to be part of Xcode, but was removed as of 4.3 (March 2012). Other than finding and installing 'libtoolize', is there another way to build? I guess not. Feel free to contribute something. Personally I much prefer CMake to autotools, but of course everything has its pros and cons. Is there something CMake doesn't support that libusbx needs? libusbx as libusb-1.0 have quite minimal needs. I had the unfortunate experience of trying to cross-compile with cmake not long ago though, and I have to say it left quite a bad impression. :\ I guess it would be fastest for you to simply install libtool and autotools. You can of course also run the autotools+libtool on a Linux machine, pack up the directory, and then run configure on OS X without autotools. Like with all autotools packages this was always possible and will always remain possible. //Peter -- 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] DFU - dual mode devices without composite support
g...@novadsp.com wrote: All I really need to do is send a few bytes of configuration data over the control endpoint but can see no way of doing that with the Windows stack in the way .. Use bDeviceClass 0xff (vendor specific) and install the winusb kernel driver using libwdi in any part of your software. Then the libusb-1.0 API can very easily do type vendor recipient device control requests. Or if you only care about Windows then why not use HID. It's quite popular. You would then use HIDAPI, and not use the libusb-1.0 API at all. I guess you already know everything that is documented here: https://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass //Peter -- 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] Building git code on Mac; CMake support?
Sean McBride wrote: Note that autotools are requited _only_ for people using the GIT version. What is the difference? What is included with the released version that is not included with git, and why? The difference in this case is that the autotools have been run by whoever created the release tarball, and thus the configure script has already been created, and is ready to run on any system with a shell. autotools are not involved at all beyond the point where they create the configure script. Maybe this helps explain why I find snapshot tarballs important. //Peter -- 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] Building git code on Mac; CMake support?
Sean McBride wrote: Other than finding and installing 'libtoolize', is there another way to build? I guess not. Feel free to contribute something. Where can I find Vitali's CMake support? I'd be interested to know what state it's in... https://github.com/vlovich/libusb/tree/cmake-support -- 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] Building git code on Mac; CMake support?
Sean McBride wrote: Homebrew [1] is a very nice tools for installing external tools on Mac OS X. $ brew install libtool On Mac at least, that's now 3 dependencies: - install Xcode - install homebrew - 'brew install' libtool vs - install Xcode - install CMake vs what is currently needed by tarball consumers - install Xcode The requirements for developers in a project usually doesn't matter so much, because they tend to be smaller in numbers than the users of the project. Optimize for the common case and all that. CMake unfortunately doesn't affect only developers, it also means that every user now needs CMake, where before they didn't. It's a significant disadvantage. :\ //Peter -- 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] libusbx v1.0.14
Chuck Cook wrote: From my point of view. I would like to see libusb-1.0 go through another iteration or two. Sounds like a great opportunity to get more involved. Go for it! tests with baseline devices which exercise all functions of every API If you've been using the API then this could be a great way to help. //Peter -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? 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] libusbx-1.0.13 has been released
Lionel Debroux wrote: The maintainer of libusb has proved, for two years, to be a roadblock on the path of advancing the state of libusb and on making life easier for users. I think it would be fair of you to look closely at the repository history before we discuss if and how I advanced the state of libusb. There are a few hundred commits to look into, and I encourage you to compare them with their corresponding proposed patches. Unfortunately that's the only way to accurately measure my activity that I can suggest. I would be happy to visualize it for you if I knew of a good way, but I haven't come up with one. If anyone has suggestions, please share. The long release cycle is a dead horse; bystanders and users wrote emails asking for a release, but unfortunately noone took initiative to create a release branch. I only heard the idea to do a 1.0.8.1 release with some subset of commits taken from master after 1.0.9 was already out. The idea is really good and I wish someone had suggested it sooner - it would have been very easy for anyone who wanted to get involved, and even easier for me, to do some cherry-picking to make such a release branch. Alas I had tunnel vision on the master branch, noone helped me out of that, and 1.0.9 took too long. I think it turned out very good once it was done, but anyway, everyone is busy working on new and even better versions now. :) //Peter -- 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] help/doc needed
Hi Bob, Bob Lapique wrote: the right place to seek help on basic Libusbx usage... Sure, if you find no other resource to explain what you want to know. If not, I'd be very pleased if someone could redirect me to some place where the difference between the Linux and Windows implementations is documented. There's no such documentation I'm afraid. The Linux backend has been worked on quite a lot and by different people while the Windows backend is much younger and is principally the work of one person - so there are several differences, and the odd new one is discovered now and then. :\ I am trying to port asynchronous I/O from Linux to Windows. Can you describe your protocol? Simple stuff should work well already. Lately, I get error -1 (LIBUSB_ERROR_IO) from libusb_submit_transfer() with an interrupt tranfer : libusbx: error [winusb_submit_bulk_transfer] WinUsb_Pipe Transfer failed: [22] Le périphérique ne reconnaît pas la commande. Does the same code work in Linux without kernel warnings? In particular, do you claim the interface? //Peter -- 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] help/doc needed
Bob Lapique wrote: What I want to do is to communicate with a home made board, based on a Microchip PIC microcontroller (PIC18 or PIC32), with interrupt transfers. I don't want anything special, just send and receive packets to trigger measurements and get the results. But at the moment, if I can toggle a LED, I'll be a happy man :) I'm not sure you should use interrupt OUT to trigger measurements, probably a control transfer is more suitable, or simply no transfer at all if the micro can decide on it's own when to measure. I installed a version of WinUSB supplied by the µC manufacturer. WinUSB is WinUSB, it's from Microsoft. I would suggest to use zadig.exe to check that WinUSB has been installed correctly for your device, if not then you can correct it using zadig very easily. The device has 2 endpoints (TX+RX) of 64 bytes. IN and OUT is the USB terminology. You may not need the OUT one, interrupt transfers aren't a very good fit for sending commands. On WinXP32, libusb_claim_interface() returns 0. Ok, that's good. In Linux, my app works very well. Should I see those kernel warnings in the console ? log files ? In dmesg. It would be helpful to see usbmon output from a run of your Linux application. Use these two links: http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz http://kernel.org/doc/Documentation/usb/usbmon.txt //Peter -- 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_init
Pete Batard wrote: the error basically comes from trying the following: _open(NUL, _O_WRONLY); I don't understand why the fd integer is allocated using _open() instead of allocating it in the library using a simple counter or so. It seems that the fd is just a placeholder; no actual IO goes over it. //Peter -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? 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] [PATCH] Make libusb_error_name also handle transfer status codes
I don't know how wise it is to mix the two different namespaces. //Peter -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? 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] libusb0 libusbK driver support
David Grant wrote: mass storage support? I guess you already have the following in mind? http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice //Peter -- 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: I at least need to send 2 bytes to the FPGA to receive back a NAK in case of a bad 2 first bytes. In case of a proper trame this will send a ACK or data packet. You can simplify your protocol significantly since USB transfers, aside from isochronous, are a reliable transport. If a transfer is successful then the exact data you sent has arrived correctly. Error detection and retransmission is handled on a very low layer. Take advantage of this in your protocol to make it simpler. //Peter -- 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. That would be a violation of the USB protocol. What device controller are you using? Most of them interrupt when they are asked by the host to transfer data, and then your main firmware hands over whatever data is ready to be transmitted to the (internal or external) USB device controller. The device controller is not allowed to transmit on the wire until the host controller instructs it to. The misunderstanding is common. Bus communication is explained in chapters 5 and 8 of the USB 2.0 spec, they are really readable and I recommend reading through them. //Peter -- 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:
Once I have opened a device using LibUsbX, is there a
synchronization handle I can pend on whilst waiting for the
peripheral device to write back to the host?
The device is not allowed to transmit to the host before your
application requests data.
// open device etc.
libusb_open_device_with_vid_pid(NULL,m_args.VID,m_args.PID);
while (!done)
{
DWORD dw = WaitForMultipleObjects(handles.size(),handles[0],FALSE,10);
// data waiting to be read from device
if (dw == WAIT_OBJECT_0 + 0)
{
// do the read ...
result = libusb_bulk_transfer(m_pDevice,m_epIn,...);
}
//
}
No good since there can be no data from device until you initiate a
transfer.
Another point is that the code is absolutely unportable, which kindof
misses one big point of using the portable libusb-1.0 API.
I recommend to create one USB event handling thread (which you may
already have) that calls libusb_handle_events_completed() in a loop,
and then you can choose per transfer if you want to perform a
synchronous transfer like in the call above where
libusb_bulk_transfer() will return when the requested data has been
transfered, or if you want to use the asynchronous API and queue a
transfer for processing an get a callback notification once it is
done, but be able to continue your own processing meanwhile.
//Peter
--
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] libusb0 libusbK driver support
Pete Batard wrote: I have now pushed a patch that adds libusb0.sys and libusbK.sys support there, for testing. I look forward to some testing! Even if it comes at the cost of the libusbK DLL it's still very nice that libusb-1.0 code can be used with the libusb-win32 driver. To fetch the branch: git clone git://github.com/pbatard/libusbx.git libusbx-pbatard cd libusbx-pbatard git checkout 0K Note that because the branch is not off mainline, but off a personal libusbx repo, you must go through a new clone. Both branches (master and 0K) in your personal repo have parents on libusbx.git master, so I suggest for everyone to simply add a remote and fetch from that in their existing worktrees, rather than making new clones. Repositories don't matter at all, only commits matter. I should also point out that the implementation is very dependent on the KUSB_FNID definitions from libusbK and their order, This seems fragile. Is there any more robust way? The one minor issue I found is that I get the following in xusb when trying to fetch the string descriptors of an XBox Controller device, when libusb-win32 is used: Reading string descriptors: libusbx: error [winusbx_submit_control_transfer] ControlTransfer failed: [31] A device attached to the system is not functioning. That device doesn't have strings, so this is not a major issue, and the libusb0 driver doesn't seem to have an issue returning strings for devices that have them. It's just in case there are no strings that libsusb0 seems to differ from the others and produces an error whereas the other drivers don't complain. Interesting. Is the error definitely coming from the libusb0 driver, as opposed to libusbK? Which string descriptor is being read from the device by the way - because if there are no strings then all iFoobla descriptor fields should be 0, and then there will also be no descriptor 0, so then I would certainly expect an error for the control transfer. (Though the error code is a little surprising.) Did Travis help with this code too, besides libusbK providing WinUSB compatibility? This is a nice feature, so I think he deserves credit! Thanks, //Peter -- 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 windows [libusb_submit_bulk_transfer] unable to match endpoint to an open interface
Andrea Oliveri wrote: I run the same code under Fedora 17 and it's OK. I think you get a warning in the kernel log. When the application try to read data from the device under windows i receive this error message: libusbx: error [libusb_submit_bulk_transfer] unable to match endpoint to an open interface - cancelling transfer You need to call libusb_claim_interface() after opening the device and before transfering data. //Peter -- 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] detach-kernel-driver: return ERROR_NOT_FOUND if usbfs is already bound (v2)
Hans de Goede wrote: The only way to fix this for certain is to add an atomic detach-and-claim call to the kernel. I don't know if this is worth it, though. Having spend some time thinking about this, I believe it is worth it, both to fix this race, as well as to fix the detach-kernel-driver except when it is usbfs race. I agree. For a detach-and-claim ioctl it would make sense to not detach (but still / only claim) if the attached driver (already) is usbfs. Nicely fixing the race there too. So if you're ok with adding such an ioctl I'll write a patch for it. Consider making the detach-except-when ioctl generic, so that userspace can provide any valid driver name, and let NULL mean usbfs. //Peter -- 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] EREMOTEIO Error under Fedora 17
Andrea Oliveri wrote: how can i understand Suggest show the code again, and since you are now getting to actual data transfer please also include debug output. https://libusb.org/wiki/debug mentions how to do this for libusb, but the instructions work also for libusbx if you adjust the URL. //Peter -- 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] detach-kernel-driver: return ERROR_NOT_FOUND if usbfs is already bound (v2)
Hans de Goede wrote: If the usbfs driver is found LIBUSB_ERROR_NOT_FOUND will be returned to indicate no driver was detached. What is the situation like for other platforms besides Linux, and does the change also require documentation? //Peter -- 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] Compiling on a fresh installation on Mac OS X
Yves Arrouye wrote: I was a bit surprised that the default installation obtained by cloning (using git clone on the command line) git://github.com/libusbx/libusbx.gitdid not include a configure configure co are generated and included in release tarballs. Since they are generated files they do not belong in version control. Using a fresh cloned directory and having MacPort's autoconf and friends first in my path (/opt/local/bin; those are later versions than Apple's), I had to do the following (from the top level directory): % mkdir m4 % autoreconf -v -i Is that expected? libusb has always had the autogen.sh script which generates (and runs) configure in a git tree. It works also with Mac OS X Xcode tools. If so, shouldn't the INSTALL file mentions that rather than say that one should simply have to run configure? INSTALL is for tarball consumers. If you are a git consumer there are further requirements. it does not seem that you intend to distribute something that can be configured directly with configure? libusb certainly does not intend to put generated files under version control, but it's possible that libusbx may want to change how this works. I speak for the libusb project with my 8 years of experience there, not for the libusbx fork of a few months which is ran by Pete. Or I may be missing something quite obvious Maybe the autogen.sh script. Once I did this, it was pretty easy to build a proper library. I think it is pretty easy to build libusb and libusbx, but working with git does require more of you. I think that's a good thing not per se, but because what is kept in git stays clean and easy to work with, while the release process adds the generated files. Pretty much the same as with every other proper library. //Peter -- 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] Compiling on a fresh installation on Mac OS X
Pete Batard wrote: you're going to earn yourself a ban. That's confusing, but I guess you'll do as you like. but working with git does require more of you. I think that's a good thing Please keep this bullshit about how git is going to save the world I didn't write as verbosely as I could have, and you misunderstood. From the context that was the original poster's question it could perhaps have been understood that what I intended was: but working with the code in git does require more of you This isn't the issue at hand Hopefully it's now clear that it is. //Peter -- 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] Compiling on a fresh installation on Mac OS X
Pete Batard wrote: Where did the issue become trying to convince Yves that using git (or another VCS for that matter) was better for him? I don't know how you came up with the idea that I tried to do that. Fortunately it didn't seem like Yves interpreted what I wrote like you did. Communication takes two people, and when messages are interpreted to mean something else than what was intended, time after time and with no interest for clarifications, then saying that the sender is trolling seems an odd proposition. Anyway - thanks for helping answer the original question! //Peter -- 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! I think the code looks fine. Try running against libusbx and/or libusb git source. (It would be interesting to try both, in this case.) http://libusb.org/wiki/debug has a cheat sheet for libusb, which also works for libusbx as long as the repo URL is adjusted. //Peter -- 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] Bus address of root hub
Markus wrote: I can't see a generally reliable way to get my hands on the HC information while at the same time, being able to infer which devices are connected (by means of libusb_get_bus_number() result). Do I overlook something here? Well the HC is not a USB device, so it does not fit into the libusb-1.0 API device model, which is (only) for USB devices. Right now, I can reliably tell which devices share a common bus. However, currently it's only Windows that returns the correct VID/PID for the root hub. Again, the root hub is not a USB device, but an implementation-specific part of the host controller. The root hub thus doesn't have USB VID/PID. If the HC is on a PCI bus then it will have a PCI VID/PID, but pretending that those are USB ids is a bad idea, since they are two unrelated namespaces. Consider a PCMCIA (not CardBus) USB host controller. There you would only have PCMCIA ids to go on. Another unrelated namespace. Bad idea to mix with USB ids. So it looks as if there is no possible way to tell which host controller model runs a given bus except for Windows. Why do you want to do this again? You mentioned bus bandwidth. How would you like to use the bandwidth knowledge? Do you see a chance to get such a matching done in libusbx or do you consider that outside its scope? I think that HCs and root hubs should not be exposed as USB devices, because they are not USB devices. That doesn't mean that the API must never be extended to deal also with those devices, or perhaps more likely the USB busses that they implement, but I currently don't see the use-case so it's difficult to suggest any API design. It helps to know more about how you want to use the bus knowledge? Thanks //Peter -- 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: Would you please show me how did you get bmRequestType to value 0xC2. Please see the USB 2.0 spec 9.3.1 bmRequestType Table 9-2 page 248. http://www.usb.org/developers/docs/usb_20_10.zip //Peter -- 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: I am using libusb-1.0.9, under windows 7 Just a note that the debug log you sent is from libusbx, so check which DLL gets used if you intended something else. I am also able to get serial # from one of our legacy app (written with windows API) Note that retrieving a string descriptor is a generic USB-level operation and that can't really involve unrelated Windows API. The serial number is just one many uses for string descriptors. That said, which windows API do you use to retrieve the serial number? *Before call libusb_get_string_descriptor_ascii* [ 0.350070] [181c] libusbx: debug [libusb_claim_interface] interface 0 [ 0.352070] [181c] libusbx: error [winusb_claim_interface] could not access interface 0: [1] Incorrect function. Microsoft doesn't document what ERROR_INVALID_FUNCTION means when calling WinUsb_Initialize() - if the error code is indeed from that call and not from Windows in general. [ 0.353571] [181c] libusbx: debug [libusb_claim_interface] interface 1 [ 0.355571] [181c] libusbx: debug [libusb_claim_interface] interface 2 [ 0.357572] [181c] libusbx: debug [libusb_claim_interface] interface 3 [ 0.359572] [181c] libusbx: debug [libusb_claim_interface] interface 4 [ 0.362072] [181c] libusbx: debug [libusb_claim_interface] interface 5 [ 0.365573] [181c] libusbx: debug [libusb_claim_interface] interface 6 [ 0.367574] [181c] libusbx: debug [libusb_claim_interface] interface 7 [ 0.369574] [181c] libusbx: debug [libusb_claim_interface] interface 8 [ 0.371574] [181c] libusbx: debug [libusb_claim_interface] interface 9 [ 0.374075] [181c] libusbx: debug [libusb_claim_interface] interface 10 [ 0.376075] [181c] libusbx: debug [libusb_claim_interface] interface 11 [ 0.378076] [181c] libusbx: debug [libusb_claim_interface] interface 12 [ 0.380076] [181c] libusbx: debug [libusb_claim_interface] interface 13 [ 0.382076] [181c] libusbx: debug [libusb_claim_interface] interface 14 [ 0.384577] [181c] libusbx: debug [libusb_claim_interface] interface 15 [ 0.386577] [181c] libusbx: debug [libusb_claim_interface] interface 16 [ 0.388578] [181c] libusbx: debug [libusb_claim_interface] interface 17 [ 0.390578] [181c] libusbx: debug [libusb_claim_interface] interface 18 [ 0.393079] [181c] libusbx: debug [libusb_claim_interface] interface 19 [ 0.395079] [181c] libusbx: debug [libusb_claim_interface] interface 20 [ 0.398580] [181c] libusbx: debug [libusb_claim_interface] interface 21 [ 0.400580] [181c] libusbx: debug [libusb_claim_interface] interface 22 [ 0.403081] [181c] libusbx: debug [libusb_claim_interface] interface 23 [ 0.405081] [181c] libusbx: debug [libusb_claim_interface] interface 24 [ 0.407081] [181c] libusbx: debug [libusb_claim_interface] interface 25 [ 0.409082] [181c] libusbx: debug [libusb_claim_interface] interface 26 [ 0.411082] [181c] libusbx: debug [libusb_claim_interface] interface 27 [ 0.413083] [181c] libusbx: debug [libusb_claim_interface] interface 28 [ 0.415083] [181c] libusbx: debug [libusb_claim_interface] interface 29 [ 0.417584] [181c] libusbx: debug [libusb_claim_interface] interface 30 [ 0.419584] [181c] libusbx: debug [libusb_claim_interface] interface 31 It seems that you are calling libusb_claim_interface() in a loop. Just call it one time for the interface that you actually want to use. Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting:0x00 bNumEndpoints:0x05 bInterfaceClass: 0xFF bInterfaceSubClass: 0xFF bInterfaceProtocol: 0xFF iInterface: 0x00 Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type:Bulk wMaxPacketSize: 0x0040 (64) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x02 OUT Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x04 OUT Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x86 IN Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x88 IN Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting:0x01 bNumEndpoints:0x03 bInterfaceClass: 0xFF bInterfaceSubClass: 0xFF bInterfaceProtocol: 0xFF iInterface: 0x00 Endpoint Descriptor: bEndpointAddress: 0x02 OUT Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x86 IN Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x88 IN
Re: [Libusbx-devel] Bus address of root hub
Markus wrote: my question is slightly off-topic since its affects a property of USB that's presumably standardized. Nevertheless, I'm unable to find any definite information on this: Is it correct that the root hub of a host controller has always address 255 on the given USB bus? No, 255 is an arbitrary value that Pete chose to assign to root hubs in the Windows backend, and is not a valid device address per the USB spec. On other operating systems the kernel API that backends use expose root hubs like if they were external hubs, so there no address is invented. USB 2.0 10.2.8 Root Hub: The root hub provides the same functionality for dealing with USB topology as other hubs (see Chapter 11), except that the hardware and software interface between the root hub and the Host Controller is defined by the specific hardware implementation. EHCI: System software should provide an abstraction to the USB system software stack that allows the root hub ports to be manipulated by the system as if they were ports on an external hub. I'm sure Microsoft allows the same port manipulation, but they don't expose the root hub as if it was an external hub, and since the root hub isn't an actual USB device it doesn't have a device address. If this is the case, then there are device addresses 0 to 126 + 255 (the root hub), correct? The device address is a seven-bit value. 0 is the default address, until a device is assigned a unique address by the OS. 127 is also a valid device address. 255 is not. I think the good way is for the WinUSB backend to not fabricate a root hub device, since it can never be communicated with anyway. What is the libusb-win32 situation in this regard? Does Windows agree to use libusb0.sys for a root hub? //Peter -- 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] Bus address of root hub
Pete Batard wrote: but it doesn't prevent you from retrieving root-hub descriptors. The descriptors simply come from the OS's driver rather than from an external device. That makes sense. Is it true also for Windows? //Peter -- 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] Bus address of root hub
Pete Batard wrote: Is it true also for Windows? The current code doesn't attempt to cache any descriptors for root hubs, So the Windows USB stack does not provide root hub descriptors? (If so that's perfectly fine, I'm just trying to understand how Windows exposes the root hubs.) Still, we currently do not try to poke root hubs for data during enum on Windows, so, even if allowed, libusbx won't return much... The more I think about it the more I think that not exposing root hubs at all would be a good thing. By the way, 255 has special meaning in Wireless USB, as do 128-254. WUSB uses 16-bit addresses over the air, that may be why Windows uses unsigned short. //Peter -- 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] Fix unconditional disarming of timerfd
Hey,
Hans de Goede wrote:
doing the disarm without the flying-transfers lock held is racy, ie:
Bringing back the old behavior was a start. Yes, race also. The
attached patch on top of the previous fix avoids the race, and is
available also via
git fetch git://git.libusb.org/libusb-stuge.git for_libusbx/timerfd_race \
git cherry-pick FETCH_HEAD
the setting of the timerfd from libusb_submit_transfer should
also be moved to add_to_flying_list() and be done under the
protected of the flying-transfers lock.
It makes sense from the point of view of critical sections, but
starting the timer before the transfer has actually been submitted
would mean that the timeout while the transfer is on the bus will
always be shorter than the user-specified timeout, offset by however
long it takes to do the submit itself - while starting the timer
*after* submitting the transfer means that timeout while in flight
will always be ever so slightly longer than the user-specified value.
I don't like that API semantic change so much, and I also think that
submitting a transfer is more likely to take time than setting up the
timer is, thus also costing a larger timeout error.
I think the smaller timeout error and most importantly having the
user-specified timeout be a lower bound rather than an upper bound
is preferable.
//Peter
From ca77a1a541aaa3b2f0cbc4ea03e1eeca3dd5aa5a Mon Sep 17 00:00:00 2001
From: Peter Stuge pe...@stuge.se
Date: Tue, 10 Jul 2012 16:54:16 +0200
Subject: [PATCH] io.c: Avoid timerfd race condition between completion and
new submit
An event handler thread working on transfer completion for the last
flying transfer with a timeout can end up racing with a call to
libusb_submit_transfer() from a second thread, so that the timerfd
gets disarmed even though libusb actually again has a transfer with
a timeout.
By arming or disarming the timerfd during completion strictly
according to remaining flying transfers while also holding the
flying_transfers_lock this change ensures that a new transfer can
not be added to the flying list until the completion code path has
armed/disarmed the timerfd according to the current flying list.
Hans de Goede describes the race condition situation in
http://sourceforge.net/mailarchive/message.php?msg_id=29520709
libusb.git commit c5194b408286229ce0d94765f963890057d46ee0
Signed-off-by: Peter Stuge pe...@stuge.se
---
libusb/io.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/libusb/io.c b/libusb/io.c
index cf41ee6..666f6da 100644
--- a/libusb/io.c
+++ b/libusb/io.c
@@ -1457,19 +1457,14 @@ int usbi_handle_transfer_completion(struct
usbi_transfer *itransfer,
usbi_mutex_lock(ctx-flying_transfers_lock);
list_del(itransfer-list);
- if (usbi_using_timerfd(ctx))
- r = arm_timerfd_for_next_timeout(ctx);
- usbi_mutex_unlock(ctx-flying_transfers_lock);
-
if (usbi_using_timerfd(ctx)) {
- if (r 0)
- return r;
- else if (0 == r) {
+ r = arm_timerfd_for_next_timeout(ctx);
+ if (0 == r)
r = disarm_timerfd(ctx);
- if (r 0)
- return r;
- }
}
+ usbi_mutex_unlock(ctx-flying_transfers_lock);
+ if (r 0)
+ return r;
if (status == LIBUSB_TRANSFER_COMPLETED
transfer-flags LIBUSB_TRANSFER_SHORT_NOT_OK) {
--
1.7.4.1.343.ga91df.dirty
--
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: Data never becomes available. The application asks the device to send data, when the application knows that data is supposed to be available in the device. Agree, in my case I send data to an FPGA and I'm always expecting to receive data from it. The application send the data to the device and expect data back. All right, but until the application tries to receive data, the device has no way of indicating that it has data to send. My loop event doesn't need to manage these fds by it's self but simply call libusb_handle_events(). Then libusb will call my callback function, that I register with libusb_fill_bulk_transfer. In the callback I will manage what I want to do depending on the status?!?! Correct. You add the fds from libusb to your own set of fds, and you call libusb_handle_events() when poll() returns because of an event on any of the libusb fds. A A Proposition could be that libusb support nice API to distinguish them??: No, the fd:s from libusb are opaque. Could you explain what you mean by opaque? Opaque is the opposite of transparant. In the context of data structures this means that you do not know what is inside the data structure. In the case of fds you know that they will be fd numbers, here opaque means that you do not know what any event on any fd means. It's a common misunderstanding that devices can communicate with the application without them being asked to transfer any data. This is not my case, I'm always sending data to the device and then expecting data from it. The device can anyway *not* send to the application *before* the application asks for data. //Peter -- 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: 3- In the callback I need to know what the FD is referring to and take action, ex: data is ready to be read for the FD of bulk transfer. This is a misunderstanding of USB. Data never becomes available. The application asks the device to send data, when the application knows that data is supposed to be available in the device. The device sends data only when an application asks. The device has no way to signal that data is available or not available until the application asks for data. The libusb API deals with synchronous or asynchronous transfers. The former block until completion or specified timeout, the latter happen in the background and the specified callback is called on completion or on error. In order to make this work an application must make a small effort to drive libusb event handling. To run on Windows, there is only one choice; create a thread which does nothing other than calling libusb_handle_events_completed() in a loop until there are no more libusb events to handle (e.g. until your application is exiting). If Windows is not important then getting the list of fd:s is also an alternative. When there is an event on any of the fd:s from libusb then libusb_handle_events() is called to process those events. A A Proposition could be that libusb support nice API to distinguish them??: No, the fd:s from libusb are opaque. If something happens on any of them then libusb is called to take care of the event. Otherwise I will please to push a tested patch. Change your program around a little to use libusb the right way. It's a common misunderstanding that devices can communicate with the application without them being asked to transfer any data. If you want to study USB communication more in depth I recommend spending a few days with chapter 5, 8, and 9 in the USB 2.0 spec: http://www.usb.org/developers/docs/usb_20_10.zip //Peter -- 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 on Windows + Cygwin + Apple iPad
Timotei Dolean wrote: I'll look in the meantime into the alternative to the select()-based method, maybe that will get it working. Yes, it can't work before then. //Peter -- 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
Hi Philip, philip.jos...@microchip.com wrote: the incentive to uncomplicated the user's experience has driven many implementers to HID on Windows. Yes, this is easy to understand. I think by far the best solution to communicate with HID class devices manually is to use HIDAPI. Even with our driver pre-installer, we still run into problems on some Windows machines (especially those controlled by an IS department). Do you already have some information about how those machines will react to USB devices which use the Microsoft string descriptor and control request to specify e.g. WinUSB as driver, on Windows 8? We had hoped that libusb would solve this by providing a generic way of accessing a device (simply through using control, interrupt, and bulk pipes without regard to device type) and without the need for a driver installation procedure (INF) on Windows. I think HIDAPI is a much better fit for HID class devices than libusb can ever be. With HIDAPI you get the excellent user experience also on Windows, while keeping portability across many operating systems. Non-HID-class devices will be able to offer the same user experience on Windows 8 by using the Microsoft extensions to USB, which load WinUSB for a device without a driver installation procedure and without an INF file, and then the application can of course use libusb easily. Other than lacking hot-plug, the libusb has served us well on Linux for both our bulk and HID devices. I hope it continues to do so in the future too, at least for the non-HID-class devices. I really do recommend HIDAPI for taking care of HID class. Making a thin transport abstraction of libusb vs. HIDAPI depending on device interface is probably very easy, and allows each of the three components (your application, libusb, and HIDAPI) to keep the sematics which are most relevant in respective context. Windows however was another problem (we resorted to providing our own generic interface that under the covers uses WinUSB for bulk and the native HID system calls for HID -- and unfortunately, we have INF files to contend with). I think this was a very wise solution. For the future HIDAPI for HID class and libusb for vendor specific would allow to consolidate your code across platforms, leaving only the distinction between bulk and HID class communication. On the Mac, we use libusb for bulk and implemented our own back end for HID (providing a very simplified pipe-oriented read and write capability with hot-plug). It sounds like HIDAPI would allow for significant simplication of your code, since it works without driver installation procedure across Linux, Windows, and Mac OS X. having a common way of accessing devices across platforms would be very good for us (including HID support). Of course. I think a libusb+HIDAPI combination offers just that. I would also encourage you to publish such a thin libusb+HIDAPI abstraction if you decide to take that approach, and if you think that others could benefit from the same code. //Peter -- 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: devices that do not have such descriptors will apparently still require an INF file for install purposes. Yes, that is true. At least the problem is going away in the future. Having a single API and single library across platforms would still provide the best path for many Do you implement/need a stream transport, which either uses HID or bulk? I think it would be straightforward to implement such a library on top of HIDAPI+libusb, and perhaps it could be useful for others too. I think that is an interesting project idea! //Peter -- 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] hot unplug on windows, only 3 IN transfers complete
Johannes Stezenbach wrote: Doesn't Windows (WinUSB to be precise) return an error code indicating the device was unplugged for the submitted transfers? Can you provide a debug log? I assume you check for submit errors, and I'm interested in seeing what happens to those later 13. Thanks! //Peter -- 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 and Zadig?
g...@novadsp.com wrote: Assuming I need a user-mode interface to a custom USB Bulk class device: 1. Can I use Zadig to install a WinUSB driver for the VID/PID? Yes, that's one of the things it is meant for. You can also use libwdi in your own program, to do what zadig does, but in a more automated fashion. 2. If Zadig installs the driver correctly, can I then simply open the device using the libusbx version of libusb-1.0.dll? Right, libusb-1.0 opens any device for which WinUSB is installed. I.e. this works exactly the same with both libusb libusb-1.0 and libusbx libusb-1.0 libraries. They are very close to each other. Apologies but the profusion of libusb varieties and their inter-dependencies is getting a little confusing. Yes, I completely understand the confusion. :\ //Peter -- 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 2/2] Logging: Only display timestamps in debug mode and use libusb_init as origin
Pete Batard wrote: 1. It sets the origin of the timestamps to the first libusb_init() call issued by the application. The idea is to avoid getting an arbitrary origin once we have toggleable logging, as it is currently set to the first debug message ever issued, which isn't something an app developer can reference against as it could occur wherever. It would probably be simpler to do the same thing by moving the setting of first to before the loglevel check within the logging function. In addition that has the benefits that it keeps all logging code in one place, and avoids the need to add global state. //Peter -- 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] Compiling a Universal binary on OS X?
Yves Arrouye wrote: How can I do that? No solution AFAIK. It does not help that the full command-line isn't displayed (how can I see that instead of the fake command lines here, by the way)... make V=1 rather not have to build twice and lipo everything together, This does however work and will produce working universal binaries. and also am not sure what would then happen to the *.la etc. files that only knew about one arch. They are libtool files which do not really matter except when using libtool to link against the library. //Peter -- 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: 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. However, if Windows always considers a device with 0:0 in the device descriptor an error, then the Windows backend should discard them. //Peter -- 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: I've got a custom USB bulk device (Blackfin based with my own firmware for what it's worth). Fun! Did you already verify the USB part of the firmware, or is this part of what you are doing right now? I run xdev face:feed (our VID/PID) and all device info gets reported correctly. Most of this comes from Windows APIs rather than from communication with the device itself. When libusb_open_device is called the console displays this error message: [ 4.425253] [25f0] libusbx: error [cache_config_descriptors] could not access configuration descriptor (dummy) for '\\.\USB#VID_05E3PID_0608#885A667304' : [31] A device attached to the system is not functioning. Can anyone tell me why? Is this caused during device inspection/inquiry or what? In my experience Windows isn't so helpful about error messages when something doesn't work the way it wants. If you are indeed in the process of firmware bringup then I'd recommend testing also with other environments, in particular Linux or FreeBSD can provide many helpful error messages if something is slightly off in the firmware. //Peter -- 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 and ubertooth
Xiaofan Chen wrote: ok pete i tryed it again, got a bit of a different message, but still failed. Also since you are using Cygwin which has its older libusb-1.0, you may want to remove the older libusb-1.0 cygwin package I've helped Dan with this a bit. The ubertooth package and a library it depends on is not really prepared to be cross-platform, and I've given some hints about how to accomplish that. If autotools, cmake, or another build system solution for portability is used (currently they use only a Makefile) then the cross-platform issues can be resolved one at a time, and at the end it will also be easy to build the programs for Windows. I cross-compiled the library and one of the test programs manually using mingw, after some portability changes, and the final programs worked well, so it's mostly about making the ubertooth build system more ready for Windows. //Peter -- 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] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Pete Batard wrote: On 2012.05.14 18:44, Peter Stuge wrote: I don't think that should be neccessary. If replacing the driver does not lead to a new libusb_device * for the device then I think it is a bug if the device must be destroyed before accurate state is reported by calls to _get_device_list(). .. hotplug .. The bug is that the Windows backend requires a libusb_device * to be unref:ed before libusb_get_device_list() reports system changes, while other backends do not have this limitation and it is documented that libusb_get_device_list() does not have this limitation. you're asking for hotplug before we implement hotplug. No, I'm confirming that the non-hotplug-supporting API has a bug in the Windows backend. whatever you want to pretend is a bug is actually a missing feature, I just confirmed that it's a bug. The bug was obviously reported by Uri together with his patch, and then further explained by Hans. //Peter -- 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] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Uri Lublin wrote: Maybe the problem can be solved in the application. I think that would be a workaround. Likely I can unref it before driver installation, and find it again after the installation. It seems racy and unneccessary to me. //Peter -- 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] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Pete Batard wrote: Right now, outside of not freeing the list (but in that case, expecting an enum list to auto-update itself if after it has been generated IS hotplug), You seem to miss that the list is expected to be updated on call to libusb_get_device_list() - noone has said anything about auto-updating. //Peter -- 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] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Pete Batard wrote: The bug is that the Windows backend requires a libusb_device * to be unref:ed before libusb_get_device_list() reports system changes, while other backends do not have this limitation and it is documented that libusb_get_device_list() does not have this limitation. .. That other backends have decided to pre-empt something that rightfully belongs to hotplug, by implementing part of the device refresh that belongs there, is their choice Other backends did not choose to do this. The specification (the API) says that they must, and hotplug or not changes nothing. It's about what the libusb API provides it's callers with, and the Windows backend doesn't really deliver because of this bug and with a few others. (That difficult-to-spot enumeration bug, cross-thread cancellation, and who knows what else.) Yes, the experimental backend will have bugs, but you seem to claim that this isn't really a bug while it is really obvious by now that it is. you're asking for hotplug before we implement hotplug. No, I'm confirming that the non-hotplug-supporting API has a bug in the Windows backend. Except, you hadn't confirmed anything at this point, as the only actual verifiable data The data I used (and all that's needed) was Uri's description of what he did and what happened, along with Hans extended explanation of the problem. Because I know how the libusb API is supposed to work (and you know too, since Hans quoted the documentation) no further data or testing is needed to confirm that the Windows backend indeed has a bug here. You can of course view that any way you like, and see it as receiveable (or not) as you like, but that doesn't change the facts. //Peter -- 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] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Pete Batard wrote: if you want to dismiss the Windows backend as full of bugs I never wrote that and I never hinted at that. This email thread is about just one bug. fixing this is likely to be a waste of time when we could spend it on implementing the full hotplug. ..if you don't mind having unfixed bugs. since you know so much about the bug, you should easily be able to tell what these circumstances are then... I will not bother telling again since you don't consider it receivable. (Hint: Uri, Hans and me have already told you several times now.) //Peter -- 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] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Uri Lublin wrote: Only if old backend api is UNSUPPORTED. Hm. Shouldn't the check be done unconditionally - and for all devices, ie. in every pass except perhaps HCD? Otherwise I think the bug still bites when installing the previous driver after unredirecting the device? //Peter -- 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:
+int API_EXPORTED libusb_get_port_path(libusb_context *ctx, libusb_device
*dev, uint8_t* path, uint8_t path_len)
I think the proposed API could be simplified. There's a hard upper
limit on the path length (7 ports including the HC) so I would
suggest to drop the path_len input parameter and document that path
must be uint8_t [7] or longer.
+ /* The device needs to be open, else the parents may have been
destroyed */
Please explain this comment in more detail? Does it refer to the
libusb_device refcounting?
+libusb_device * LIBUSB_CALL libusb_get_parent(libusb_device *dev)
+{
+ return dev-parent_dev;
+}
Are all devices refcounted by their children?
//Peter
--
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:
On 2012.05.11 16:48, Peter Stuge wrote:
I think the proposed API could be simplified. There's a hard upper
limit on the path length (7 ports including the HC) so I would
suggest to drop the path_len input parameter and document that path
must be uint8_t [7] or longer.
With software history littered with this array will never grow larger
than X, and with us having no clue how the USB specs may evolve
Most of the libusb community has plenty of clue actually, but I
understand that the assumption can look adventurous. Look into the
reasons for the depth limit in the USB spec and you'll find that it
is really not likely to change anytime soon, backed up even further
by the moderate frequency of new USB standards being published.
Like you, I expect that new USB specs will bring changes, and I think
that a programming library which wants to stay convenient across spec
versions will need various changes along with spec changes, but I
also know that backwards compatibility is a very high priority for
the USB specification, as we see from the low number of visible
changes from 1.0 through 3.0.
It makes no sense to try to design upwards today for a completely
unknown and certainly unlikely future, while the depth limit hasn't
changed over more than 15 years of USB so far, and with a core design
goal for libusb being convenience.
This means taking some risks and making smart guesses about what is
useful or not, based on experience..
who knows if some prominent USB committee member,
..as opposed to erring on the side of caution, based on speculation.
You may suggest that guessing based on experience is speculation too,
but I think the better term for that is projection, and I consider
them to be very different.
I would strongly suggest we use the safest approach, that requests
a user array to also be provided with its size, as is proposed
here.
It's less convenient and every API user for the foreseeable future
will think wtf how stupid is it to have to provide a size here.
If you want to always play safe then I think you may want to look
more at OpenUSB, which came about from the desire of design goals
different from those of libusb, and the safety you mention fits well
there. Of course you can and should take libusbx in the same
direction if you want.
There's in any case also a way to completely avoid all risk while
at the same time providing a possibly even more convenient API, by
returning a const char *path with a known format, suitable for
sscanf().
I think this is even more convenient because the API returns text,
which fits much better for both user interaction and storage.
+ /* The device needs to be open, else the parents may have been
destroyed */
Please explain this comment in more detail? Does it refer to the
libusb_device refcounting?
http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx-pbatard;a=commitdiff;h=9dc299236c4f9e58b7281a035a8c35c0cd33e1a3
This commit is a subset of the proposed commit, and doesn't explain
the comment at all. But thanks for pointing out the original commit!
This is indeed the refcount and ultimate destruction of most of the
devices after libusb_free_device_list(), which of course means that
one can end up with zombie parents if trying to access these outside
of libusb_get_device_list() - libusb_free_device_list().
That's quite limited.
+libusb_device * LIBUSB_CALL libusb_get_parent(libusb_device *dev)
+{
+ return dev-parent_dev;
+}
Are all devices refcounted by their children?
...
For the time being, the expectation is that the retrieval of a parent
is issued within a libusb_get_device_list() - libusb_free_device_list()
section, so there's no refcounting. This is of course an important point
to mention, which isn't currently done in the API call doc, so I'll make
sure this is fixed.
I think it's too limited for the API to be worthwhile. It introduces
a unique restriction not seen previously in the libusb API.
//Peter
--
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
philip.jos...@microchip.com wrote: Pete wrote: an up to date device list, with all the USB properties We currently do this in a layer above libusb Can you tell us about how your users can use your layer? Ie. rough details of the primitives and API offered? Thanks! //Peter -- 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/RFC] logging timestamps v3
Pete Batard wrote: From 971f4eb540a414020f4ac9a3cf7b64827cc69ae6 Mon Sep 17 00:00:00 2001 From: Peter Stuge pe...@stuge.se Date: Wed, 2 May 2012 17:04:00 + Subject: [PATCH] Core: Add a timestamping and thread ID to logging --- Please clarify in the commit message what was changed since my commit, and please mention the commit id in libusb.git. If you prefer, please feel free to make yourself author, as long as the libusb.git commit reference is there. Thanks! //Peter -- 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] Add struct libusb_version members rc and describe
Hans de Goede wrote:
my vote *in this case* goes to adding the 2 fields.
I pushed the attached commit to libusb-stuge.git x/version_rc_describe
which is based on current libusbx.git master.
Anyone wanting to apply the change can grab the patch, or maybe save
time with:
git fetch git://git.libusb.org/libusb-stuge.git x/version_rc_describe \
git cherry-pick FETCH_HEAD
//Peter
From 41a92270fe608351a610630be3369185ce3f35ed Mon Sep 17 00:00:00 2001
From: Peter Stuge pe...@stuge.se
Date: Thu, 19 Apr 2012 22:55:44 +0200
Subject: [PATCH] Core: Add struct libusb_version members rc and describe
libusb.git commit df35117ce58b74fa530baaaccc30adaf432398ea
---
libusb/Makefile.am |3 ++-
libusb/core.c |9 ++---
libusb/libusb.h| 21 +
msvc/config.h |3 +++
4 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/libusb/Makefile.am b/libusb/Makefile.am
index 0e7fc88..6b605a3 100644
--- a/libusb/Makefile.am
+++ b/libusb/Makefile.am
@@ -36,7 +36,8 @@ else
THREADS_SRC = os/threads_windows.h os/threads_windows.c
endif
-libusb_1_0_la_CFLAGS = $(VISIBILITY_CFLAGS) $(AM_CFLAGS) $(THREAD_CFLAGS)
+libusb_1_0_la_CFLAGS = $(VISIBILITY_CFLAGS) $(AM_CFLAGS) $(THREAD_CFLAGS) \
+ -DLIBUSB_DESCRIBE=\`git --git-dir $(top_srcdir)/.git describe --tags
2/dev/null`\
libusb_1_0_la_LDFLAGS = $(LTLDFLAGS)
libusb_1_0_la_SOURCES = libusbi.h core.c descriptor.c io.c sync.c $(OS_SRC) \
os/linux_usbfs.h os/darwin_usb.h os/windows_usb.h \
diff --git a/libusb/core.c b/libusb/core.c
index b50af56..b389bc6 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -43,7 +43,10 @@ const struct usbi_os_backend * const usbi_backend =
windows_backend;
struct libusb_context *usbi_default_context = NULL;
const struct libusb_version libusb_version_internal =
- { LIBUSB_MAJOR, LIBUSB_MINOR, LIBUSB_MICRO, LIBUSB_NANO};
+{
+ LIBUSB_MAJOR, LIBUSB_MINOR, LIBUSB_MICRO, LIBUSB_NANO, LIBUSB_RC,
+ LIBUSB_DESCRIBE
+};
static int default_context_refcnt = 0;
static usbi_mutex_static_t default_context_lock = USBI_MUTEX_INITIALIZER;
@@ -1764,8 +1767,8 @@ DEFAULT_VISIBILITY const char * LIBUSB_CALL
libusb_error_name(int error_code)
}
/** \ingroup misc
- * Fills a libusb_version struct with the full version (major, minor,
- * micro, nano) of this library
+ * Returns a pointer to const struct libusb_version with the version
+ * (major, minor, micro, nano, rc, and describe) of the running library.
*/
DEFAULT_VISIBILITY
const struct libusb_version * LIBUSB_CALL libusb_get_version(void)
diff --git a/libusb/libusb.h b/libusb/libusb.h
index da4683c..e417f67 100644
--- a/libusb/libusb.h
+++ b/libusb/libusb.h
@@ -642,10 +642,23 @@ struct libusb_device_handle;
* Structure providing the version of libusbx currently in use
*/
struct libusb_version {
- uint16_t major;
- uint16_t minor;
- uint16_t micro;
- uint16_t nano;
+ /** Library major version. */
+ const uint16_t major;
+
+ /** Library minor version. */
+ const uint16_t minor;
+
+ /** Library micro version. */
+ const uint16_t micro;
+
+ /** Library nano version. This field is incremented on each commit. */
+ const uint16_t nano;
+
+ /** Library release candidate suffix string, e.g. -rc4. */
+ const char *rc;
+
+ /** Output of `git describe --tags` at library build time. */
+ const char *describe;
};
/** \ingroup lib
diff --git a/msvc/config.h b/msvc/config.h
index 43b4d4e..43aa1f7 100644
--- a/msvc/config.h
+++ b/msvc/config.h
@@ -19,3 +19,6 @@
/* type of second poll() argument */
#define POLL_NFDS_TYPE unsigned int
+
+/* no way to run git describe from MSVC? */
+#define LIBUSB_DESCRIBE
--
1.7.4.1.343.ga91df.dirty
--
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
