Hi,
On 03/27/2013 05:22 PM, Ludovic Rousseau wrote:
> 2013/3/25 Hans de Goede :
>> Hi,
>>
>>
>> On 03/23/2013 12:05 PM, Ludovic Rousseau wrote:
>>>
>>> 2013/3/23 Hans de Goede :
We all seem to agree on that, which is good :) So it would be helpful
to get some feedback on my propose
2013/3/25 Hans de Goede :
> Hi,
>
>
> On 03/23/2013 12:05 PM, Ludovic Rousseau wrote:
>>
>> 2013/3/23 Hans de Goede :
>>>
>>> We all seem to agree on that, which is good :) So it would be helpful
>>> to get some feedback on my proposed API for the opting in before I
>>> actually start coding this.
Hi,
On 03/23/2013 12:05 PM, Ludovic Rousseau wrote:
> 2013/3/23 Hans de Goede :
>> We all seem to agree on that, which is good :) So it would be helpful
>> to get some feedback on my proposed API for the opting in before I
>> actually start coding this. Let me quote my own API proposal from
>> an
2013/3/23 Hans de Goede :
> We all seem to agree on that, which is good :) So it would be helpful
> to get some feedback on my proposed API for the opting in before I
> actually start coding this. Let me quote my own API proposal from
> another mail:
>
> Assuming all platforms will do auto-detach
Hi,
On 03/22/2013 11:32 PM, Pete Batard wrote:
> On 2013.03.22 17:25, Ludovic Rousseau wrote:
>> Change: Auto detach is now fine for me.
>
> OK.
>
> I wasn't actually proposing such a change, since, unless somebody
> volunteers to create a patch,
I volunteer :)
> it's extremely unlikely that I'l
On 2013.03.22 17:25, Ludovic Rousseau wrote:
> Change: Auto detach is now fine for me.
OK.
I wasn't actually proposing such a change, since, unless somebody
volunteers to create a patch, it's extremely unlikely that I'll have
time to spend on that. At any rate, even if there's a volunteer, this
2013/3/22 Hans de Goede :
> Hi,
>
>
> On 03/22/2013 10:58 AM, Ludovic Rousseau wrote:
>>
>> 2013/3/22 Hans de Goede :
>>>
>>> Although automatic detaching may seem like a smart and user (programmer)
>>> friendly thing to do, I'm very much against it! Let me explain
>>> why:
>>>
>>> a) libusb_detach
Hi,
On 03/22/2013 10:58 AM, Ludovic Rousseau wrote:
> 2013/3/22 Hans de Goede :
>> Although automatic detaching may seem like a smart and user (programmer)
>> friendly thing to do, I'm very much against it! Let me explain
>> why:
>>
>> a) libusb_detach_kernel_driver on Linux will *always* work if
2013/3/22 Hans de Goede :
> Although automatic detaching may seem like a smart and user (programmer)
> friendly thing to do, I'm very much against it! Let me explain
> why:
>
> a) libusb_detach_kernel_driver on Linux will *always* work if the
> user has the necessary rights on the usbfs device node
Hi,
On 03/22/2013 01:16 AM, Pete Batard wrote:
> On 2013.03.21 20:06, Ludovic Rousseau wrote:
>> Maybe LIBUSBX_IMPLEMENTS_DETACH_KERNEL_DRIVER
>
> Works for me.
I've a small nitpick, lets call it LIBUSB_CAP_SUPPORTS_DETACH_KERNEL_DRIVER
to match with the LIBUSB_ERROR_NOT_SUPPORTED error code.
>>
On 2013.03.21 20:06, Ludovic Rousseau wrote:
> Maybe LIBUSBX_IMPLEMENTS_DETACH_KERNEL_DRIVER
Works for me.
> It would also be cool if libusb_claim_interface() could report a
> specific error in case detach is needed.
> Something like LIBUSB_ERROR_NEED_DETACH_KERNEL_DRIVER.
I think if we could do
2013/3/21 Pete Batard :
> Do you, or anyone, have a preference for how this new cap should be
> called? I don't think LIBUSBX_HAS_DETACH will fly, as we could argue
> that Windows also has _detach - it just returns an error when called.
Maybe LIBUSBX_IMPLEMENTS_DETACH_KERNEL_DRIVER
> Right now, I
On 2013.03.21 08:19, Hans de Goede wrote:
> lets have the HID cap flag set on Linux too.
Thanks. I mean it.
> But please, lets
> clearly document that it requires detach on Linux.
Sure. I'll work something out to try to make that clear, unless you
already have an idea of what you would like to
On Wed, Mar 20, 2013 at 5:37 PM, Hans de Goede wrote:
> On 03/20/2013 02:16 AM, Xiaofan Chen wrote:
>>
>> On Wed, Mar 20, 2013 at 6:43 AM, Pete Batard wrote:
>>>
>>> Oh, and for what is worth, I think over at libusb we discussed the idea
>>> of having a _detach() call that did nothing but returne
On Thu, Mar 21, 2013 at 4:19 PM, Hans de Goede wrote:
> Hi,
>
> On 03/20/2013 10:21 PM, Pete Batard wrote:
>
>
>
> Ok I give in, lets have the HID cap flag set on Linux too. But please, lets
> clearly document that it requires detach on Linux.
>
> As for having a detach cap flag, that sounds like
Hi,
On 03/20/2013 10:21 PM, Pete Batard wrote:
Ok I give in, lets have the HID cap flag set on Linux too. But please, lets
clearly document that it requires detach on Linux.
As for having a detach cap flag, that sounds like a good idea too, actually
if we had only had that from day one code us
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
Hi,
On 03/20/2013 02:16 AM, Xiaofan Chen wrote:
> On Wed, Mar 20, 2013 at 6:43 AM, Pete Batard wrote:
>> Oh, and for what is worth, I think over at libusb we discussed the idea
>> of having a _detach() call that did nothing but returned success on
>> Windows, to avoid #ifdefs, but that idea was r
Hi,
On 03/19/2013 09:11 PM, Pete Batard wrote:
> 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 state
On Wed, Mar 20, 2013 at 6:43 AM, Pete Batard wrote:
> Oh, and for what is worth, I think over at libusb we discussed the idea
> of having a _detach() call that did nothing but returned success on
> Windows, to avoid #ifdefs, but that idea was rejected at the time. I
> think I proposed a patch for
Oh, and for what is worth, I think over at libusb we discussed the idea
of having a _detach() call that did nothing but returned success on
Windows, to avoid #ifdefs, but that idea was rejected at the time. I
think I proposed a patch for that actually.
As long as we have a detach call in libusb
On 2013.03.19 22:11, Ludovic Rousseau wrote:
> What would a real program look like?
Not sure about "real", but our own xusb sample has it, since, of course,
we want it to access HID devices on both Linux and Windows:
https://github.com/libusbx/libusbx/blob/master/examples/xusb.c#L836
Regards,
/
Hello,
2013/3/19 Pete Batard :
> 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_.
I am not sure how this capability is supposed to be used in a
cross-platform program.
Do we need to have platef
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 w
Hans de Goede wrote:
>
> Let me try to explain why, just as there is a huge difference between
> internal functionality and something only available when doing extra
> stuff outside of libusbx, there is a huge difference between being
> able to access a device without detaching the driver, and acce
Hi,
On 03/18/2013 09:24 PM, Pete Batard wrote:
> On 2013.03.18 10:32, Hans de Goede wrote:
>> Hmm, I'm not sure about claiming LIBUSB_CAP_HAS_HID_ACCESS in Linux, I
>> would rather not
>> actually, as on Linux there is no special hid code.
>
> This is not what the capability is about. See below.
>
On 2013.03.18 10:32, Hans de Goede wrote:
> Hmm, I'm not sure about claiming LIBUSB_CAP_HAS_HID_ACCESS in Linux, I
> would rather not
> actually, as on Linux there is no special hid code.
This is not what the capability is about. See below.
> AFAIK the HID code
> on Windows
> allows accessing the
Hi,
On 03/17/2013 11:33 PM, Pete Batard wrote:
> Last of the patches I wanted to have for the 1.0.15 release.
> Unless there are comments, my plan will be to integrate this patch in 24
> hours and declare RC.
>
> This patch adds a new caps attribute to the backend struct. I preferred to do
> it
On 2013.03.18 00:02, Xiaofan Chen wrote:
> OpenBSD and NetBSD will not have the HID capability
Thanks for the update. I'll make sure the capability is disabled for
*BSD when I merge the patch into mainline.
Regards,
/Pete
On Mon, Mar 18, 2013 at 6:33 AM, Pete Batard wrote:
> Oh, and just a note on *BSD - I expect the platform to behave the same as
> Linux, so I set the HID cap as enabled there, but maybe this isn't correct.
> At any rate I'll try to run some *BSD tests on a VM during the RC duration,
> but if someo
30 matches
Mail list logo
