On 2013.03.19 18:07, Tim Roberts wrote: > I'm not sure I buy that argument.
I don't by that argument, but not for the same reason as Tim (though I think that's a valid point on its own). But let's me first start by the most worrying statement of Hans' reply: On 2013.03.19 07:41, Hans de Goede wrote: > Claiming that it will just work like it works on Windows is wrong too > though, so lets make it 2 different capabilities. 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". Or do I need to elaborate further on when I said that the caps were about: > answering the question: "Can libusbx, on its own, provide feature X". > Nothing more. Nothing less. Was I supposed to add "especially, no assumption should be made with regards to how the feature is implemented with regards to each platform"? That's really what I was implying there. So once more, LIBUSBX_HAS_HID_ACCESS is only meant to answer the question: "Can libusbx access an HID device on this platform?". No less. _NO MORE_. On both Linux and Windows, the answer to that question is a resounding yes (in most cases, but see more for Windows specifics at the end), hence the value should be set to true. Especially it's not because I was the main Windows backend developer that when I add something to the general libusbx API, it's meant to be interpreted in a Windows specific way. So no assumptions should be made on how exactly HID access should be provided by libusbx, as long as it can be provided, in full, using native libusbx calls. That's what I tried to explain in the previous mail. Moreover, following on this, it makes no more sense to add a LIBUSBX_HAS_HID_ACCESS_WITH_DETACH for Linux and keep LIBUSBX_HAS_HID_ACCESS for Windows, than it'd make sense to use LIBUSBX_HAS_HID_ACCESS for Linux and add a LIBUSBX_HAS_HID_ACCESS_WITHOUT_DETACH for Windows. Clearly, if we want to go with LIBUSBX_HAS_HID_ACCESS_WITH_DETACH or whatever Linux specifics, then we also need to have a Windows specifics, and the only _viable_ implementation we can go with, if we follow what you advocate, is: LIBUSBX_HAS_HID_ACCESS_WITHOUT_DETACH LIBUSBX_HAS_HID_ACCESS_WITH_DETACH But then again, maybe OS X or another platform will come with their won HID access schemed (provided it can be implemented in full within libusbx), that may not fit with WITH_DETACH/WITHOUT_DETACH, so we might really as well go with: LIBUSBX_HAS_HID_ACCESS_LIKE_ON_WINDOWS LIBUSBX_HAS_HID_ACCESS_LIKE_ON_LINUX I hope I'm not the only one who sees just a little bit of a problem with doing that and transforming what was meant as a way to obtain information about a _generic_ capacity into something that is platform specific. As to the example, and this is the reason why I agree with Tim that it's not convincing, let's try to push it further and consider the use of an HID keyboard with an LCD display from a libusbx user's perspective, first with the expected point of view of an app developer relying on libusbx to develop their app. If our app developer's intent is to develop software that accesses the HID+LCD keyboard, you can bet that they're going to at least perform a minimal amount of testing and very quickly find out, even if we don't have an explicit _DETACH for Linux in our caps: 1. That they need to detach on Linux, unlike what is the case on Windows 2. Whether they need to take provisions for the loss of KB access, which may very well imply dropping the libusbx method of access from their app altogether. As such it shouldn't really matter whether there exists a _WITH_DETACH cap or not. _WITH_DETACH alone will hardly be enough to let them know about the possible consequences of trying to access their HID device on Linux . No matter how precise we try to be with our caps designation, this is something they will need to comprehend by themselves, preferably through experimentation. I don't really see how 2 words will equate documentation and/or empirical data. But let's push the above scenario further, and now consider the end users of the app for a minute. If the app made it through to their hands, and it's using detach, it can only mean that its main target is not the kind of dual devices you cite as potentially problematic. Now, due to the absence of _WITH_DETACH, our app developer may have been oblivious to the detach call being an issue for some users, and may only learn about that problem through user reports, but I will argue that if they do, they're also most likely not really going to care if a handful of devices out there may be forced to temporarily lose part of their functionality (part, since the main functionality should be with what the app is trying to access) while undergoing libusbx access on Linux, since there are probably not the devices they were targeting. So I really don't see how splitting the HID cap in 2 is going to be that beneficial Finally, it is my strong belief that we are going to help a lot more users by telling them a generic truth (that libusbx on its own CAN access HID devices on both Linux and Windows), which is what our generic caps are about, than trying to be pedantic and annoy the hell of anybody who sees libusbx for what it really is and should be, just _another_ library that they'd like to work with and that they don't really want to be forced to spend time learning the intricacies of (unless they really have to). Or, if it makes more sense this way, do you really want to force all Windows users to learn about a non Windows operation (detach) because it appears in our capabilities list? If we want to be logical with that _DETACH caps proposal for Linux, then I'm also going to have plenty of caps to add with regards to the various Windows restrictions, such as no pollable fds, concurrent access a question mark, or even just for HID mouse or KB access. And finally on that last topic, since it should make your example somewhat less relevant, you might want to consider that on Windows, libusbx cannot gain full access to an HID device that serves as a keyboard or a mouse. That's because the OS reserves exclusive access. At best, we're gonna get a bunch of generic descriptors, but you can forget about sending or receiving any other kind of data unless you replace the driver (and in your example, the hope of course is that the manufacturer was smart enough to make the LCD+KB device composite, as Windows would treat them as 2 independent devices). Thus, if you're going to do HID KB/mouse access with libusbx, you may not be able to do that in a cross platform fashion anyway, in which case knowing that you may run into extra issues on Linux is irrelevant. If we take Windows HID access as our benchmark, then Linux can already be considered a special case for KB access, because it allows full access to a keyboard device. So maybe we should also add a: LIBUSBX_CAPS_HAS_HID_ACCESS_INCLUDING_KEYBOARDS_AND_MICE as well as LIBUSBX_CAPS_HAS_HID_ACCESS_WITH_EXACT_REPORT_DESCRIPTORS (since another retriction we have on Windows that we can only "guess" them)? Hopefully, you get the point. I think that's a point I made a couple of times previoulsy, but let me reiterate it: If you propose something that is aimed at one platform, please try to consider whether it'd make sense to propose the same thing, but with platforms roles reversed. 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
