libusb-1.0 for NetBSD

[Xiaofan Chen]

Just want to let the users here know that libusb-1.0.9 release
support NetBSD (using OpenBSD backend). You are welcome
to try it.
http://www.libusb.org/wiki/libusb-1.0

libusbx is a fork of libusb-1.0 and it has more active development.
http://www.libusbx.org/
http://www.phoronix.com/scan.php?page=news_item&px=MTEwNTY

It has also NetBSD support. But right now the OpenBSD/NetBSD
codes are a bit behind the other OS (Linux, Mac OS X and Windows)
since it does not support some target features for the upcoming
1.0.12 release, eg, the topology API.
http://sourceforge.net/apps/trac/libusbx/roadmap
http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commit;h=cfb8610242394d532778a483570089c2bed52c84

Also missing is this minor one.
http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commit;h=6d47fa1bc52562f673c30e5fd36f8ae44ed102e8

Hopefully those who are interested in libusbx can subscribe to libusbx
mailing list and help improve the codes for NetBSD.

--
Xiaofan

[Xiaofan Chen]

On Wed, May 30, 2012 at 10:12 PM, Thomas Klausner <t...@giga.or.at> wrote:

> On Wed, May 30, 2012 at 09:01:08PM +0800, Xiaofan Chen wrote:
>> Just want to let the users here know that libusb-1.0.9 release
>> support NetBSD (using OpenBSD backend). You are welcome
>> to try it.
>> http://www.libusb.org/wiki/libusb-1.0
>

> Neat, thanks for the note.
> I've packaged it for pkgsrc, it's in pkgsrc/devel/libusb1.
> I haven't tested it yet.

Thanks. You may want to try libusb-compat-0.1 as well.
http://www.libusb.org/wiki/libusb-compat-0.1

Take note libusb-0.1 is no longer maintained.
http://www.libusb.org/
Legacy API: libusb-0.1
Development status: libusb-0.1 is deprecated and will have
no further changes or releases


--
Xiaofan

[Xiaofan Chen]

BTW, I have done a bit of test for libusb-1.0 under
NetBSD 5.1.2 and it seems to work fine. I will try
more tests under 6.0 Beta 2.

Example: libusbdotnet (using libusb-1.0 backend) under NetBSD
http://libusb.6.n5.nabble.com/OpenBSD-backend-test-of-libusb-1-0-9-with-libusbdotnet-td5656945.html#a5656996


--
Xiaofan

[Jeremy C. Reed]

On Wed, 30 May 2012, Thomas Klausner wrote:

> On Wed, May 30, 2012 at 09:01:08PM +0800, Xiaofan Chen wrote:

> > Just want to let the users here know that libusb-1.0.9 release
> > support NetBSD (using OpenBSD backend). You are welcome
> > to try it.
> > http://www.libusb.org/wiki/libusb-1.0
>

> Neat, thanks for the note.
> I've packaged it for pkgsrc, it's in pkgsrc/devel/libusb1.
> I haven't tested it yet.

I built it with --enable-examples-build. How to use the examples?

sunflower:examples$ ./listdevs
sunflower:examples$ ./dpfp
Could not find/open device
sunflower:examples$ ./dpfp_threaded
Could not find/open device

The listdevs shows nothing.

[Xiaofan Chen]

On Wed, May 30, 2012 at 10:31 PM, Jeremy C. Reed <re...@reedmedia.net> wrote:
> I built it with  --enable-examples-build. How to use the examples?
>
> sunflower:examples$ ./listdevs
> sunflower:examples$ ./dpfp
> Could not find/open device
> sunflower:examples$ ./dpfp_threaded
> Could not find/open device
>
> The listdevs shows nothing.

libusb-1.0 under OpenBSD/NetBSD use ugen, so only
ugen device are supported. And you may need to
set up proper permission to run the examples
under normal user account. You can try run as
root first or use sudo.



--
Xiaofan

[Jeremy C. Reed]

sunflower:examples$ sudo ./listdevs
sunflower:examples$ ls -l /dev/*ugen*
crw-rw---- 1 root photos 64, 0 Mar 6 2009 /dev/ugen0.00
crw-rw---- 1 root photos 64, 1 Mar 6 2009 /dev/ugen0.01
crw-rw---- 1 root photos 64, 2 May 21 16:09 /dev/ugen0.02
crw-rw---- 1 root photos 64, 3 Mar 6 2009 /dev/ugen0.03
crw-rw---- 1 root photos 64, 4 Mar 6 2009 /dev/ugen0.04
crw-rw---- 1 root photos 64, 5 Mar 6 2009 /dev/ugen0.05
crw-rw---- 1 root photos 64, 6 Mar 6 2009 /dev/ugen0.06
crw-rw---- 1 root photos 64, 7 May 13 2010 /dev/ugen0.07
crw-rw---- 1 root photos 64, 8 Mar 6 2009 /dev/ugen0.08
crw-rw---- 1 root photos 64, 9 Mar 6 2009 /dev/ugen0.09
crw-rw---- 1 root photos 64, 10 Mar 6 2009 /dev/ugen0.10
crw-rw---- 1 root photos 64, 11 Mar 6 2009 /dev/ugen0.11
crw-rw---- 1 root photos 64, 12 Mar 6 2009 /dev/ugen0.12
crw-rw---- 1 root photos 64, 13 Mar 6 2009 /dev/ugen0.13
crw-rw---- 1 root photos 64, 14 Mar 6 2009 /dev/ugen0.14
crw-rw---- 1 root photos 64, 15 Mar 6 2009 /dev/ugen0.15
sunflower:examples$ id
uid=1000(reed) gid=100(users) groups=100(users),0(wheel),1007(photos)
sunflower:examples$ sudo id
uid=0(root) gid=0(wheel)
groups=0(wheel),2(kmem),3(sys),4(tty),5(operator),20(staff),31(guest)
sunflower:examples$

What does the output supposed to look like?

My kernel is 6.0_BETA from around April 16.

(My main problem is with CUPs using USB. I will redocument my problems
with it.)

[Xiaofan Chen]

Since I am one of the admins of libusbx (non-developer admin,
I mainly contributed by testing and support since I
am not a software guy), here is the run log for libusbx
1.0.11 under NetBSD 6.0 Beta 1.


localhost$ ./configure --enable-examples-build
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i386-unknown-netbsdelf6.0.
checking host system type... i386-unknown-netbsdelf6.0.
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... match_pattern
/lib[^/]+(\.so|_pic\.a)$
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... NetBSD ld.elf_so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for windres... no
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... NetBSD (using OpenBSD backend)
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking sys/timerfd.h usability... no
checking sys/timerfd.h presence... no
checking for sys/timerfd.h... no
checking whether TFD_NONBLOCK is declared... no
checking whether to use timerfd for timing... no (header not available)
checking for struct timespec... yes
checking for sigaction... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for gettimeofday... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands

localhost$ make
make all-recursive
Making all in libusb
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-openbsd_usb.lo
os/openbsd_usb.c: In function '_sync_control_transfer':
os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules
CC libusb_1_0_la-threads_posix.lo
CCLD libusb-1.0.la
Making all in doc
Making all in examples
CC listdevs.o
CCLD listdevs
CC xusb.o
CCLD xusb
CC dpfp.o
CCLD dpfp
CC dpfp_threaded-dpfp_threaded.o
CCLD dpfp_threaded

localhost$ cd examples/

localhost$ ./listdevs
1366:0101 (bus 0, device 2)

localhost$ ./xusb 1366:0101
Using libusbx v1.0.11.10513

Opening device...
speed: 12 Mbit/s (USB 1.0 FullSpeed)

Reading device descriptor:
length: 18
device class: 0
S/N: 3
VID:PID: 1366:0101
bcdDevice: 0001
iMan:iProd:iSer: 1:2:3
nb confs: 1

Reading configuration descriptors:
nb interfaces: 1
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 81
max packet size: 0040
polling interval: 00
endpoint[1].address: 02
max packet size: 0040
polling interval: 00

Claiming interface 0...

Reading string descriptors:
String (0x01): "SEGGER"
String (0x02): "J-Link"
String (0x03): "xxxxxxxxxx"

Releasing interface 0...
Closing device...



--
Xiaofan

[Jeremy C. Reed]

On Wed, 30 May 2012, Xiaofan Chen wrote:

> Since I am one of the admins of libusbx (non-developer admin,
> I mainly contributed by testing and support since I
> am not a software guy), here is the run log for libusbx
> 1.0.11 under NetBSD 6.0 Beta 1.

I made a package for libusbx-1.0.11 (based on the new libusb1 package).

Thanks for the example.

But no output:

sunflower:examples$ ./listdevs
sunflower:examples$ sudo ./listdevs
sunflower:examples$

sunflower:examples$ usbdevs
addr 1: UHCI root hub, vendor 0x8086
addr 1: UHCI root hub, vendor 0x8086
addr 1: EHCI root hub, vendor 0x8086
addr 2: CNF7051, Chicony Electronics Co., Ltd.
addr 3: USB2.0-CRW, Generic
addr 1: UHCI root hub, vendor 0x8086
addr 1: UHCI root hub, vendor 0x8086
addr 1: UHCI root hub, vendor 0x8086
addr 1: UHCI root hub, vendor 0x8086
addr 1: EHCI root hub, vendor 0x8086
addr 2: HL-5150D, Brother

dmesg shows:

ugen0 at uhub7 port 1
ugen0: Canon Inc. Canon Digital Camera, rev 2.00/0.02, addr 3
ugen0: detached
ugen0: at uhub7 port 1 (addr 3) disconnected

(from earlier plugged in device used with gphoto2.)

[Thomas Klausner]

On Wed, May 30, 2012 at 10:18:59PM +0800, Xiaofan Chen wrote:
> Thanks. You may want to try libusb-compat-0.1 as well.
> http://www.libusb.org/wiki/libusb-compat-0.1

I've packaged this as well and made it depend on libusbx for now.

We need two switches in pkgsrc so users can decide on libusb1 vs.
libusbx and libusb vs libusb-compat...
Thomas

[Eric Haszlakiewicz]

On Wed, May 30, 2012 at 04:45:13PM +0100, Stephen Borrill wrote:

> On Wed, 30 May 2012, Xiaofan Chen wrote:
> >libusb-1.0 under OpenBSD/NetBSD use ugen, so only
> >ugen device are supported.
>

> One of the problems with libusb with NetBSD is that it cannot detach a
> driver and reattach ugen. So if uhid has attached, you are stuck with it.

I just ran into this problem myself. I was thinking of adjusting the usb
code so all devices can support the same ioctl's that ugen supports, but
things got a bit trickier than I expected.
One of the problems is that not all usb devices have a device node in /dev,
and there's no way to walk the device tree by (e.g.) operating on a hub
device (/dev/usb0) so there doesn't seem to be a way to indicate that you
want to do something with a particular usb device. :(

eric

[David Young]

Sometimes I have wished for a way to modify the kernel's
autoconfiguration data---by which I mean the code & structs derived from
the kernel's config(5) file---from userland in order to stop one driver
from ever (re-)attaching to a device or to make a new/different driver
attach. It seems to me that this would be a generally useful facility
to have.

It would be nice if we had a richer set of locators, too: strings, byte
tuples, ....

It seems like one or more person has started the project of revamping
autoconf(9) but abandoned it for one reason or another. I'd sure like
to see someone finish. I think that it would un-block one or two of my
personal projects and help others' projects to get started, too.

Dave

--
David Young
dyo...@pobox.com Urbana, IL (217) 721-9981

[Xiaofan Chen]

On Wed, May 30, 2012 at 10:31 PM, Jeremy C. Reed <re...@reedmedia.net> wrote:

You need to have real ugen device attached. To check that, you can use
"dmesg | grep ugen".

localhost$ dmesg | grep ugen
ugen0 at uhub0 port 1
ugen0: SEGGER J-Link, rev 1.10/0.01, addr 2


--
Xiaofan

[Xiaofan Chen]

On Thu, May 31, 2012 at 1:26 AM, Eric Haszlakiewicz <e...@nimenees.com> wrote:
> On Wed, May 30, 2012 at 04:45:13PM +0100, Stephen Borrill wrote:
>> On Wed, 30 May 2012, Xiaofan Chen wrote:
>> >libusb-1.0 under OpenBSD/NetBSD use ugen, so only
>> >ugen device are supported.
>>
>> One of the problems with libusb with NetBSD is that it cannot detach a
>> driver and reattach ugen. So if uhid has attached, you are stuck with it.

The kernel detaching and attaching function of libusb is
only implemented under Linux where the usbfs driver
can be the fall back driver if you detach the existing
device driver and usbfs is what libusb is based on under
Linux.

For Windows, it is possible to switching driver manually
or using program but it is an expensive operation and thus
it is out of libusb.

I am not so sure if NetBSD can borrow the idea from
FreeBSD's USB stack written by HPS.

It is a very nice feature that FreeBSD 9 loads ugen along
with uhid for generic USB HID device like my Microchip
PICKit 2. With that, I can use libusb based program on
generic HID device without the need to do anything.

ugen0.2: <Microchip Technology Inc.> at usbus0
uhid0: <Microchip Technology Inc. PICkit 2 Microcontroller Programmer,
class 0/0, rev 2.00/0.02, addr 2> on usbus0
uhid0: at uhub0, port 1, addr 2 (disconnected)

But of course this will be quite a bit of work since it
involve kernel modification.

The other possibility is to learn from Mac OS X where
you can use a code-less kext to prevent the existing
kernel driver from attaching to a device (or a class
of device) based on certain criteria.

> I just ran into this problem myself.  I was thinking of adjusting the usb
> code so all devices can support the same ioctl's that ugen supports, but
> things got a bit trickier than I expected.
> One of the problems is that not all usb devices have a device node in /dev,
> and there's no way to walk the device tree by (e.g.) operating on a hub
> device (/dev/usb0) so there doesn't seem to be a way to indicate that you
> want to do something with a particular usb device. :(

--
Xiaofan

[Xiaofan Chen]

Thanks. Yes that is a good thing to let user chooses the options
they want to go.

Here is the build/run log for libusb-compat-0.1.4 release.

localhost$ ./configure --enable-examples-build
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i386-unknown-netbsdelf6.0.
checking host system type... i386-unknown-netbsdelf6.0.

checking how to print strings... print -r

checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes

checking for pkg-config... /usr/pkg/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBUSB_1_0... yes
configure: creating ./config.status
config.status: creating libusb.pc
config.status: creating libusb-config

config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating examples/Makefile

config.status: creating config.h

config.status: executing depfiles commands
config.status: executing libtool commands

config.status: executing default commands

localhost$ make
make all-recursive
Making all in libusb

/bin/ksh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I.. -fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef
-Wunused -Wstrict-prototypes -Werror-implicit-function-declaration
-Wno-pointer-sign -Wshadow -I/usr/pkg/include/libusb-1.0 -g -O2 -MT
libusb_la-core.lo -MD -MP -MF .deps/libusb_la-core.Tpo -c -o
libusb_la-core.lo `test -f 'core.c' || echo './'`core.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden
-std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow
-I/usr/pkg/include/libusb-1.0 -g -O2 -MT libusb_la-core.lo -MD -MP -MF
deps/libusb_la-core.Tpo -c core.c -fPIC -DPIC -o
libs/libusb_la-core.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden
-std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow
-I/usr/pkg/include/libusb-1.0 -g -O2 -MT libusb_la-core.lo -MD -MP -MF
deps/libusb_la-core.Tpo -c core.c -o libusb_la-core.o >/dev/null 2>&1
mv -f .deps/libusb_la-core.Tpo .deps/libusb_la-core.Plo
/bin/ksh ../libtool --tag=CC --mode=link gcc -fvisibility=hidden
-std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow
-I/usr/pkg/include/libusb-1.0 -g -O2 -version-info 8:4:4 -release
0.1 -o libusb.la -rpath /usr/local/lib libusb_la-core.lo
-L/usr/pkg/lib -lusb-1.0
libtool: link: warning: library `/usr/pkg/lib/libusb-1.0.la' was moved.
libtool: link: gcc -shared .libs/libusb_la-core.o -Wl,-rpath
-Wl,/usr/pkg/lib -Wl,-rpath -Wl,/usr/pkg/lib -L/usr/pkg/lib
/usr/pkg/lib/libusb-1.0.so -pthread -Wl,-soname -Wl,libusb-0.1.so.8
-o .libs/libusb-0.1.so.8.4
libtool: link: (cd ".libs" && rm -f "libusb-0.1.so.8" && ln -s
"libusb-0.1.so.8.4" "libusb-0.1.so.8")
libtool: link: (cd ".libs" && rm -f "libusb.so" && ln -s
"libusb-0.1.so.8.4" "libusb.so")
libtool: link: ar cru .libs/libusb.a libusb_la-core.o
libtool: link: ranlib .libs/libusb.a
libtool: link: ( cd ".libs" && rm -f "libusb.la" && ln -s
"../libusb.la" "libusb.la" )
Making all in examples
gcc -DHAVE_CONFIG_H -I. -I.. -I../libusb -std=gnu99 -fgnu89-inline
-Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -g
-O2 -MT lsusb.o -MD -MP -MF .deps/lsusb.Tpo -c -o lsusb.o lsusb.c
mv -f .deps/lsusb.Tpo .deps/lsusb.Po
/bin/ksh ../libtool --tag=CC --mode=link gcc -std=gnu99
-fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -g
-O2 -o lsusb lsusb.o ../libusb/libusb.la -lusb
libtool: link: warning: library `/usr/pkg/lib/libusb-1.0.la' was moved.
libtool: link: warning: library `/usr/pkg/lib/libusb-1.0.la' was moved.
libtool: link: gcc -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
-Wstrict-prototypes -Werror-implicit-function-declaration
-Wno-pointer-sign -Wshadow -g -O2 -o .libs/lsusb lsusb.o
-L/usr/pkg/lib ../libusb/.libs/libusb.so /usr/pkg/lib/libusb-1.0.so
-pthread -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib
gcc -DHAVE_CONFIG_H -I. -I.. -I../libusb -std=gnu99 -fgnu89-inline
-Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -g
-O2 -MT testlibusb.o -MD -MP -MF .deps/testlibusb.Tpo -c -o
testlibusb.o testlibusb.c
mv -f .deps/testlibusb.Tpo .deps/testlibusb.Po
/bin/ksh ../libtool --tag=CC --mode=link gcc -std=gnu99
-fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -g
-O2 -o testlibusb testlibusb.o ../libusb/libusb.la -lusb
libtool: link: warning: library `/usr/pkg/lib/libusb-1.0.la' was moved.
libtool: link: warning: library `/usr/pkg/lib/libusb-1.0.la' was moved.
libtool: link: gcc -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
-Wstrict-prototypes -Werror-implicit-function-declaration
-Wno-pointer-sign -Wshadow -g -O2 -o .libs/testlibusb testlibusb.o
-L/usr/pkg/lib ../libusb/.libs/libusb.so /usr/pkg/lib/libusb-1.0.so
-pthread -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib

localhost$ cd examples/

localhost$ ./lsusb
1366:0101

localhost$ ./testlibusb -v
Dev #2: SEGGER - J-Link
- Serial Number: xxxxxxxxxx
wTotalLength: 32
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: c0h
MaxPower: 50
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 255
bInterfaceSubClass: 255
bInterfaceProtocol: 255
iInterface: 0
bEndpointAddress: 81h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 02h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0

With libusb-1.0 in, I believe more packages can be ported
to NetBSD.

I am probably the first one to try out libusb-1.0 under
NetBSD and I hope more people here will try it out,
report success and failures and improve the current codes.

The initial commit to add NetBSD support is here.
http://git.libusb.org/?p=libusb.git;a=commit;h=de41604560a57b2279ac1d0a10b8192a9224d284;js=1


--
Xiaofan

[Xiaofan Chen]

On Thu, May 31, 2012 at 1:26 AM, Eric Haszlakiewicz <e...@nimenees.com> wrote:

> On Wed, May 30, 2012 at 04:45:13PM +0100, Stephen Borrill wrote:
>> On Wed, 30 May 2012, Xiaofan Chen wrote:
>> >libusb-1.0 under OpenBSD/NetBSD use ugen, so only
>> >ugen device are supported.
>>
>> One of the problems with libusb with NetBSD is that it cannot detach a
>> driver and reattach ugen. So if uhid has attached, you are stuck with it.
>
> I just ran into this problem myself.  I was thinking of adjusting the usb
> code so all devices can support the same ioctl's that ugen supports, but
> things got a bit trickier than I expected.

What if you limit your scope of work to generic HID device (non-mouse,
non-keyboard)? Does it make things easier?

The reason why generic HID device is popular is because Windows
come with in-box HID driver and native HID API is relatively easy
to use. libusb is usually used to communicate with this type of
device under Linux since the kernel HID driver can be detached.

> One of the problems is that not all usb devices have a device node in /dev,
> and there's no way to walk the device tree by (e.g.) operating on a hub
> device (/dev/usb0) so there doesn't seem to be a way to indicate that you
> want to do something with a particular usb device. :(

--
Xiaofan

[Xiaofan Chen]

On Thu, May 31, 2012 at 9:05 PM, Eric Haszlakiewicz <e...@nimenees.com> wrote:

> On Thu, May 31, 2012 at 07:48:00AM +0800, Xiaofan Chen wrote:
>> The other possibility is to learn from Mac OS X where
>> you can use a code-less kext to prevent the existing
>> kernel driver from attaching to a device (or a class
>> of device) based on certain criteria.
>

> I don't know what "code-less kext" is, but in NetBSD you can do this with
> a custom kernel configuration that has a nailed down ugen entry, e.g.:
>
> ugen3   at uhub? port ? vendor 0x06c2 product 0x0031 flags 1
>
> The vendor and product you can get using the
> USB_GET_DEVICE_DESC ioctl, which
> I recently copied over to uhid devices.

Thanks for the tip.

> Unfortunately userconf (boot -c) doesn't seem to be capable enough to
> do this so you actually need to build a new kernel for it.

Ah if that can be done without building a new kernel, that would be great.

A code-less kext is just an XML file which can prevents Apple Mac OS X
default driver to attach to the device, but rather use the generic iokit driver
(and as a result libusb can be used for USB device).
http://developer.apple.com/library/mac/#qa/qa1076/_index.html
http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEXTConcept/KEXTConceptAnatomy/kext_anatomy.html

An example to use ST ST-Link V1 (using USB mass storage driver by
default) with libusb so that people can use open-source libusb based
program like OpenOCD under Mac OS X.

https://github.com/texane/stlink/tree/master/stlinkv1_macosx_driver
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleIdentifier</key>
<string>com.libusb.stlink_shield</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0.0</string>
<key>IOKitPersonalities</key>
<dict>
<key>DeviceDriver</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.kpi.iokit</string>
<key>IOClass</key>
<string>IOService</string>
<key>IOProviderClass</key>
<string>IOUSBDevice</string>
<key>bcdDevice</key>
<integer>256</integer>
<key>idProduct</key>
<integer>14148</integer>
<key>idVendor</key>
<integer>1155</integer>
</dict>
<key>InterfaceDriver</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.kpi.iokit</string>
<key>IOClass</key>
<string>IOService</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>idProduct</key>
<integer>14148</integer>
<key>idVendor</key>
<integer>1155</integer>
</dict>
</dict>
<key>OSBundleLibraries</key>
<dict>
<key>com.apple.iokit.IOUSBFamily</key>
<string>1.8</string>
<key>com.apple.kpi.libkern</key>
<string>11.2.0</string>
</dict>
</dict>
</plist>


--
Xiaofan

[Thomas Mueller]

I noticed this thread shortly after noticing libusb-1.0 and libusbx in the pkgsrc updates.

Could the new-to-NetBSD libusb updates be of any use for USB 3.0 devices or for USB 2.0 printers?

Tom

[Thomas Mueller]

Xiaofan Chen <xiao...@gmail.com> responded:

> Does NetBSD supports USB 3.0 XHCI controller? If yes then
> libusb should work as well.

> I am not so sure if libusb is a good fit for USB printers. Take
> it is rather a low level library and mostly used for generic
> USB device.

Sort of wishful thinking on my port. There is no XHCI support in NetBSD,
and I saw a faint hope that the libubs update might provide this support.

Tom

[Xiaofan Chen]

On Mon, Nov 19, 2012 at 8:31 PM, Fredrik Pettai <pet...@nordu.net> wrote:
> OpenBSD added some patches after this conversation took place, maybe those are of interest:
> http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/libusb1/patches/

Some new development:

1. libusb and libusbx are going to merge
http://libusb.6.n5.nabble.com/libusb-and-libusbx-merging-td5712044.html

2. OpenBSD has some new changes which will not be compatible
with NetBSD.
http://libusbx.1081486.n5.nabble.com/Re-Libusbx-devel-mpi-openbsd-org-Re-libusb-Update-for-OpenBSD-s-backend-td1628.html

From the above thread, you can see that libusb/libusbx needs
a NetBSD contributor who can test the codes and who can
catch up at least some of the updates in libusb/libusbx.

Any one interested?

--
Xiaofan