libusbx v1.0.12 has been released
Locked
libusbx v1.0.12 has been released
 
|
All,
It is my pleasure to announce the release of libusbx v1.0.12. In terms of bugfixes and new features, this new version brings the following improvements: * Fix a potential major regression with pthread on Linux * Fix missing thread ID from debug log output on cygwin * Fix possible crash when using longjmp and MinGW's gcc 4.6 * Add topology calls: libusb_get_port_number(), libusb_get_parent() & libusb_get_port_path() * Add toggleable debug, using libusb_set_debug() or the LIBUSB_DEBUG environment variable * Define log levels in libusb.h and set timestamp origin to first libusb_init() call * All logging is now sent to to stderr (info was sent to stdout previously) * Update log messages severity and avoid polluting log output on OS-X * Add HID driver support on Windows * Enable interchangeability of MSVC and MinGW DLLs * Additional bug fixes and improvements The v1.0.12 source tarball can be downloaded at: https://sourceforge.net/projects/libusbx/files/latest/download?source=files For additional information or downloads, you are also invited to visit http://libusbx.org. Also note that you can always check our roadmap at https://sourceforge.net/apps/trac/libusbx/roadmap, for information about future releases, and you are of course welcome to submit improvement suggestions or bug reports on the libusbx-devel mailing list. Regards, /Pete ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: libusbx v1.0.12 has been released
|
Did you really put that HID junk back in there? This is a bad idea. HID users SHOULD NOT be using libusb and I will not add this IOHID support to the Darwin backend. -Nathan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: libusbx v1.0.12 has been released
|
|
On 2012.06.15 22:25, Nathan Hjelm wrote:
> Did you really put that HID junk back in there? This is a bad idea. HID > users SHOULD NOT be using libusb and I will not add this IOHID support > to the Darwin backend. That's fine, we're not going to force you to do something you're not comfortable with. For what is worth, HID support has always been readily available on Linux, and is not much of an issue on Windows either. From our last discussions on the subject, it seemed that quite a few users seemed to be of the idea that convenience trumped other concerns, especially given that using HID requires no manual installation on Windows, unlike WinUSB, which is why we think it makes a lot of sense to add it back. Regards, /Pete ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: libusbx v1.0.12 has been released
|
|
On Jun 15, 2012, at 3:59 PM, Pete Batard wrote: > On 2012.06.15 22:25, Nathan Hjelm wrote: >> Did you really put that HID junk back in there? This is a bad idea. HID >> users SHOULD NOT be using libusb and I will not add this IOHID support >> to the Darwin backend. > > That's fine, we're not going to force you to do something you're not > comfortable with. > > For what is worth, HID support has always been readily available on > Linux, and is not much of an issue on Windows either. From our last > discussions on the subject, it seemed that quite a few users seemed to > be of the idea that convenience trumped other concerns, especially given > that using HID requires no manual installation on Windows, unlike > WinUSB, which is why we think it makes a lot of sense to add it back. There are two seperate issues here: 1) whether or not vendors should be abusing the HID interface to bypass problems with the Windows driver model, and 2) whether or not these devices should be accessed with libusb. Let me address the second issue first as it is the most relevant to the discussion. Yes, Linux user's can easily access HID devices through libusb but that does not mean we should go out of our way to support the HID model on any other platform. As I said I will not add nor support IOHID access for libusb on OSX/Darwin thus our users can not expect to write a portable app/library using libusb that accesses a HID device. Since I expect a majority of libusb's users are looking for portability so all of HID device users should be directed to use hidapi. The first issue is pretty much a religious one. Microsoft screwed up so vendors are doing something I consider sub-par (I bought a device-- an ecotech xr30w-- that uses fake-HID and I almost returned it. luckily for the vendor USB is a secondary feature of the device). Not much can be done but to encourage vendors to not use HID and use WinUSB or a dedicated driver. I don't really care if this is a PIA. They need to take it up with Microsoft to fix their (one of many) broken software models. -Nathan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: libusbx v1.0.12 has been released
|
|
On 2012.06.16 00:39, Nathan Hjelm wrote:
> There are two seperate issues here: > 1) whether or not vendors should be abusing the HID interface to bypass problems with the Windows driver model, and > 2) whether or not these devices should be accessed with libusb. > > Let me address the second issue first as it is the most relevant to the discussion. Indeed. > Yes, Linux user's can easily access HID devices through libusb but that does not mean we should go out of our way to support the HID model on any other platform. Well, that's not really an issue. We have it for both Linux and Windows, so now's a bit late to say that we're going out of our way to provide it. Or are you saying that HID on Windows is expected to blow in "our" face, whereas Linux should be stable, and therefore that different weights and measures should apply? Also, there are people who think that adding HID on OS-X could be both an interesting exercise (because it's expected to be tricky) and may actually be worth it, if it makes life easier for users on the platform... If users think a feature might be useful to them, I think "we" have a duty to look into what we can do to support it. Finally, what part of providing a *generic* USB library is really that hard to understand? Are HID devices suddenly not part of the USB microcosm? Or should we state that libusb(x) is only "generic, is as much as ALL platforms can provide the exact same set of features"? Sorry, but I don't think that flies. If we follow that logic, then no fd polling on Windows should equate no libusb Windows backend plain and simple. By your reasoning with regards to HID, it is a disservice to let Windows users, or users of any platform for that matter, suffer a non-portable feature, and any such feature should be remove. But if you want a statement that's easier to summarize with regards to the approach we follow here, it is the following: If we can do it, let's do it. > As I said I will not add nor support IOHID access for libusb on OSX/Darwin thus our users can not expect to write a portable app/library using libusb that accesses a HID device. Since I expect a majority of libusb's users are looking for portability so all of HID device users should be directed to use hidapi. You do understand that, if we follow your logic, as indicated above, we need to push it through to its logical conclusion and forcefully *remove* HID support on Linux. Otherwise, I don't see your argument making much sense. > The first issue is pretty much a religious one. Microsoft screwed up so vendors are doing something I consider sub-par (I bought a device-- an ecotech xr30w-- that uses fake-HID and I almost returned it. luckily for the vendor USB is a secondary feature of the device). Not much can be done but to encourage vendors to not use HID and use WinUSB or a dedicated driver. I don't really care if this is a PIA. They need to take it up with Microsoft to fix their (one of many) broken software models. Or, we can try to see what we can do to help our users, rather than force them to jump through extra hoops, by imposing arbitrary dogma. Nobody expects you to go with something you're not comfortable with, and nobody will force you into development or support of such a feature. However, I will very take objection if you try to impose *your* personal views on anyone else, especially our users. I know for a fact that Microchip would have been quite interested in cross-platform libusb HID support, as it would have greatly simplified their development. Yet, instead, we pretty much forced them to restart from scratch. I know some people will try to argue that it's all for the better, but I hardly see how costing our users time, that they could very much have avoided, is doing them any favour. Finally, it's not because we provide a portable library that people are going to develop cross-platform applications. Some people might not care that much if HID support is available only on a couple of platform, if these are the ones they are interested in. So there again, I think we should take into account that there's quite the difference between easy to profess dogma and expected reality. Regards, /Pete ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: libusbx v1.0.12 has been released
|
In reply to this post by Nathan Hjelm-2
Nathan Hjelm wrote:
> As I said I will not add nor support IOHID access for libusb on OSX/Darwin This special case HID class code which was removed from libusb long ago and now added back into libusbx by Pete didn't belong in libusb in the first place, and I think it will remain unique to libusbx. There's no interest for the code in libusb. > Since I expect a majority of libusb's users are looking for > portability so all of HID device users should be directed to > use hidapi. Yes. HIDAPI does the job and does it very well! //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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
In reply to this post by Nathan Hjelm-2
On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <[hidden email]> wrote:
> Since I expect a majority of libusb's users are looking for portability > so all of HID device users should be directed to use hidapi. Actually hidapi can benefit from the libusb's HID backend as well. You can see that HIDAPI has a libusb-1.0 API based backend. https://github.com/signal11/hidapi/tree/master/libusb Right now it is only for Linux and FreeBSD. But if there is a native HID backend for libusbx under Mac OS X, the above libusb backend for HIDAPI can be extended to Mac OS X as well. You may ask why that could be beneficial? The native HID backend (HIDAPI under Mac OS X and Windows, and the hidraw backend for Linux even though hidraw is not the default for HIDAPI Linux) may have the side benefits of supporting Bluetooth. But in the future libusbx will have new features like Hotplug and Cross-platform event handling, that could actually benefit HIDAPI a lot provided libusbx supports HID on the platforms. -- Xiaofan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen <[hidden email]> wrote:
> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <[hidden email]> wrote: >> Since I expect a majority of libusb's users are looking for portability >> so all of HID device users should be directed to use hidapi. > > Actually hidapi can benefit from the libusb's HID backend as well. > You can see that HIDAPI has a libusb-1.0 API based backend. > https://github.com/signal11/hidapi/tree/master/libusb > > Right now it is only for Linux and FreeBSD. But if there is > a native HID backend for libusbx under Mac OS X, the above > libusb backend for HIDAPI can be extended to Mac OS X as well. > > You may ask why that could be beneficial? The native HID backend > (HIDAPI under Mac OS X and Windows, and the hidraw backend > for Linux even though hidraw is not the default for HIDAPI Linux) > may have the side benefits of supporting Bluetooth. But in the future > libusbx will have new features like Hotplug and Cross-platform event > handling, that could actually benefit HIDAPI a lot provided libusbx > supports HID on the platforms. BTW, it seems to me this uhid may be more suitable for HIDAPI than hidraw in the future as the native backend. http://permalink.gmane.org/gmane.linux.kernel.input/25430 It sounds a bit like the native HID API under Windows. -- Xiaofan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
In reply to this post by Nathan Hjelm-2
On Fri, Jun 15, 2012 at 05:39:58PM -0600, Nathan Hjelm wrote:
> There are two seperate issues here: > 1) whether or not vendors should be abusing the HID interface to > bypass problems with the Windows driver model, and > 2) whether or not these devices should be accessed with libusb. > > Let me address the second issue first as it is the most relevant to > the discussion. Yes, Linux user's can easily access HID devices > through libusb but that does not mean we should go out of our way to > support the HID model on any other platform. As I said I will not > add nor support IOHID access for libusb on OSX/Darwin thus our users > can not expect to write a portable app/library using libusb that > accesses a HID device. Since I expect a majority of libusb's users > are looking for portability so all of HID device users should be > directed to use hidapi. > > The first issue is pretty much a religious one. Microsoft screwed up > so vendors are doing something I consider sub-par (I bought a > device-- an ecotech xr30w-- that uses fake-HID and I almost returned > it. luckily for the vendor USB is a secondary feature of the > device). Not much can be done but to encourage vendors to not use > HID and use WinUSB or a dedicated driver. I don't really care if > this is a PIA. They need to take it up with Microsoft to fix their > (one of many) broken software models. Could you elaborate why you think the ecotech xr30w is "fake-HID", and why you think it is bad? I've no experience with HID, but the HID spec says "Many typical HID class devices include indicators, specialized displays, audio feedback, and force or tactile feedback." The examples given in the Usage Tables http://www.usb.org/developers/docs/hidpage/ include several output only applications, much more than just keyboards, mice and joysticks. I think the key point is that the HID spec provides a framework for devices with a flexible, extensible and self-describing set of controls. To me it looks like the ecotech xr30w developers were choosing the appropriate USB device class for their device. Your assessment that HID is only used to bypass OS shortcomigs seems incorrect. Johannes ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
On Jun 16, 2012, at 9:00 AM, Johannes Stezenbach wrote: > On Fri, Jun 15, 2012 at 05:39:58PM -0600, Nathan Hjelm wrote: >> There are two seperate issues here: >> 1) whether or not vendors should be abusing the HID interface to >> bypass problems with the Windows driver model, and >> 2) whether or not these devices should be accessed with libusb. >> >> Let me address the second issue first as it is the most relevant to >> the discussion. Yes, Linux user's can easily access HID devices >> through libusb but that does not mean we should go out of our way to >> support the HID model on any other platform. As I said I will not >> add nor support IOHID access for libusb on OSX/Darwin thus our users >> can not expect to write a portable app/library using libusb that >> accesses a HID device. Since I expect a majority of libusb's users >> are looking for portability so all of HID device users should be >> directed to use hidapi. >> >> The first issue is pretty much a religious one. Microsoft screwed up >> so vendors are doing something I consider sub-par (I bought a >> device-- an ecotech xr30w-- that uses fake-HID and I almost returned >> it. luckily for the vendor USB is a secondary feature of the >> device). Not much can be done but to encourage vendors to not use >> HID and use WinUSB or a dedicated driver. I don't really care if >> this is a PIA. They need to take it up with Microsoft to fix their >> (one of many) broken software models. > > Could you elaborate why you think the ecotech xr30w is "fake-HID", > and why you think it is bad? > > I've no experience with HID, but the HID spec says > "Many typical HID class devices include indicators, specialized > displays, audio feedback, and force or tactile feedback." > The examples given in the Usage Tables > http://www.usb.org/developers/docs/hidpage/ > include several output only applications, much more than > just keyboards, mice and joysticks. I think the > key point is that the HID spec provides a framework > for devices with a flexible, extensible and self-describing > set of controls. The xr30w is a good example of a fake-HID device. For those who are not familiar with the device its an awesome programmable led aquarium light (http://ecotechmarine.com/products/radion/). The xr30w uses a usb interface to support three features: programming, live mode, and firmware updates. The company doesn't (yet) support Mac so I spent some time reverse-engineering their protocols: Programming: Ecotech's software generates an array of 15 byte points including start time, duration, led cluster intensity (red, green, white, blue, etc), and cloud/storm probabilities. This array is broken down into 58 byte blocks and sent to the device with report 9 (button). After the entire program has been sent a reboot command is issued to commit the new program. This is a bulk write use case and does not fit HID. Live mode: Ecotech's software uses this mode to demonstrate a particular setting. Report 16 (unicode?!) is used to send led cluster intensity (red, green, white, blue, etc), storm mode, and cloud mode. This use case does fit HID but can also be done with a control transfer. Firmware: Ecotech distributes a text file (I am not even kidding) containing reports. Each line is converted to binary and sent to the xr30w. This is a bizarre way to do a firmare update (there might be a good reason for doing it this way) but it looks to me like another bulk write use case and doesn't fit HID. > To me it looks like the ecotech xr30w developers were choosing > the appropriate USB device class for their device. > Your assessment that HID is only used to bypass OS shortcomigs > seems incorrect. I think this is a cut and dry case of HID-class abuse. Only one of the xr30w's features looks like it fits well with the HID model (I am using HID Usage Table v1.12 as a reference). The rest of the features (and consequently a majority of the usage) is simple bulk read. Ecotech would have been better off using the composite class with a Windows driver. -Nathan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
In reply to this post by Xiaofan Chen
On Jun 16, 2012, at 7:19 AM, Xiaofan Chen wrote: > On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <[hidden email]> wrote: >> Since I expect a majority of libusb's users are looking for portability >> so all of HID device users should be directed to use hidapi. > > Actually hidapi can benefit from the libusb's HID backend as well. > You can see that HIDAPI has a libusb-1.0 API based backend. > https://github.com/signal11/hidapi/tree/master/libusb > > Right now it is only for Linux and FreeBSD. But if there is > a native HID backend for libusbx under Mac OS X, the above > libusb backend for HIDAPI can be extended to Mac OS X as well. The only reason to use libusb under hidapi on Linux is the lack of an HID API. Its not really a good thing. > You may ask why that could be beneficial? The native HID backend > (HIDAPI under Mac OS X and Windows, and the hidraw backend > for Linux even though hidraw is not the default for HIDAPI Linux) > may have the side benefits of supporting Bluetooth. But in the future > libusbx will have new features like Hotplug and Cross-platform event > handling, that could actually benefit HIDAPI a lot provided libusbx > supports HID on the platforms. I would argue that if hidapi wants hotplug support they will need to implement it themselves for one simple reason: HID is not restricted to just usb. Bluetooth support is tricky. On OSX it isn't thread safe (you can't access a device from more than one thread) so I wouldn't recommend accessing IOBluetooth with a generic interface. Besides, it is trivial to add hotplug support for most device classes under OSX. I can't speak for other platforms. -Nathan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
RE: libusbx v1.0.12 has been released
|
In reply to this post by Pete Batard-2
One of the major factors in using HID in unorthodox ways is that there
is no need for the Windows INF/driver install business. This has always been a potential problem with a customer's machine (permissions and the like). I agree that many devices using this class might be better served using bulk, but the incentive to uncomplicated the user's experience has driven many implementers to HID on Windows. Even with our driver pre-installer, we still run into problems on some Windows machines (especially those controlled by an IS department). Now you might say, "Hey, not my problem." but that is an unrealistic view of a very customer-oriented situation that can hurt a bottom line. 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. Other than lacking hot-plug, the libusb has served us well on Linux for both our bulk and HID devices. 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). 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). Admittedly, our application of USB is very much just transport oriented (all content is vendor specific, we are just using the USB as a common transport), but even then, having a common way of accessing devices across platforms would be very good for us (including HID support). The simpler the maintenance, the better. But I see that as one gets "above" the concept of "just a transport using pipes" and addressing specific USB types, then things might become a bit more complicated. -----Original Message----- From: Pete Batard [mailto:[hidden email]] Sent: Friday, June 15, 2012 5:24 PM To: [hidden email] Cc: [hidden email] Subject: Re: libusbx v1.0.12 has been released On 2012.06.16 00:39, Nathan Hjelm wrote: > There are two seperate issues here: > 1) whether or not vendors should be abusing the HID interface to bypass problems with the Windows driver model, and > 2) whether or not these devices should be accessed with libusb. > > Let me address the second issue first as it is the most relevant to the discussion. Indeed. > Yes, Linux user's can easily access HID devices through libusb but that does not mean we should go out of our way to support the HID model on any other platform. Well, that's not really an issue. We have it for both Linux and Windows, so now's a bit late to say that we're going out of our way to provide it. Or are you saying that HID on Windows is expected to blow in "our" face, whereas Linux should be stable, and therefore that different weights and measures should apply? Also, there are people who think that adding HID on OS-X could be both an interesting exercise (because it's expected to be tricky) and may actually be worth it, if it makes life easier for users on the platform... If users think a feature might be useful to them, I think "we" have a duty to look into what we can do to support it. Finally, what part of providing a *generic* USB library is really that hard to understand? Are HID devices suddenly not part of the USB microcosm? Or should we state that libusb(x) is only "generic, is as much as ALL platforms can provide the exact same set of features"? Sorry, but I don't think that flies. If we follow that logic, then no fd polling on Windows should equate no libusb Windows backend plain and simple. By your reasoning with regards to HID, it is a disservice to let Windows users, or users of any platform for that matter, suffer a non-portable feature, and any such feature should be remove. But if you want a statement that's easier to summarize with regards to the approach we follow here, it is the following: If we can do it, let's do it. > As I said I will not add nor support IOHID access for libusb on OSX/Darwin thus our users can not expect to write a portable app/library using libusb that accesses a HID device. Since I expect a majority of libusb's users are looking for portability so all of HID device users should be directed to use hidapi. You do understand that, if we follow your logic, as indicated above, we need to push it through to its logical conclusion and forcefully *remove* HID support on Linux. Otherwise, I don't see your argument making much sense. > The first issue is pretty much a religious one. Microsoft screwed up so vendors are doing something I consider sub-par (I bought a device-- an ecotech xr30w-- that uses fake-HID and I almost returned it. luckily for the vendor USB is a secondary feature of the device). Not much can be done but to encourage vendors to not use HID and use WinUSB or a dedicated driver. I don't really care if this is a PIA. They need to take it up with Microsoft to fix their (one of many) broken software models. Or, we can try to see what we can do to help our users, rather than force them to jump through extra hoops, by imposing arbitrary dogma. Nobody expects you to go with something you're not comfortable with, and nobody will force you into development or support of such a feature. However, I will very take objection if you try to impose *your* personal views on anyone else, especially our users. I know for a fact that Microchip would have been quite interested in cross-platform libusb HID support, as it would have greatly simplified their development. Yet, instead, we pretty much forced them to restart from scratch. I know some people will try to argue that it's all for the better, but I hardly see how costing our users time, that they could very much have avoided, is doing them any favour. Finally, it's not because we provide a portable library that people are going to develop cross-platform applications. Some people might not care that much if HID support is available only on a couple of platform, if these are the ones they are interested in. So there again, I think we should take into account that there's quite the difference between easy to profess dogma and expected reality. Regards, /Pete ------------------------------------------------------------------------ ------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: libusbx v1.0.12 has been released
|
|
Hi Philip,
[hidden email] 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
RE: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
Thanks for your comments.
Just a note in regards to WinUSB and Windows 8. It would appear that a device will not need to provide an INF as long as it provides Windows specific info in its OS descriptors (refer to Microsoft tech note http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799%28v=vs %20.85%29.aspx#required__microsoft_os_descriptors_in_firmware). Unfortunately, this does not help our current customer base (the devices out there do not have those specialized descriptors and a safe, in-field update of the firmware for all these tools may not be realistic). Those devices that do not have such descriptors will apparently still require an INF file for install purposes. Having a single API and "single library" across platforms would still provide the best path for many (albeit, I realize that driver installation is still a concern if libusb uses WinUSB on Windows). -----Original Message----- From: Peter Stuge [mailto:[hidden email]] Sent: Monday, June 18, 2012 10:09 AM To: [hidden email]; [hidden email] Subject: Re: [Libusbx-devel] libusbx v1.0.12 has been released Hi Philip, [hidden email] 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/libusbx-devel ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
[hidden email] 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
In reply to this post by Xiaofan Chen
On 06/16/2012 09:24 AM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen <[hidden email]> wrote: >> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <[hidden email]> wrote: >>> Since I expect a majority of libusb's users are looking for portability >>> so all of HID device users should be directed to use hidapi. >> Actually hidapi can benefit from the libusb's HID backend as well. >> You can see that HIDAPI has a libusb-1.0 API based backend. >> https://github.com/signal11/hidapi/tree/master/libusb >> >> Right now it is only for Linux and FreeBSD. But if there is >> a native HID backend for libusbx under Mac OS X, the above >> libusb backend for HIDAPI can be extended to Mac OS X as well. >> >> You may ask why that could be beneficial? The native HID backend >> (HIDAPI under Mac OS X and Windows, and the hidraw backend >> for Linux even though hidraw is not the default for HIDAPI Linux) >> may have the side benefits of supporting Bluetooth. But in the future >> libusbx will have new features like Hotplug and Cross-platform event >> handling, that could actually benefit HIDAPI a lot provided libusbx >> supports HID on the platforms. I don't really understand this statement. HIDAPI currently uses IOHIDManager on Mac, which is the native API for HID device access on Mac. What you're suggesting is that libusb/mac add support for opening HID devices using IOHIDManager, so that then HIDAPI can use libusb/mac to open these devices (which will use IOHIDManager), instead of using IOHIDManager directly, which it already does? > BTW, it seems to me this uhid may be more suitable for > HIDAPI than hidraw in the future as the native backend. > http://permalink.gmane.org/gmane.linux.kernel.input/25430 > > It sounds a bit like the native HID API under Windows. I think uhid is a method to insert HID events and traffic into the HID subsystem of the kernel from a userspace program, for processing as though these events were coming from hardware. The example uhid program creates mouse events from keyboard input. hidraw is the native HID library on Linux for sending and receiving raw data, and it works for USB and Bluetooth. Alan. ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
In reply to this post by Nathan Hjelm-2
On 06/16/2012 12:51 PM, Nathan Hjelm wrote:
> On Jun 16, 2012, at 7:19 AM, Xiaofan Chen wrote: >> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <[hidden email]> wrote: >>> Since I expect a majority of libusb's users are looking for portability >>> so all of HID device users should be directed to use hidapi. >> Actually hidapi can benefit from the libusb's HID backend as well. >> You can see that HIDAPI has a libusb-1.0 API based backend. >> https://github.com/signal11/hidapi/tree/master/libusb >> >> Right now it is only for Linux and FreeBSD. But if there is >> a native HID backend for libusbx under Mac OS X, the above >> libusb backend for HIDAPI can be extended to Mac OS X as well. > The only reason to use libusb under hidapi on Linux is the lack of an HID API. Its not really a good thing. I disagree. Linux has hidraw, which is its native HID interface from userspace. The original reason for a libusb-based HIDAPI implementation on Linux was that when HIDAPI was started, hidraw had some limitations which needed to be fixed in the kernel, the largest of which was lack of handling of feature reports. These issues have since been fixed (as of kernel 2.6.39). Since getting new kernel code to end users can take quite a bit of time (roughly 2-3 month kernel release cycles, where new code gets queued for the next (not current) cycle, plus distros which are often on a 6-month or longer release cycle and often will ship one revision behind the latest kernel, and users which are often not using the latest distros), I decided to make a libusb-based implementation of HIDAPI to fill the gap. This worked well with a few caveats. Currently there are advantages to using the hidraw implementation and there are advantages to using the libusb implementation which are outlined in the HIDAPI README and in linux/README. Further, the libusb-based implementation is useful now for FreeBSD as well. > I would argue that if hidapi wants hotplug support they will need to implement it themselves for one simple reason: HID is not restricted to just usb. Bluetooth support is tricky. Hotplug would have to come from libudev on Linux. > On OSX it isn't thread safe (you can't access a device from more than one thread) so I wouldn't recommend accessing IOBluetooth with a generic interface. I don't know about IOBluetooth, but HIDAPI on Mac is perfectly threadsafe. If you find a threading issue, it's a bug. > Besides, it is trivial to add hotplug support for most device classes under OSX. I can't speak for other platforms. The API for hotplug in IOHIDManager is pretty good, and easy to use. Linux isn't bad either (libudev for both back-ends). One day I need to get motivated and get hotplug into all the HIDAPI implementations. Alan. ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
In reply to this post by Alan Ott
On Fri, Jun 22, 2012 at 10:45 AM, Alan Ott <[hidden email]> wrote:
> On 06/16/2012 09:24 AM, Xiaofan Chen wrote: >> On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen <[hidden email]> wrote: >>> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm <[hidden email]> wrote: >>>> Since I expect a majority of libusb's users are looking for portability >>>> so all of HID device users should be directed to use hidapi. >>> Actually hidapi can benefit from the libusb's HID backend as well. >>> You can see that HIDAPI has a libusb-1.0 API based backend. >>> https://github.com/signal11/hidapi/tree/master/libusb >>> >>> Right now it is only for Linux and FreeBSD. But if there is >>> a native HID backend for libusbx under Mac OS X, the above >>> libusb backend for HIDAPI can be extended to Mac OS X as well. >>> >>> You may ask why that could be beneficial? The native HID backend >>> (HIDAPI under Mac OS X and Windows, and the hidraw backend >>> for Linux even though hidraw is not the default for HIDAPI Linux) >>> may have the side benefits of supporting Bluetooth. But in the future >>> libusbx will have new features like Hotplug and Cross-platform event >>> handling, that could actually benefit HIDAPI a lot provided libusbx >>> supports HID on the platforms. > > I don't really understand this statement. HIDAPI currently uses > IOHIDManager on Mac, which is the native API for HID device access on Mac. > > What you're suggesting is that libusb/mac add support for opening HID > devices using IOHIDManager, so that then HIDAPI can use libusb/mac to > open these devices (which will use IOHIDManager), instead of using > IOHIDManager directly, which it already does? I am saying that you could have two backend for HIDAPI for each platform, one is the native HID API on the platform (benefits: bluetooth support). The other backend is libusb (USB only, but potential future benefits: cross-platform hotplug support and cross-platform event handling support as outlined in libusbx roadmap) provided libusb supports HID device for the platform. http://sourceforge.net/apps/trac/libusbx/roadmap I guess this is a moot point and the potential benefits are only potential now. I will recommend people to use HIDAPI for new cross-platform HID project. On the other hand, there are many existing libusb-1.0 API based program for generic USB HID device under Linux, if there is a need to port the existing program to Windows, then probably they can stick to use the libusb-1.0 API, just need to use libusbx-1.0.12 or later which supports generic HID device under Windows. >> BTW, it seems to me this uhid may be more suitable for >> HIDAPI than hidraw in the future as the native backend. >> http://permalink.gmane.org/gmane.linux.kernel.input/25430 >> >> It sounds a bit like the native HID API under Windows. > > I think uhid is a method to insert HID events and traffic into the HID > subsystem of the kernel from a userspace program, for processing as > though these events were coming from hardware. The example uhid program > creates mouse events from keyboard input. > > hidraw is the native HID library on Linux for sending and receiving raw > data, and it works for USB and Bluetooth. Thanks for the explanation. I was thinking that uhid can do similar things as hidraw too but maybe I am not correct. -- Xiaofan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
Re: [Libusbx-devel] libusbx v1.0.12 has been released
|
|
In reply to this post by Alan Ott
On Fri, Jun 22, 2012 at 11:11 AM, Alan Ott <[hidden email]> wrote:
> On 06/16/2012 12:51 PM, Nathan Hjelm wrote: >> The only reason to use libusb under hidapi on Linux is the lack of >> an HID API. Its not really a good thing. > > I disagree. Linux has hidraw, which is its native HID interface from > userspace. > > The original reason for a libusb-based HIDAPI implementation on Linux > was that when HIDAPI was started, hidraw had some limitations which > needed to be fixed in the kernel, the largest of which was lack of > handling of feature reports. These issues have since been fixed (as of > kernel 2.6.39). Since getting new kernel code to end users can take > quite a bit of time (roughly 2-3 month kernel release cycles, where new > code gets queued for the next (not current) cycle, plus distros which > are often on a 6-month or longer release cycle and often will ship one > revision behind the latest kernel, and users which are often not using > the latest distros), I decided to make a libusb-based implementation of > HIDAPI to fill the gap. This worked well with a few caveats. Currently > there are advantages to using the hidraw implementation and there are > advantages to using the libusb implementation which are outlined in the > HIDAPI README and in linux/README. Further, the libusb-based > implementation is useful now for FreeBSD as well. Last time I sent the news about libusb/libusbx in the NetBSD mailing list and it generated quite some interests. One of the issue is again the driver detaching problem since libusb/libusbx rely on ugen driver under BSDs. One potential solution is to teach uhid the ugen ioctls but that is quite some big work. http://mail-index.netbsd.org/current-users/2012/05/30/msg020285.html The other solution is to detach uhid with a custom kernel configuration that has a pre-defined ugen entry but unfortunately it requires a rebuild of the NetBSD kernel. http://mail-index.netbsd.org/current-users/2012/05/31/msg020306.html >> I would argue that if hidapi wants hotplug support they will need to >> implement it themselves for one simple reason: HID is not restricted to >> just usb. Bluetooth support is tricky. > > Hotplug would have to come from libudev on Linux. > >> On OSX it isn't thread safe (you can't access a device from >> more than one thread) so I wouldn't recommend accessing >> IOBluetooth with a generic interface. > > I don't know about IOBluetooth, but HIDAPI on Mac is perfectly > threadsafe. If you find a threading issue, it's a bug. > >> Besides, it is trivial to add hotplug support for most device >> classes under OSX. I can't speak for other platforms. > > The API for hotplug in IOHIDManager is pretty good, and easy to use. > Linux isn't bad either (libudev for both back-ends). One day I need to > get motivated and get hotplug into all the HIDAPI implementations. Windows is not that bad either. I think libusb-pbatard's hp branch has some codes already. -- Xiaofan ------------------------------------------------------------------------------ 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/ _______________________________________________ libusb-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-devel |
«
Return to LibUSB Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |