Change in management

Daniel Drake offered to take over the project since it has been stagnant
for a while now.

His plans mirrored my plans closely and I don't want to stand in the way
of someone who is willing to put the effort into leading and
implementing the 1.0 API.

So I've made him project admin and he'll take over leading the project.

I will hopefully still be involved in the future, but merely as a
developer.

JE

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

libusb future

Hi all,

As Johannes Erdfelt wrote in a mail earlier today, I'm now in control of 
the libusb project. libusb development has been stalled for several 
months, mainly because Johannes does not currently have enough time to 
work on the project.

I use libusb-0.1 in one of my projects, but decided to drop it as it was 
lacking some functionality I wanted. I could not find any equivalent 
libraries offering the feature set I was hoping for, so I sat down to 
write my own USB access library. We later realised that the goals and 
design principles of my own library fit in with the original libusb 
ideas rather well, so it makes sense for my work to become the future 
libusb.

Many thanks to Johannes for being open/flexible in this respect -- 
libusb is clearly his baby but he has been very co-operative in 
transferring it given the project inactivity. I'll do my best to take 
good care of it :)

A little about me: I'm a Linux kernel contributor and have worked on 
various USB device drivers. I also lead Gentoo's kernel team. My current 
project which inspired the new USB library is a fingerprint scanning 
project: http://www.reactivated.net/fprint/

My plans for libusb:

1. I will undertake basic maintenance of the widely-used libusb-0.1 
codebase - I'll apply simple patches and do infrequent releases.

Re: OpenUSB Linux Update

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb future

On Jan 2, 2008 8:24 AM, Daniel Drake <dsd <at> gentoo.org> wrote:
> 3. I will rename my new USB library project (fpusb) to "libusb-1.0". In
> other words, this can be viewed as a complete rewrite of libusb
> (although with various borrowed code/ideas). The goals are basically to
> provide asynchronous I/O capabilities in a lightweight library, while
> offering poll fd's for decent mainloop integration. You can read a bit
> more about my efforts here:
> http://www.reactivated.net/fprint/wiki/Fpusb
>
> I will elaborate more on the goals of libusb-1.0 in a future mail. Some
> portability will be lost in the short term (it'll be Linux only), but I
> hope to attract interest from developers experienced with USB I/O layers
> of other operating systems, and with their help it will hopefully become
> as portable as libusb-0.1. (If such people are interested already, I'd
> suggest not doing anything more than looking at the code for now, give
> the design a bit more time to settle first).
>

Just wondering if the new libusb-1.0 can be made to be compatible with
libusb-win32 1.0 which is the new development version of libusb-win32.

Website (wiki): http://libusb-win32.wiki.sourceforge.net/
Developer: Stephan Meyer
0.1 branch API which is based on libusb API but adds isochronous transfer
and asynchronous I/O. It is already working quite well. So this is in line
with your goals.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/src/usb.h?view=markup

1.0 branch API which is basically compatible with the 0.1 API but adds
several backend (libusb-win32 device driver, native HID and WinUSB). It is
still under development.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup

Why adds HID backend? Because HID driver is built in Windows 98 and later, it is
very popular for many USB device to disguise as USB device (just look at the
Linux HID blacklist). It is not that simple to detach the HID driver under
Windows without manual intervention so it makes sense to have an HID backend.
This might make sense for Linux in the future because of the upcoming
HID Simple Driver Interface (http://lkml.org/lkml/2007/3/5/20).
Even though HID API is quite platform specific, it is quite well understood
in major operating systems (Windows, Linux, BSDs, Solaris and Mac OS X)
so that it is possible to write a platform specific backend. This will help
libusb to solve one major problem for HID device: kernel HID driver detaching
is only possible under Linux using libusb API.

Why adds WinUSB for libusb-win32 1.0? It is to solve the Windows Vista 64
driver signing problem. The future usbfs is kind of similar to WinUSB (to
expose USB endpoints). So this might be kind of insiring as well.

I understand Windows and Linux are quite different and I am not a programmer
myself so I am not so sure if this is all feasible. But I just feel it is worth
considering.

Xiaofan
http://mcuee.blogspot.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: libusb future

Xiaofan Chen wrote:
> Just wondering if the new libusb-1.0 can be made to be compatible with
> libusb-win32 1.0 which is the new development version of libusb-win32.

Thanks for the information. I'm certainly interested in having future 
incarnations of libusb portable to windows, I'll spend some time looking 
over that material sometime soon.

Cheers,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: libusb future

Daniel Drake wrote:
> As Johannes Erdfelt wrote in a mail earlier today, I'm now in control of 
> the libusb project.
> ...
> 3. I will rename my new USB library project (fpusb) to "libusb-1.0". In 
> other words, this can be viewed as a complete rewrite of libusb 
> (although with various borrowed code/ideas). The goals are basically to 
> provide asynchronous I/O capabilities in a lightweight library, while 
> offering poll fd's for decent mainloop integration.

How open do you expect to be?  That is, do you expect to be a benevolent
dictator, having sole control over all aspects of the code base?  Or do
you expect it to be a cooperative development effort?

For example, in my opinion, many of your API names are not necessarily
intuitive; I couldn't guess what they do without consulting a
reference.  Part of that comes from abbreviating.  And what led you to
use "msg" to describe all of the USB transfers?  In the USB spec,
control pipes are the only ones that carry "messages".  Do you expect to
open this up for discussion?

This does not seem to support isochronous pipes yet.  Do you have a plan
for that?

And do we all expect to continue having both libusb and openusb
discussions on this one mailing list?  Personally, I think the
cross-pollenization is probably quite valuable.

--

-- 
Tim Roberts, timr <at> probo.com
Providenza & Boekelheide, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: libusb future

Tim Roberts wrote:
> How open do you expect to be?  That is, do you expect to be a benevolent
> dictator, having sole control over all aspects of the code base?  Or do
> you expect it to be a cooperative development effort?

I hope for it to be cooperative, but I'm not sure how much I can expect 
other people to contribute.

> For example, in my opinion, many of your API names are not necessarily
> intuitive; I couldn't guess what they do without consulting a
> reference.  Part of that comes from abbreviating.  And what led you to
> use "msg" to describe all of the USB transfers?  In the USB spec,
> control pipes are the only ones that carry "messages".  Do you expect to
> open this up for discussion?

Indeed, feedback is appreciated. I am not yet happy with the naming 
aspects of the API which I have already meddled with a few times since 
starting the project. Suggestions appreciated.

I can probably guess, but which parts did you find unintuitive?

Do you think I should refer to control transfers as "messages" but bulk 
ones as something else? (i guess yes). libusb_submit_bulk_transfer()? 
libusb_submit_bulk_urb()?

> This does not seem to support isochronous pipes yet.  Do you have a plan
> for that?

Yes, it's planned, just haven't gone as far to implement it yet. There 
is certainly work to be done before this can be released as v1.0.

> And do we all expect to continue having both libusb and openusb
> discussions on this one mailing list?  Personally, I think the
> cross-pollenization is probably quite valuable.

Agreed, I'm sure we can learn from each other.

Thanks,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: libusb future

Daniel Drake wrote:
> Indeed, feedback is appreciated. I am not yet happy with the naming 
> aspects of the API which I have already meddled with a few times since 
> starting the project. Suggestions appreciated.
>
> I can probably guess, but which parts did you find unintuitive?
>   

Well, certainly the "poll" routines do not explain themselves.  I also
don't like "intr" and "devh".  And, since I'm getting picky,
fpusb_dev_get_descriptor implies that it will gets any kind of
descriptor (rather than just the device descriptor), and
fpusb_dev_get_config doesn't mention the word "descriptor".  You don't
have an API to fetch string descriptors yet, do you?

I like APIs that read like a sentence fragment, with a verb and a noun.

> Do you think I should refer to control transfers as "messages" but bulk 
> ones as something else? (i guess yes). libusb_submit_bulk_transfer()? 
> libusb_submit_bulk_urb()?
>   

Personally, I would refer to all of them as "transfers".  The message vs
stream distinction in the spec is not really very useful.  From a
software point of view, control, bulk, and interrupt transfers are
identical, except that some control transfers have a pre-defined format.

I'm torn about how to handle the naming of sync vs async routines, even
in my own code.  Although "libusb_submit_bulk_urb" accurately reflects
what the routine does, in fact the libusb user doesn't know about or
think in terms of URBs.  That is an implementation detail.

I could be talked into this:
    libusb_submit_bulk_transfer
    libusb_submit_bulk_transfer_async
or this:
    libusb_submit_bulk_transfer_and_wait
    libusb_submit_bulk_transfer

--

-- 
Tim Roberts, timr <at> probo.com
Providenza & Boekelheide, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: libusb future

On Jan 3, 2008 7:16 AM, Tim Roberts <timr <at> probo.com> wrote:
> I'm torn about how to handle the naming of sync vs async routines, even
> in my own code.  Although "libusb_submit_bulk_urb" accurately reflects
> what the routine does, in fact the libusb user doesn't know about or
> think in terms of URBs.  That is an implementation detail.
>
> I could be talked into this:
>     libusb_submit_bulk_transfer
>     libusb_submit_bulk_transfer_async
> or this:
>     libusb_submit_bulk_transfer_and_wait
>     libusb_submit_bulk_transfer
>

libusb-win32 0.1 has already implemented isochronous transfer and asynchronous
 I/O support.

http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup

int usb_isochronous_setup_async(usb_dev_handle *dev, void **context,
                                   unsigned char ep, int pktsize);
int usb_bulk_setup_async(usb_dev_handle *dev, void **context,
                           unsigned char ep);
int usb_interrupt_setup_async(usb_dev_handle *dev, void **context,
                                unsigned char ep);

int usb_submit_async(void *context, char *bytes, int size);
int usb_reap_async(void *context, int timeout);
int usb_reap_async_nocancel(void *context, int timeout);
int usb_cancel_async(void *context);
int usb_free_async(void **context);

How do you like the above names?

Xiaofan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: libusb future

Xiaofan Chen wrote:
>
> libusb-win32 0.1 has already implemented isochronous transfer and asynchronous
>  I/O support.
>
> http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/src/dll/usb.h?view=markup
>
> int usb_isochronous_setup_async(usb_dev_handle *dev, void **context,
>                                    unsigned char ep, int pktsize);
> int usb_bulk_setup_async(usb_dev_handle *dev, void **context,
>                            unsigned char ep);
> int usb_interrupt_setup_async(usb_dev_handle *dev, void **context,
>                                 unsigned char ep);
>
> int usb_submit_async(void *context, char *bytes, int size);
> int usb_reap_async(void *context, int timeout);
> int usb_reap_async_nocancel(void *context, int timeout);
> int usb_cancel_async(void *context);
> int usb_free_async(void **context);
>   

That's an interesting approach.  The first three routines essentially
create "pipe handles", so that a single routine can do all of the URB
submission.

Because of that, I think I would have used names more like
"usb_create_pipe_handle".  After all, the "usb_xxx_setup_async" routines
aren't really setting up a request.  And, of course, the last 5 APIs
don't have any nouns, so it isn't clear what is being reaped, canceled,
or freed.

--

-- 
Tim Roberts, timr <at> probo.com
Providenza & Boekelheide, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/