Re: [Libusbx-devel] Hotplug
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 deal with these won't include them in their event mask and >> never see them, where as apps which are interested can request them >> and differentiate between usable devices, and devices which have >> (some ?) descriptors filled in but are otherwise not usable. >> > > What about device suspend/resume? Will it cause the device to > arrive/left? I am not so sure if the behavior of suspend/resume > is the same or compatible across different OS (main ones first, > Windows, Mac OS X and Linux). AFAIK suspend/resume is handled by the device-driver, so if libusb has taken over the device, it won't be suspended / resumed. Regards, Hans -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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 >http://libusbx.sourceforge.net/api-1.0/group__poll.html >http://libusbx.sourceforge.net/api-1.0/mtasync.html First time I looked at that (Asynchronous API of libusb(x)), I'm sure you are right on all accounts, we certainly should be able to do way better here. br Kusti -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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_DEVICE_ARRIVED >LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_LEFT Why is necessary or beneficial to have different events for device plug in/out for driverless devices? 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(). br Kusti -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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 official hotplug interface for >the libusb 1.0 API. Sorry about the choice of words, I should have chosen some euphemism. Nothing personal Nathan, I don't know you, so don't take it or this personally. I'm sure Pete did not take it personally when you abandoned libusbx and called the HID functionality crap. As to having the opportunity to help libusb API development I politely decline, I hope that libusbx will take it's own course and libusb can go wherever it's fancy takes it, if it is going anywhere, which was one of the problems in the first place. Since you are not interested in libusbx I would have not involved you in this discussion at all had not someone else done it and it is not my habbit to speak behind the backs of people so I kept you in the loop. br Kusti -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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 called them ADDED / REMOVED Interesting how one can get worked up by choice of names (Referring to myself)! Following is just presented as my personal feelings nothing more, but I'm offering them as an example of how an 'outsider' might view the words. It is very difficult for the sender of a message to get into the shoes of the receiver and thus understand what the message means in the receivers context. ARRIVED and LEFT both are sort of personal and thus out of place here. 'He arrived' or 'Elvis has left the building'. LEFT is often and in many contexts paired with RIGHT so I don't like that. ARRIVED/ADDED/LEFT seem to beg the question ARRIVED where, ADDED to what, LEFT from what? LEFT what behind? Something is LEFT after we removed something else? REMOVED I kind of like because that is what this action is typically called. 'Life is too short to REMOVE USB safely' AVAILABLE and UNAVAILABLE have been suggested, this is also kind of reasonable and likable and I like the symmetry. But a device can be UNAVAILABLE because it is in use by some other application so that is not good. USB spec "Attachment and Removal" would suggest ATTACH and REMOVE, which is sort of nice as it stems from the 'official' wordage. Attachment is hard to spell but I just might manage ATTACH. SUSPEND and RESUME have also been suggested but those are sort of reserved names for different USB functionality so I would not go there. I suggested PLUGGED/UNPLUGGED. PLUGing is everyday usage that people use when they talk about usb devices, 'plug it it', 'plug it out' I have some reservations about PLUGGED as I'm not sure if anyone PLUGS a device though they often UNPLUG them, which to me says that it should be PLUGGED_IN and my internal need for symmetry then calls for PLUGGED_OUT, but that then is two words and an underscore where one should be enough. So the results of the Finnish Jury is that my vote goes to: ATTACHED / REMOVED Single words in everyday use with usb devices with pedigree in the official usb standard. just my 2 snt of this subject br Kusti -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Problem with Vendor class
Hi to all.My previous experience with USB was PIC 18F4550 and HID device so sorry if I ask something obvious. I have a problem with AVR32 UC3A0512 device and Vendor class. Hardware is EVK1100 clone (WaveShare EVK3A). I manage to build firmware with AtmelStudio 6 and install driver (libUSBwin32 or libUSBK). Device is visible by Windows without any warning. When I try xusb.exe from example folder my device is listed with two interfaces (0 without endpoints and 1 with two endpoints: interuput and isochronous). In my host PC application when I try to set active interface 1 I got error (from UC3A debug printout message is USB_REQ_TYPE_STANDARD). From what I read my host app must activate Vendor device by sending USB_REQ_TYPE_VENDOR request with appropriate alt configuration number? Is there any Vendor class example firmware for EVK1100 to test libusbx functionality? Identical results are with composite Vendor+HID device (HID part can be opened and send/receive data). Goran Radivojevic -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Bug? libusb_bulk_transfer timeouts with data in buffer but reports 0 bytes transferred
I'm experiencing some unexpected behavior using the function libusb_bulk_transfer on IN transaction. The version used is 1.0.14.10577 running on windows 7 x64. Sometimes when the functions returns with timeout I can see some data written in the buffer correctly but the transferred variable reports 0 bytes. On the next libusb_bulk_transfer call the data is not available anymore and therefore it get lost. Looking at the API documentation I read: "Also check|transferred|when dealing with a timeout error code. libusbx may have to split your transfer into a number of chunks to satisfy underlying O/S requirements, meaning that the timeout may expire after the first few chunks have completed. libusbx is careful not to lose any data that may have been transferred; do not assume that timeout conditions indicate a complete lack of I/O." Checking with an HW sniffer I see the packet sent from the devices correctly. The problem happens more often if the timeout is set to few ms (in my case I set 1ms to increase the error rate). Is this a knows bug? -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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 users > >> >> We can simply add: >> >> LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_ARRIVED >> LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_LEFT > > Why is necessary or beneficial to have different events for > device plug in/out for driverless devices? To detect transitions between the 2 states, ie a device gets plugged in, windows loads the standard driver for it, so from libusb pov it is driverless (as it does not have a driver which allows its use in libusb) this generates a LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_ARRIVED Some apps may respond to this by uninstalling the standard driver and attaching a libusb usable driver, ie the winusb driver, then the following 2 events are generated: LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_LEFT LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED Note that this very closely matches what exactly happens, when you uninstall the standard driver, windows will report this as the device having go away. And when you install the other driver it will report this as a new device being available. > 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 interested in this will want an event on the transitions from driverless to non-driverless too, so that they will know that the windows-device-manager is done with the driver installation. Regards, Hans -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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 interested in this will want an >event on the transitions from driverless to non-driverless >too, so that they will know that the windows-device-manager >is done with the driver installation. Ok, I see, I guess this could also be a 'property' of libsub_device (in my way of thinking), but I also see that it is handy to communicate this info via different events, even better so as far as my limited understanding of the this issue goes, that sound fine. Thanks for explaining. br Kusti -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
On Wed, Feb 13, 2013 at 7:45 PM, GORAN RADIVOJEVIC wrote: > I have a problem with AVR32 UC3A0512 device and Vendor > class. Hardware is > EVK1100 clone (WaveShare EVK3A). > I manage to build firmware with AtmelStudio 6 and install driver > (libUSBwin32 or libUSBK). Device is visible by > Windows without any warning. When I try xusb.exe from example > folder my device is listed with two interfaces > (0 without endpoints and 1 with two endpoints: interuput and > isochronous). Take note that libusbx does not isochronous transfer even though libusb0.sys has limited isoc support and libusbk.sys has better isoc support. Which version of libusbx are you using? You may need to use latest git version and use libusbk.sys driver only since libusbx has some problems with libusb0.sys as of now with regard to the filter driver and USB composite device. And take note WinUSB does not support isoc transfer. Please post the output of xusb.exe. I am not so sure if your device is a USB composite device with two interfaces (in that case, this device violate USB spec since the 2nd interface has a isoc interface) or a device with single interface but with an alternative interace (then it is okay). > In my host PC application when I try > to set active interface 1 I got error (from UC3A debug printout > message is USB_REQ_TYPE_STANDARD). From what > I read my host app must activate Vendor device by sending > USB_REQ_TYPE_VENDOR request with appropriate alt > configuration number? Is there any Vendor class example > firmware for EVK1100 to test libusbx functionality? > Identical results are with composite Vendor+HID device > (HID part can be opened and send/receive data). Please post the output of xusb.exe. -- Xiaofan -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug? libusb_bulk_transfer timeouts with data in buffer but reports 0 bytes transferred
On 13/02/13 13:02, Ramon Zambelli wrote:
I'm experiencing some unexpected behavior using the function
libusb_bulk_transfer on IN transaction. The version used is
1.0.14.10577 running on windows 7 x64.
Sometimes when the functions returns with timeout I can see some data
written in the buffer correctly but the transferred variable reports 0
bytes. On the next libusb_bulk_transfer call the data is not available
anymore and therefore it get lost.
Looking at the API documentation I read:
"Also check|transferred|when dealing with a timeout error code.
libusbx may have to split your transfer into a number of chunks to
satisfy underlying O/S requirements, meaning that the timeout may
expire after the first few chunks have completed. libusbx is careful
not to lose any data that may have been transferred; do not assume
that timeout conditions indicate a complete lack of I/O."
Checking with an HW sniffer I see the packet sent from the devices
correctly.
The problem happens more often if the timeout is set to few ms (in my
case I set 1ms to increase the error rate).
Is this a knows bug?
I've experienced something similar and it's been on my TODO list for
many months to have a look at it. Can you try the attached patch? This
helps in my situation where I see this issue, although I'm still seeing
some data loss which I've not had time to look into in more detail.
Regards,
Toby
>From 1ca6732246d1e7bbb54bc52f2560a0abaf5bb983 Mon Sep 17 00:00:00 2001
From: Toby Gray
Date: Wed, 13 Feb 2013 15:21:52 +
Subject: [PATCH] Windows: Update transferred data on timeout or cancel.
When handling aborted transfer it's possible that some data (but not
the full buffer) was transferred. This change ensures that this
partially transferred data is recorded and passed up to the caller.
# Please enter the commit message
for your changes. Lines starting # with '#' will be ignored, and an
empty message aborts the commit. # On branch master # Your branch is
ahead of 'origin/master' by 27 commits. # # Changes to be committed:
libusb/os/windows_usb.c # # Untracked files: # (use "git add
..." to include in what will be committed) # # .emacs.desktop #
emacs-X11.exe.stackdump
---
libusb/os/windows_usb.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 8a8caf4..fff21f3 100644
--- a/libusb/os/windows_usb.c
+++ b/libusb/os/windows_usb.c
@@ -2030,9 +2030,9 @@ static void windows_transfer_callback(struct usbi_transfer *itransfer, uint32_t
{
struct libusb_transfer *transfer = USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
struct windows_device_priv *priv = _device_priv(transfer->dev_handle->dev);
- int status;
+ int status, istatus;
- usbi_dbg("handling I/O completion with errcode %d", io_result);
+ usbi_dbg("handling I/O completion with errcode %d, size %d", io_result, io_size);
switch(io_result) {
case NO_ERROR:
@@ -2047,6 +2047,10 @@ static void windows_transfer_callback(struct usbi_transfer *itransfer, uint32_t
status = LIBUSB_TRANSFER_TIMED_OUT;
break;
case ERROR_OPERATION_ABORTED:
+ istatus = priv->apib->copy_transfer_data(SUB_API_NOTSET, itransfer, io_size);
+ if (istatus != LIBUSB_TRANSFER_COMPLETED) {
+ usbi_dbg("Failed to copy partial data in aborted operation: %d", istatus);
+ }
if (itransfer->flags & USBI_TRANSFER_TIMED_OUT) {
usbi_dbg("detected timeout");
status = LIBUSB_TRANSFER_TIMED_OUT;
--
1.7.9
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug? libusb_bulk_transfer timeouts with data in buffer but reports 0 bytes transferred
On Wed, Feb 13, 2013 at 9:02 PM, Ramon Zambelli wrote: > Checking with an HW sniffer I see the packet sent from the > devices correctly. Could you post the debug log (set LIBUSB_DEBUG environmental variable to 4) and the HW sniffer data comparison. Since you have the HW sniffer, do you notice errors like data toggle error or things like that. > The problem happens more often if the timeout is set > to few ms (in my case I set 1ms to increase the error rate). You can not set such a low timeout in practice since Windows (or Linux or Mac OS X) is not a real time OS. -- Xiaofan -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug? libusb_bulk_transfer timeouts with data in buffer but reports 0 bytes transferred
On 13-Feb-13 4:27 PM, Toby Gray wrote: > I've experienced something similar and it's been on my TODO list for > many months to have a look at it. Can you try the attached patch? This > helps in my situation where I see this issue, although I'm still > seeing some data loss which I've not had time to look into in more detail. Great! The patch seems to work like a charm. Thanks a lot. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with Vendor class
GORAN RADIVOJEVIC wrote: > > My previous experience with USB was PIC 18F4550 and HID device so > sorry if I ask something obvious. > I have a problem with AVR32 UC3A0512 device and Vendor class. Hardware > is EVK1100 clone (WaveShare EVK3A). > I manage to build firmware with AtmelStudio 6 and install driver > (libUSBwin32 or libUSBK). Device is visible by > Windows without any warning. When I try xusb.exe from example folder > my device is listed with two interfaces > (0 without endpoints and 1 with two endpoints: interuput and isochronous). Is it really two interfaces? Or is it one interface with two alternate settings? There is a big difference. > In my host PC application when I try > to set active interface 1 I got error (from UC3A debug printout > message is USB_REQ_TYPE_STANDARD). What was the error? > From what I read my host app must activate Vendor device by sending > USB_REQ_TYPE_VENDOR request with > appropriate alt configuration number? No. Vendor requests have nothing to do with vendor-class devices. You can have vendor requests even on standard class devices. My blind guess is that you were trying to claim interface 1, when you should have been claiming interface 0 with alternate setting 1. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Bug? libusb_bulk_transfer timeouts with data in buffer but reports 0 bytes transferred
This patch makes sense, and I realize that I wasn't as "careful" as the libusbx documentation state to not lose any data when I wrote this section of code. Thanks to the both of you for both the report and the fix. The patch has now been applied and pushed. Regards, /Pete -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] linux: Don't set the USBFS_URB_SHORT_NOT_OK flag on the last urb
Looks good to me - pushed. I added some parenthesis around the new test, as I know some compilers will complain (possibly in pedantic mode) about ensuring to clarify that the test is as intended, and not just a result of unexpected operator precedence. Regards, /Pete PS: I screwed up the ticket reference in the commit message - used libusb's 142 instead of our 82. Oh well... #82 has now been (manually) closed. On 2013.02.11 15:24, Xiaofan Chen wrote: > On Mon, Feb 11, 2013 at 11:21 PM, Hans de Goede wrote: >> This fixes; https://libusb.org/ticket/142 >> >> Signed-off-by: Hans de Goede >> --- >> libusb/os/linux_usbfs.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c >> index 0ca02e1..d18d009 100644 >> --- a/libusb/os/linux_usbfs.c >> +++ b/libusb/os/linux_usbfs.c >> @@ -1787,7 +1787,7 @@ static int submit_bulk_transfer(struct usbi_transfer >> *itransfer, >> urb->type = urb_type; >> urb->endpoint = transfer->endpoint; >> urb->buffer = transfer->buffer + (i * bulk_buffer_len); >> - if (use_bulk_continuation && !is_out) >> + if (use_bulk_continuation && !is_out && i != num_urbs - 1) >> urb->flags = USBFS_URB_SHORT_NOT_OK; >> if (i == num_urbs - 1 && last_urb_partial) >> urb->buffer_length = transfer->length % >> bulk_buffer_len; >> -- >> 1.8.1.2 >> > > Nice. Created a libusbx ticket to capture this one so it can go into 1.0.15. > https://github.com/libusbx/libusbx/issues/82 > -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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. We're not the USB committee. We're not in the process of releasing a new standard to the world with little margin for error. So could we please dial down the "we should make it perfect from the get-go" fallacy, when, regardless of what libusb decides to do, we can slap a big EXPERIMENTAL on our HP API for a few iterations and get actual user feedback? Or are we so arrogant that we think we can figure the whole thing by ourselves, without the need for real-life implementation reports? Now, that's not to say that the process of trying to devise what we we *think* our users will want from an hotplug API is a waste of time, in fact that's where we want to start. But the way this discussion has extended into the minutia of trying to finalize what names we should use for driverless device handling, when we still haven't a clue (or at least I don't) how we're going to implement this whole lot on Windows, and whether it'll result in something that's workable for our users, makes we wonder if we're not pushing this whole process a bit too far. Unless an API ends up as a code proposal that can be tested, and that can generate feedback from as many users as possible (which, IMO, is better done through actual releases that include experimental features, rather than RCs), I don't think it should be tagged or even remotely considered as "final", and we probably should try to keep some room for some potentially drastic changes. What's more, we're building a library, with developers as a target audience. So I would expect any developer starting to use a really brand new feature to have room to modify their code if the API evolves at short notice. And maybe some of you here feel that libusbx should be tied to the libusb API, but I don't see much point in participating in a fork if we can't go in our separate direction should we think it'll help our users better, especially if the reason for a deviation is users reporting that a first proposal doesn't work that well for them. And yeah, this means that our users may eventually have to choose between two incompatible APIs and non interchangeable libraries, but that's really the essence of forks (and that's alos why I believe we should only introduce hp in 2.x of libusbx to alleviate the problem). So, to get back to the current point, in case you ask me right now what kind of cross-platform API we should go with for hotplug and whether we want to go with DRIVERLESS_WHATEVER events, I'll continue to state "I don't know". And I'm not gonna know until I have a proposal with some Windows code, alongside the Linux and OS X one, that we can place in the end of our users, so that we finally start to receive feedback. Then again, I'm not going to prevent anybody from knocking themselves out with elaborating on what they think should go in a final HP API. Regards, /Pete -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Hotplug
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 to recent libusb progress and that lead to the discussion (more about the usage of words than about the actual API). >And maybe some of you here feel that libusbx should be tied to the >libusb API, but I don't see much point in participating in a fork if we >can't go in our separate direction should we think it'll help our users >better, especially if the reason for a deviation is users reporting that >a first proposal doesn't work that well for them. And yeah, this means >that our users may eventually have to choose between two incompatible >APIs and non interchangeable libraries, but that's really the essence of >forks (and that's alos why I believe we should only introduce hp in 2.x >of libusbx to alleviate the problem). I'm with you there. > >So, to get back to the current point, in case you ask me right now what >kind of cross-platform API we should go with for hotplug and whether we >want to go with DRIVERLESS_WHATEVER events, I'll continue to state "I >don't know". And I'm not gonna know until I have a proposal with some >Windows code, alongside the Linux and OS X one, that we can place in the >end of our users, so that we finally start to receive feedback. That's fine, I just wanted to understand why it might be beneficial to do what was discussed and got educated. cheers Kusti -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
