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/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
