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:p...@akeo.ie] Sent: Friday, June 15, 2012 5:24 PM To: libusbx-devel@lists.sourceforge.net Cc: libusb-de...@lists.sourceforge.net 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 libusb-de...@lists.sourceforge.net 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/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
