On 2013.03.20 09:32, Hans de Goede wrote: > Hi, >> Excuse me, but I must have missed the part where I claimed or even >> remotely implied that LIBUSBX_HAS_HID_ACCESS meant "HID access using a >> native driver and without detach, just like it is done on Windows". > > Well, the problem is that under Linux accessing HID devices works just > like any other device, there is nothing special about HID devices under > Linux. Yes you can access them, but you can access *any* device this way, > so I don't see this something which needs advertising through a special > capability.
That's because you're still not getting what caps are about. Caps are about answering the question: "Does this runtime of libusbx provide feature X". When ALL platforms provide the same feature(s), then caps have no reason to exist. So caps do not exist in isolation for a platform, as a way to document a platform specific implementation (i.e. "this platform provides HID access through detach", "this platform provides HID access through a native drive"). It exists when we have discrepancies with regards to general features between platforms. In this case, on some platforms, the current libusbx can NOT access HID devices on its own, whereas on others it can. Don't you think we owe it to our users, then, to let them know then whereas the library they are using can or cannot communicate with HID devices? > OTOH on Windows HID devices are handled specially and can be accessed > without messing with the native driver, which whether you like it or not > is a big difference. It's exactly the other way round when you actually try to fathom what caps are really about. Of course each platform has a specific way to provide a capability when it's implemented. And in the case of HID, BOTH Windows and Linux have restrictions. For Windows, the restrictions are that you can't access a KB or mouse, and the reports you'll get won't be the original ones. For Linux, the restrictions are that you need to detach. But these are just that: _restrictions_ of the implementation. Heck, who knows if someone isn't going to pop up with a patch to bridge libwdi on Windows, that we could integrate to provide a detach feature there. In that case we might very well chose to drop the whole HID code there (since it has limitations we can't bypass) and go with detach always to access HID, just as it is on Linux. Are we suddenly going to pretend that the Windows libusbx runtime has somehow lost its capability to access HID devices, when at worst the only extra required by app developers will to adda detach call (which the bridge could very well provide on its own, without requiring app devs to do it)? Of course not. Implementation restrictions, whatever they are, do not mean that HID access is less of a feature on Linux than it is on Windows. Why you are still hell bent on insisting that a Linux _restriction_ should be seen as more than that is really beyond me. I'm trying to imagine a justification for that, but I can't see one. Or are Linux developers less competent than the ones on other platforms that they're going to need a hint to figure out that, in order to access HID devices, they need to detach the driver first? > To me advertising LIBUSBX_HAS_HID_ACCESS under Linux would make sense if > Linux would have similar special code accessing /dev/hidraw* devices, which > atm it does not. Indeed, *to you*, and for some weird reason that I cannot comprehend, because it clearly does not derive from trying to treat libusbx as the cross platform library that it is. There's no Linux or Windows "special case" one way or another. There's only the question of X being supported by our runtime on Y. "Can feature X be provided for this libusbx runtime on platform Y?" When X=HID and Y=Linux, that answer is YES. > On second thought I do agree that having 2 separate caps for this is not a > good idea, so I'm back to my initial proposal to simply only advertise this > capability for Windows, since Windows is the only one which has it. I'm really starting to get concerned that "the libusbx runtime on Linux has everything it needs to access HID devices, and, on its own, will enable you to craft applications that can access HID devices" seems hard to understand, especially when the HID cap is going to be placed in the same frame of reference as the hotplug cap. But if you want an example of how caps are meant to be used, here's one, looking no further than xusb. xusb does provide a generic test for HID devices [1]. However, on the platforms where xusb cannot access HID devices on its own, it doesn't make sense to have it (or even if we decided to keep it in, wouldn't it be nice to be able to let users know that they might have to manually do something outside of xusb to run this test?). Without HID caps, we just shoot in the dark, and hope for the best, letting the test fail without users being any wiser as to why that failed. With HID caps, we can tell a user running on OS-X or *BSD that they're trying to test against an HID device, on a platform where HID device access cannot be provided by libusbx alone (if at all). So please tell me how the HID capability feature will be useful for our users if it is set to false on Linux? How exactly are we going to help anyone in this situation? > The capability should be renamed to better reflect what it does, Not at all. The capability reflect precisely what it advertise: the ability to access an HID device. _YOU_ are the one who want to constrain it into something that it was not meant to be in the first place, and what's more, something that's going to be unhelpful for our users, because when they seek for a simple answer to "I'm running my libusbx based app on OS X/*BSD/Linux/Windows - can I access an HID device there?" they will receive an erroneous answer in the case of the Linux platform. > but to me > to advertise the same cap for how Windows deals with HID devices under > Linux > too is just plain wrong. _to you_ > Sure we will always have subtle platform > difference, > but this is not a subtle difference, this is a big difference. Oh, so Linux is a special case now? Not being able to access KB/mouse or getting exact descriptors is peanuts, but having to do a simple operation, which libusbx provides, to gain complete access to all of the device's features is somehow worse? Good luck with that! If anything the big difference we should flag is that Linux has _proper_ HID access when Windows doesn't. That we need to use detach is completely irrelevant with regards to what our users are likely to care about. > As said the Linux equivalent would be to access hid devices through > /dev/hidraw* nodes. As I said, we're not making any promise or giving any specifics about what is _implied_ by being able to access an HID device, besides the immediate interpretation that we expect out users to have, which is that libusbx gives them access to an HID device one way or another, with or without some restrictions, that they may very well have to figure out for themselves. > You can argue about this till you see blue, but claiming > that HID access under Linux and Windows is the same thing atm is simply not > true! Well, I do have better things to do too you know. Yet I will argue for the sake of our users when I believe that our users are going to be worse off if we go with what you advocate. So here we go again, for what has to be the 10th time, because as much as you may want to skirt about it, you will have to face the fact that HID was never introduced as more than a generic cap: HAS_HID_ACCESS != HAS_HID_ACCESS_IN_A_WINDOWS_SPECIFIC_WAY There is absolutely nothing in the caps name that remotely implies that HID_ACCESS has to be provided the Windows way. If *BSD comes with their own method of accessing HID devices tomorrow that is neither windows-like or Linux-like, HAS_HID_ACCESS should still apply. Furthermore, how about the hotplug caps for libusb, which is where the libusbx HID cap derives from. Are you going to tell the libusb guys that HAS_HOTPLUG in libusb means that hotplug has to be implemented a specific way? Nope, it is only meant to tell whether the libusb runtime on platform X supports it. So there's only one question, and it is is contained in the exact 3 words we use to describe the cap: HAS the libusbx runtime from this platform enough to ACCESS HID devices. Whether you like it or not, the answer to that question on Linux is yes, and that's what we must report to our users. > <snip lots more arguments about this> If you're not prepared to argue your point, then you really have no point. Either provide convincing evidence that our users are meant to interpret the caps in the fashion you want to force everyone to interpret it, or I'm going to ignore the "la la la, can't hear you." above. In absence of more compelling data, the only compromise you're gonna get from me is that I am willing to add a LIBUSBX_HAS_DETACH cap if you really want one, so that you can do your mix of HAS_HID_ACCESS and HAS_DETACH caps to get the Linux specific information that you seem hell bent on having the caps provide (which would also solve the other discussion with Xiaofan). Take it or leave it. Regards, /Pete [1] https://github.com/libusbx/libusbx/blob/master/examples/xusb.c#L585 ------------------------------------------------------------------------------ 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
