Re: py-usb problems
Dave Tyson wrote: > Just putting a statement: > > ugen* at uhub? port ? vendor 0x product 0x flags 1 > > wasn't sufficient, I also needed to comment out the > > #uhidev* at uhub? port ? configuration ? interface ? > > and the uhidev child devices otherwise it just appeared as a child > of uhidev as before: > > uhidev0 at uhub0 port 2 configuration 1 interface 0 > uhidev0: LA CROSSE TECHNOLOGY Weather Direct Light Wireless Device, rev That's strange, it shouldn't do that. Are you sure you booted the correct kernel? What does "config -x | grep ugen" say when booted with the kernel in case? -- Andreas Gustafsson, g...@gson.org
Re: py-usb problems
On 02/19/15 07:49, Andreas Gustafsson wrote: Dave Tyson wrote: Not sure whether this belongs here or in pkgsrc-users. I have been trying to package the weewx weather station software which is written in python. It uses py-usb to handle the devices, but I cannot get it to see anything on the usb busses. What does the device show up as in the output from "dmesg"? If it attaches with a driver other than "ugen" (for example, "uhid"), that's your problem - py-usb relies on libusb which only works with the ugen driver. On Linux, libusb has the capability to automatically unload other drivers, but NetBSD lacks this functionality. You can force the device to attach as ugen by adding a line like the following to your kernel configuration and building a new kernel: ugen* at uhub? vendor 0x product 0x flags 1 replacing 0x and 0x with the hexadecimal USB vendor and product IDs of the device. You can find the IDs by running usbdevs. Just putting a statement: ugen* at uhub? port ? vendor 0x product 0x flags 1 wasn't sufficient, I also needed to comment out the #uhidev* at uhub? port ? configuration ? interface ? and the uhidev child devices otherwise it just appeared as a child of uhidev as before: uhidev0 at uhub0 port 2 configuration 1 interface 0 uhidev0: LA CROSSE TECHNOLOGY Weather Direct Light Wireless Device, rev 2.00/1.00, addr 2, iclass 3/0 uhidev0: 223 report ids uhid0 at uhidev0 reportid 1: input=14, output=0, feature=0 uhid1 at uhidev0 reportid 16: input=0, output=1, feature=0 uhid2 at uhidev0 reportid 17: input=0, output=0, feature=1 uhid3 at uhidev0 reportid 32: input=0, output=0, feature=21 uhid4 at uhidev0 reportid 33: input=0, output=0, feature=1 ... After commenting out uhidev, the device did attach as a ugen and it was visible to py-usb. ugen0 at uhub0 port 2 ugen0: LA CROSSE TECHNOLOGY Weather Direct Light Wireless Device, rev 2.00/1.00, addr 2 The weewx software seems to work OK so I will try and finish packaging it. Commenting out uhidev is not practical as I lose the usb keyboard etc. I guess this needs usb quirk - but therein lies a problem. The manufacturers of the usb radio stick used the generic vendor/product codes for development/testing (0x/0x) and so just using those risks a clash with other devices produced by similar clueless manufacturers. Any suggestions on how to work around this? Thanks for the help! Cheers, Dave -- Phone: 07805784357 Open Source O/S: www.netbsd.org Caving: http://www.wirralcavinggroup.org.uk
Re: py-usb problems
Dave Tyson wrote: > Not sure whether this belongs here or in pkgsrc-users. I have been > trying to package the weewx weather station software which is > written in python. It uses py-usb to handle the devices, but > I cannot get it to see anything on the usb busses. What does the device show up as in the output from "dmesg"? If it attaches with a driver other than "ugen" (for example, "uhid"), that's your problem - py-usb relies on libusb which only works with the ugen driver. On Linux, libusb has the capability to automatically unload other drivers, but NetBSD lacks this functionality. You can force the device to attach as ugen by adding a line like the following to your kernel configuration and building a new kernel: ugen* at uhub? vendor 0x product 0x flags 1 replacing 0x and 0x with the hexadecimal USB vendor and product IDs of the device. You can find the IDs by running usbdevs. -- Andreas Gustafsson, g...@gson.org
Re: py-usb problems
I never could get any of the various open source weather programs working with my Oregon Scientific WMR200A. They never could find the station console on the USB. If I remember correctly the problem was that it gets claimed by the driver that handles Human Interface Devices so it shows up as a UHID device, not a UGEN or USB device. It looks like your station is doing the same thing. I eventually gave up on the open source solution and wrote my own program to capture the data. It wasn't easy since Oregon Scientific doesn't provide documentation on their protocol and it had to be reverse engineered. It's still a work in progress but it has been running for a couple of years on my NetBSD system. If anyone wants a copy of the code I can make it available.
Re: py-usb problems
In Message <54e5210d.6030...@anduin.org.uk>, Dave Tyson wrote: =>On 02/18/15 19:05, Jonathan A. Kollasch wrote: =>> On Wed, Feb 18, 2015 at 05:58:22PM +, Dave Tyson wrote: =>>> recent pkgsrc. /dev/usb* is readable/writeable by all =>> What about /dev/ugen*.*? Any ugen devices in dmesg? => =>Forgot to add that /dev/uhid0-/dev/uhid18 as also =>read-write all. ktrace showed that ioctl(,USB_DEVICEINFO,) is returning devices, but a debug vesion of PyUSB shows that the usb_device::devices pointer is coming back null, which points to a libusb problem. A debug version of libusb shows that bsd.c:usb_os_find_devices() is skipping anything that isn't ugen, so any USB devices you have drivers for won't show up. Not terribly helpful, but there it is. Gary Duzan
Re: py-usb problems
On 02/18/15 19:05, Jonathan A. Kollasch wrote: On Wed, Feb 18, 2015 at 05:58:22PM +, Dave Tyson wrote: recent pkgsrc. /dev/usb* is readable/writeable by all What about /dev/ugen*.*? Any ugen devices in dmesg? Forgot to add that /dev/uhid0-/dev/uhid18 as also read-write all. Dave -- Phone: 07805784357 Open Source O/S: www.netbsd.org Caving: http://www.wirralcavinggroup.org.uk
Re: py-usb problems
On 02/18/15 19:05, Jonathan A. Kollasch wrote: On Wed, Feb 18, 2015 at 05:58:22PM +, Dave Tyson wrote: recent pkgsrc. /dev/usb* is readable/writeable by all What about /dev/ugen*.*? Any ugen devices in dmesg? Hi Jonathan, /dev/ugen0.00 - /dev/ugen3.15 are all read/write to all. e.g: crw-rw-rw- 1 root wheel 64, 0 Feb 8 07:37 /dev/ugen0.00 dmesg shows: uhidev0 at uhub0 port 2 configuration 1 interface 0 uhidev0: LA CROSSE TECHNOLOGY Weather Direct Light Wireless Device, rev 2.00/1.00, addr 2, iclass 3/0 uhidev0: 223 report ids uhid0 at uhidev0 reportid 1: input=14, output=0, feature=0 uhid1 at uhidev0 reportid 16: input=0, output=1, feature=0 uhid2 at uhidev0 reportid 17: input=0, output=0, feature=1 uhid3 at uhidev0 reportid 32: input=0, output=0, feature=21 uhid4 at uhidev0 reportid 33: input=0, output=0, feature=1 uhid5 at uhidev0 reportid 54: input=0, output=0, feature=14 uhid6 at uhidev0 reportid 208: input=0, output=0, feature=20 uhid7 at uhidev0 reportid 209: input=0, output=0, feature=20 uhid8 at uhidev0 reportid 213: input=0, output=0, feature=272 uhid9 at uhidev0 reportid 214: input=0, output=0, feature=272 uhid10 at uhidev0 reportid 215: input=0, output=0, feature=20 uhid11 at uhidev0 reportid 216: input=0, output=0, feature=20 uhid12 at uhidev0 reportid 217: input=0, output=0, feature=14 uhid13 at uhidev0 reportid 218: input=0, output=0, feature=14 uhid14 at uhidev0 reportid 219: input=0, output=0, feature=20 uhid15 at uhidev0 reportid 220: input=0, output=0, feature=20 uhid16 at uhidev0 reportid 221: input=0, output=0, feature=14 uhid17 at uhidev0 reportid 222: input=0, output=0, feature=5 uhid18 at uhidev0 reportid 223: input=0, output=0, feature=20 Dave -- Phone: 07805784357 Open Source O/S: www.netbsd.org Caving: http://www.wirralcavinggroup.org.uk
Re: py-usb problems
On Wed, Feb 18, 2015 at 05:58:22PM +, Dave Tyson wrote: > recent pkgsrc. /dev/usb* is readable/writeable by all What about /dev/ugen*.*? Any ugen devices in dmesg?
py-usb problems
Not sure whether this belongs here or in pkgsrc-users. I have been trying to package the weewx weather station software which is written in python. It uses py-usb to handle the devices, but I cannot get it to see anything on the usb busses. I don't know python, but the simple program below shows the problem: $cat a.py #!/usr/pkg/bin/python2.7 import usb busses = usb.busses() for bus in busses: print "Bus:", bus.dirname devices = bus.devices for dev in devices: print "Device:", dev.filename print " idVendor: %d (0x%04x)" % (dev.idVendor, dev.idVendor) print " idProduct: %d (0x%04x)" % (dev.idProduct, dev.idProduct) $./a.py Bus: /dev/usb0 Bus: /dev/usb1 Bus: /dev/usb2 Bus: /dev/usb3 Bus: /dev/usb4 Bus: /dev/usb5 Five busses, but no devices! Yet they are there: $usbdevs addr 1: OHCI root hub, vendor 0x1002 addr 2: Weather Direct Light Wireless Device, LA CROSSE TECHNOLOGY addr 3: product 0x0103, vendor 0x04f3 addr 4: product 0x0083, Belkin Components addr 1: EHCI root hub, vendor 0x1002 addr 1: OHCI root hub, vendor 0x1002 addr 1: EHCI root hub, vendor 0x1002 addr 1: OHCI root hub, vendor 0x1002 addr 1: EHCI root hub, vendor 0x1002 Any clues. This is a recent NetBSD 7_BETA on amd64 and very recent pkgsrc. /dev/usb* is readable/writeable by all Cheers, Dave -- Phone: 07805784357 Open Source O/S: www.netbsd.org Caving: http://www.wirralcavinggroup.org.uk
