On Sat, Feb 16, 2013 at 7:54 AM, Pete Batard wrote:
> On 2013.02.15 18:56, Kustaa Nyholm wrote:
>> On 15.2.2013 20.02, "Tim Roberts" wrote:
>>
>>> Is someone actually coding up a first-draft hotplug solution to do some
>>> experimentation?
>>
>>
>> I don't no, but I don't think so, there is I bel
On 2013.02.15 18:56, Kustaa Nyholm wrote:
> On 15.2.2013 20.02, "Tim Roberts" wrote:
>
>> Is someone actually coding up a first-draft hotplug solution to do some
>> experimentation?
>
>
> I don't no, but I don't think so, there is I believe an implementation
> from Pete way back.
Yeah, I've been
On 15.2.2013 20.02, "Tim Roberts" wrote:
>Is someone actually coding up a first-draft hotplug solution to do some
>experimentation?
I don't no, but I don't think so, there is I believe an implementation
from Pete way back.
>
>There are two ways to design standard libraries. One way is to take
Is someone actually coding up a first-draft hotplug solution to do some
experimentation?
There are two ways to design standard libraries. One way is to take
software that someone has been working on and using, clean it up, and
release it. This is the Linux model -- more or less how libusb* has
o
Hi,
On 02/15/2013 04:26 AM, Nathan Hjelm wrote:
> What might be interesting to look into is I think libusb can listen for the
> event sent out by USBDeviceOpenSeize. I am not entirely sure (it might only
> apply to kernel drivers). This might be useful to force one libusb app to
> detach so ano
On 15.2.2013 5.26, "Nathan Hjelm" wrote:
>if the vendor wishes to abuse the HID spec to make development on Windows
>easier then libusb is not the answer.
I don't think they [vendors] try to make *development* easier,
they want to make *deployment* easier, that is the main goal
for most USB pro
What might be interesting to look into is I think libusb can listen for the
event sent out by USBDeviceOpenSeize. I am not entirely sure (it might only
apply to kernel drivers). This might be useful to force one libusb app to
detach so another can use a device. Do any other platforms have a simi
On Tue, Feb 12, 2013 at 6:29 PM, Hans de Goede wrote:
> Note:
> 1) I'm not claiming this is easy from an implementation pov, just that
> the current API can handle this.
>
> 2) AFAIK Mac OS X is actually in more or less a similar situation, it has
> a call to detach the in kernel driver, but the i
On 14.2.2013 2.36, "Pete Batard" wrote:
>I'm sorry, but I don't get why we seem so hell bent (as it looks to me)
Well, no, it is just difficult to keep one's hands of the keyboard
when something 'interesting' surfaces. I'm in no hurry with hotplug,
I was just curious and wanted to get reactions
I'm sorry, but I don't get why we seem so hell bent (as it looks to me)
on finalizing the API down to its last minute detail, when we still
haven't really figured out how it's going to be implemented across the
major platforms, an more importantly, what that's really gonna mean for
our users.
On 13.2.2013 15.23, "Hans de Goede" wrote:
>
>> In my thinking weather there is a driver or not is
>> logically a property of libusb_device and should
>> be queried from that handle and result in corresponding
>> error (LIBUSB_ERROR_NO_DRIVER) if passed to libusb_open().
>
>Apps which are actually
Hi,
On 02/13/2013 10:58 AM, Kustaa Nyholm wrote:
> On 12.2.2013 12.29, "Hans de Goede" wrote:
>
>> On 02/12/2013 12:54 AM, Pete Batard wrote:
>>>
>>> Personally, the first thing I want out of hotplug from a libusbx/Windows
>>> standpoint is to provide applications with the ability to notify user
On 12.2.2013 12.29, "Hans de Goede" wrote:
> Currently the following events are defined:
>
>LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED: A device has arrived and is ready to
>use
>LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT: A device has left and is no longer
>available
>
>Not the best names ever, I would have call
On 13.2.2013 0.38, "Nathan Hjelm" wrote:
>
>Using descriptions like "stupid" for the proposed event names does
>nothing to advance the discussion on what the API for libusb 1.0 should
>look like. You, and others, have been given (and still have for a short
>time) an opportunity to help define the
On 12.2.2013 12.29, "Hans de Goede" wrote:
>On 02/12/2013 12:54 AM, Pete Batard wrote:
>>
>> Personally, the first thing I want out of hotplug from a libusbx/Windows
>> standpoint is to provide applications with the ability to notify users
>
>We can simply add:
>
>LIBUSB_HOTPLUG_EVENT_DRIVERLESS
On 12.2.2013 4.06, "Xiaofan Chen" wrote:
>
>2) The complexity of the event handling, I tend to believe
>this is the main motivation.
>
>To me 2) is really the one major problems for libusb-1.0
>API. Just read the libusbx documentation and you will
>realize that it is not that designed for Windows
Hi,
On 02/13/2013 02:08 AM, Xiaofan Chen wrote:
> On Tue, Feb 12, 2013 at 6:29 PM, Hans de Goede wrote:
>> LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_ARRIVED
>> LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_LEFT
>>
>> Event types, and generate those in the driverless case, apps which don't
>> know how to
On Wed, Feb 13, 2013 at 7:24 AM, Orin Eman wrote:
> On Tue, Feb 12, 2013 at 2:38 PM, Nathan Hjelm wrote:
>> Using descriptions like "stupid" for the proposed event names does nothing
>> to advance the discussion on what the API for libusb 1.0 should look like.
>> You, and others, have been given
On Tue, Feb 12, 2013 at 6:29 PM, Hans de Goede wrote:
> On 02/12/2013 12:54 AM, Pete Batard wrote:
>> On 2013.02.11 14:25, Hans de Goede wrote:
>>> I've taken a quick look at Nathan's proposal, and I plan to do a
>>> (personal) libusbx git tree with Nathan's hotplug code merged into it
>>> sometim
On Tue, Feb 12, 2013 at 2:38 PM, Nathan Hjelm wrote:
>
> On Feb 12, 2013, at 3:41 AM, Kustaa Nyholm
> wrote:
>
> > On 12.2.2013 12.29, "Hans de Goede" wrote:
> >>
> >> I know, but I'm operating under the assumption that Nathan will
> eventually
> >> do a libusb release with his code, at which p
On Feb 12, 2013, at 3:41 AM, Kustaa Nyholm wrote:
> On 12.2.2013 12.29, "Hans de Goede" wrote:
>>
>> I know, but I'm operating under the assumption that Nathan will eventually
>> do a libusb release with his code, at which point having API compatibility
>> would be good. And yes I know we don'
On 12.2.2013 12.29, "Hans de Goede" wrote:
>
>I know, but I'm operating under the assumption that Nathan will eventually
>do a libusb release with his code, at which point having API compatibility
>would be good. And yes I know we don't completely agree on this :)
I disagree having API/ABI compat
Hi,
On 02/12/2013 12:54 AM, Pete Batard wrote:
> On 2013.02.11 14:25, Hans de Goede wrote:
>> I've taken a quick look at Nathan's proposal, and I plan to do a
>> (personal) libusbx git tree with Nathan's hotplug code merged into it
>> sometime this week.
>
> Cool (as long as it stays personal or e
On Tue, Feb 12, 2013 at 7:54 AM, Pete Batard wrote:
> PS: I think the reason people are starting libusb/libusbx forks is
> because they are put off by the (relative) complexity of the Windows
> backend code. And that is pretty much a direct result of trying to
> implement an API that was designed
On 2013.02.11 14:25, Hans de Goede wrote:
> I've taken a quick look at Nathan's proposal, and I plan to do a
> (personal) libusbx git tree with Nathan's hotplug code merged into it
> sometime this week.
Cool (as long as it stays personal or explictly flagged as "EXPERIMENTAL
- MAY CHANGE AT ANY T
On Mon, Feb 11, 2013 at 11:21 PM, Hans de Goede wrote:
>>> There may be some gotcha's when you start using libwdi to replace the
>>> native windows driver with winusb / libusb0 / libusbk while an app
>>> using the hotplug stuff is open, but that is unrelated to the API, that
>>> is just tricky in
Hi,
On 02/11/2013 04:08 PM, Xiaofan Chen wrote:
> On Mon, Feb 11, 2013 at 10:25 PM, Hans de Goede wrote:
>> There may be some gotcha's when you start using libwdi to replace the
>> native windows driver with winusb / libusb0 / libusbk while an app
>> using the hotplug stuff is open, but that i
On Mon, Feb 11, 2013 at 10:25 PM, Hans de Goede wrote:
> On 02/10/2013 04:05 AM, Pete Batard wrote:
Has anyone actually had a peek?
>>>
>>> I have asked the other admins to take a look at
>>> Nathan's proposal. Hans has given one feedback.
>
> I've taken a quick look at Nathan's proposal, and
Hi,
On 02/10/2013 04:05 AM, Pete Batard wrote:
>>> Has anyone actually had a peek?
>>
>> I have asked the other admins to take a look at
>> Nathan's proposal. Hans has given one feedback.
I've taken a quick look at Nathan's proposal, and I plan to do a
(personal) libusbx git tree with Nathan's ho
On 11.2.2013 4.38, "Xiaofan Chen" wrote:
>
>Ubuntu is working toward that. On the other hand, I
>do not like Ubuntu Software center at all. I prefer
>Synaptic better and sometims use the command
>line apt.
I had high hopes for Ubuntu, but then Unity changed
it all and I had to give up on it, desp
On Sun, Feb 10, 2013 at 11:53 PM, Kustaa Nyholm
wrote:
> Open Source and Free software will need to provide the
> convenience of "AppStores" if they want to keep their
> foot hold not to mention expand it.
Ubuntu is working toward that. On the other hand, I
do not like Ubuntu Software center at a
On 10.2.2013 16.06, "Xiaofan Chen" wrote:
>>
>> Now, I find that disturbing this seems to imply something
>> that I as an application developer would not like.
>
>Why? That is kind of the norm for Linux. The user's
>system will either have a udev available or the
>other alternative mdev available.
On Sun, Feb 10, 2013 at 2:37 PM, Kustaa Nyholm
wrote:
> On 10.2.2013 3.03, "Xiaofan Chen" wrote:
>>
>>As for the implementation, you can see that Peter is not
>>satisfied with the Linux implementation. He has a good
>>point about udev not always available, especially among
>>Android and other emb
On 10.2.2013 5.05, "Pete Batard" wrote:
>
>That's the way I see it as well. I can't help but feel concerned that
>once again we have an API that originated straight from POSIX
>environments, and that hasn't bothered much in trying to at least
>outline what it's gonna mean for Windows. I kind of re
On 10.2.2013 3.03, "Xiaofan Chen" wrote:
>
>I think the hotplug API proposed there is not complete
>and I am sure Pete will have some different ideas
>about the API. libusbx and libusb will probably diverge
>on the Hotplug API.
I'm all for diverging at this point if it makes technical
sense.
>
On Sun, Feb 10, 2013 at 11:05 AM, Pete Batard wrote:
> I think our standing was that we'd start looking into it in 2.x, when we
> have completed the existing tasks we have lined up for 1.x.
> I know the milestone says 3.x, but I never got a chance to reorganize
> the items there the way I see them
On 2013.02.10 01:03, Xiaofan Chen wrote:
> On Sun, Feb 10, 2013 at 2:15 AM, Kustaa Nyholm
> wrote:
>> I'm sure many here also watch the libusb-devel list,
>>
>> perhaps excluding Pete.
I'm still following it, from afar.
But from a libusbx perspective, what I'm really interested in is what
actua
On Sun, Feb 10, 2013 at 2:15 AM, Kustaa Nyholm
wrote:
> I'm sure many here also watch the libusb-devel list,
>
> perhaps excluding Pete.
>
> They have made some progress in defining the hotplug
> API...what is our standing on this?
>
> Do we want to have a look at their vision, pick on it,
> or wh
38 matches
Mail list logo
