|
»
« Return to Thread: libusb future
Re: libusb future
by Xiaofan Chen
::
Rate this Message:
On Jan 2, 2008 8:24 AM, Daniel Drake <dsd@...> 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/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel
> 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/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel
« Return to Thread: libusb future
| Free embeddable forum powered by Nabble | Forum Help |
