Re: [Libusbx-devel] [PATCH] Add HID capability detection for all backends
Hi, On 03/17/2013 11:33 PM, Pete Batard wrote: > Last of the patches I wanted to have for the 1.0.15 release. > Unless there are comments, my plan will be to integrate this patch in 24 > hours and declare RC. > > This patch adds a new caps attribute to the backend struct. I preferred to do > it this way because I think it makes sense to have our backend attributes > within the backend struct, especially as we may have to set them at runtime > (in that case, we will have to remove the const qualifiers on our backend > instances, which shouldn't be an issue, but for HID this wasn't necessary). > > Because I don't really want to guess what libusb will do, I introduced > LIBUSB_CAP_HAS_HID_ACCESS at 0x100, which should leave us enough room, and > internally USBI_CAP_HAS_HID_ACCESS defined to 0x1. The latter is meant to > be used as a bitmask, which oughta simplify our testing for it, while the > former isn't, hence the need for two separate constants. > > You'll also note that I bumped LIBUSBX_API_VERSION on account of > libusb_has_capability() returning nonzero rather than 1 when a capability is > supported. I'm pretty confident that nobody was using > libusb_has_capability(), since we had nothing to test until now, or that if > they did, they probably weren't testing for an explicit value, but since > we're effectively modifying the API, we might as well not take any risks. > > Also, even if as of right now, this isn't actually required, I've updated the > doc for _has_capability() to indicate that it should always performed after > init, so that a backend has a chance to update its caps at runtime. > > Finally, I'm not sure if we want to test for > libusb_has_capability(LIBUSB_CAP_HAS_HID_ACCESS) in xusb. Ideally, we > probably should do that for the HID specific tests, but I'd rather avoid > having to take some time to do just that. Note that I did test that > libusb_has_capability() was working as expected with regards to HID on > Windows and Linux. > > Oh, and just a note on *BSD - I expect the platform to behave the same as > Linux, so I set the HID cap as enabled there, but maybe this isn't correct. > At any rate I'll try to run some *BSD tests on a VM during the RC duration, > but if someone knows something about HID and *BSD, please speak now. Hmm, I'm not sure about claiming LIBUSB_CAP_HAS_HID_ACCESS in Linux, I would rather not actually, as on Linux there is no special hid code. AFAIK the HID code on Windows allows accessing the device without doing driver swapping. Where as on Linux, driver swapping is still required. The fact that driver swapping is a lot easier on Linux, call libusb_detach_kernel_driver to detach usbhid, and the usbfs driver will auto load on claim-interface, does not change that it is still needed. To argue HID-access is supported under Linux would mean to argue that it is supported under Darwin too. One can create a code-less kext (a darwin driver) and do a driver swap of the official hid driver with that for a certain hid device, and then access it through libusbx fine on Darwin. So I would like to suggest to document that the capability is for accessing HID devices without detaching the OS native's HID driver, and that HID devices can be accessed on platforms without the capability too as long as the native driver is detached (and where necessary replaced with a generic libusb compatible driver). And then only claim the capability for windows. Regards, Hans -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] libusbx git under OpenBSD
I have not tested libusbx git under OpenBSD for a while. So I just tried it and it seems to be fine. $ export AUTOMAKE_VERSION=1.12 $ export AUTOCONF_VERSION=2.68 $ ./bootstrap.sh libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:43: installing './compile' configure.ac:40: installing './config.guess' configure.ac:40: installing './config.sub' configure.ac:30: installing './install-sh' configure.ac:30: installing './missing' examples/Makefile.am: installing './depcomp' $ ./autogen.sh libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... i386-unknown-openbsd5.2 checking host system type... i386-unknown-openbsd5.2 checking how to print strings... print -r checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking how to convert i386-unknown-openbsd5.2 file names to i386-unknown-openbsd5.2 format... func_convert_file_noop checking how to convert i386-unknown-openbsd5.2 file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$ checking for dlltool... no checking how to associate runtime and link libraries... print -r -- checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... openbsd5.2 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for windres... no checking for inline... inline checking whether gcc and cc understand -c and -o
Re: [Libusbx-devel] libusbx git under OpenBSD
On Mon, Mar 18, 2013 at 9:19 PM, Xiaofan Chen wrote: > I have not tested libusbx git under OpenBSD for a while. > So I just tried it and it seems to be fine. I also tested under NetBSD 6.0 and again it seems to work fine, but with a few warnings during compile. I think this is probably not a big issue. os/openbsd_usb.c: In function '_sync_control_transfer': os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer will break strict-aliasing rules Other than this, stress test, listdev and xusb seem to work fine with the same benchmark test device. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Add HID capability detection for all backends
On 2013.03.18 10:32, Hans de Goede wrote: > Hmm, I'm not sure about claiming LIBUSB_CAP_HAS_HID_ACCESS in Linux, I > would rather not > actually, as on Linux there is no special hid code. This is not what the capability is about. See below. > AFAIK the HID code > on Windows > allows accessing the device without doing driver swapping. Where as on > Linux, driver > swapping is still required. The fact that driver swapping is a lot > easier on Linux, > call libusb_detach_kernel_driver to detach usbhid, and the usbfs driver > will auto load > on claim-interface, does not change that it is still needed. Please understand what the caps are about. It's about answering the question: "Can libusbx, on its own, provide feature X". Nothing more. Nothing less. It doesn't matter if Windows does it without having to detach a driver and Linux requires a call to libusb_detach. Fact is, using libusbx, and libusbx alone (i.e. without having to perform additional actions outside of the library) on both the Linux and Windows platforms, libusbx should be able to communicate with an HID device. If we want to go with "but this is a different case because or detach", then the only thing you'll get is me adding an extra "LIBUSBX_HAS_HID_ACCESS_WITH_DETACH" cap set to true on Linux, which won't do our users any good. What we really want is tell our users whether libusbx has the capabilities to access and HID device on its own. That we need to invoke 12 libusbx calls before it can do or none is irrelevant. On Linux, libusbx _can_ access an HID device. Saying otherwise will be misleading. But to elaborate on that last point, please consider this scenario: We go with your proposal of setting the HID cap to false on Linux. Lo and behold, in a few months time, we have the following conversation on this mailing list "- Hey guys, I had to go overbudget and overdelay with my project for this, but just so you know, I produced an addon library that can combine libusbx and hidapi. The reason I did that is that, while I only need basic USB-like access from HID, HID access wasn't supported by libusbx on Linux, and I have to deliver a Windows+Linux USB application... - Huh, you know that libusbx _does_ provide HID access on Linux. You just need to call libusb_detach to be granted access - But libusb_has_capability() told me that HID access was not possible on Linux!!!" > To argue HID-access is supported under Linux would mean to argue that it > is supported under Darwin too. Or that it is supported under Windows by the current libusb (libusb, not libusbx), since all one has to do is replace the HID driver with WinUSB there. But as I explained above, the _BIG_ difference is that under Darwin you need to do something outside of libusbx (and likewise on Windows without native HID driver support from the backend). On Linux, you don't. If you want to pretend that differences between endo and exo don't matter, be my guest. > One can create a code-less kext (a darwin driver) and do a driver > swap of the official hid driver with that for a certain hid device, and > then access it through libusbx fine on Darwin. _OUTSIDE_ of libusbx. Again, the idea of caps is "Can libusbx, on its own, perform the following feature". If that answer is yes, as is the case for HID access on both Linux and Windows, then the caps _must_ be set to true. > So I would like to suggest to document that the capability is for > accessing HID devices > without detaching the OS native's HID driver, and that HID devices can > be accessed on > platforms without the capability too as long as the native driver is > detached (and > where necessary replaced with a generic libusb compatible driver). And > then only > claim the capability for windows. Sorry but I think that's going to be super conter-productive for our users. The capability is for accessing HID devices, period. Trying to get further than that is only going to confuse our users or worse, as exposed above, lead them to believe that HID access is not supported when using libusbx on Linux, which is plain wrong. This being said, I don't have a problem trying to make the documentation more comprehensive on the subject, but I'm also not going to delude myself into the belief that every single of our users is going to read the documentation meticulously to figure out what the actual story is on Linux. Better have them get a report that HID is supported on Linux, and then figure that they need to call detach(), than have a report that it isn't, and missing the part of the documentation that says that, well, it actually is. Regards, /Pete -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge
Re: [Libusbx-devel] libusbx git under OpenBSD
On 2013.03.18 13:41, Xiaofan Chen wrote: > I also tested under NetBSD 6.0 and again it seems to > work fine, but with a few warnings during compile. Thanks for these tests. I think we've been having these warnings for a long time. I'm still waiting for someone interested enough in the *BSD platforms to look into them. Unless other people manifest some interest to correct platform specific issues, it's hard for us to justify investing too much time on them, as the only logical conclusion we can draw is that we don't have that many users using libusbx on these platforms in the first place. Regards, /Pete -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx git under OpenBSD
On Tue, Mar 19, 2013 at 4:53 AM, Pete Batard wrote: > On 2013.03.18 13:41, Xiaofan Chen wrote: >> I also tested under NetBSD 6.0 and again it seems to >> work fine, but with a few warnings during compile. > > Thanks for these tests. I think we've been having these warnings for a > long time. I'm still waiting for someone interested enough in the *BSD > platforms to look into them. > > Unless other people manifest some interest to correct platform specific > issues, it's hard for us to justify investing too much time on them, as > the only logical conclusion we can draw is that we don't have that many > users using libusbx on these platforms in the first place. I think you are probably right. libusb-1.0 and libusbx are relatively new to OpenBSD and NetBSD users. I agree with you we will need to depend on users on OpenBSD/NetBSD to improve the support of libusbx under these two operating systems. On the other hand, OpenBSD users will use their ports system which now follows libusb.org and not libusbx. There are two patches which I will take a look at the patches since I think they are relevant to libusbx as well. http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/libusb1/patches/ And take note the warning only happens under NetBSD and not OpenBSD. NetBSD users will most likely use pkgsrc system which has ports for libusbx (libusbx-1.0.11) and libusb-1.0. http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/libusbx/ http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/libusb1/ It seems to me now OpenBSD and NetBSD users are still most likely use libusb-1.0.9 with a few patches and not libusbx. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx git under OpenBSD
On Tue, Mar 19, 2013 at 9:11 AM, Xiaofan Chen wrote: > On the other hand, OpenBSD users will use their ports system which > now follows libusb.org and not libusbx. There are two patches which > I will take a look at the patches since I think they are relevant to > libusbx as well. > http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/libusb1/patches/ But not any time soon, probably after 1.0.15 or even 2.0 release. I am not an OpenBSD/NetBSD user anyway, just installed the VM to test libusbx. -- Xiaofan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
