I've got a USB missile launcher:
uhidev0 at uhub0 port 4 configuration 1 interface 0
uhidev0: vendor 0x1130 Tenx Nonstandard Devic, rev 1.10/1.00, addr 2, iclass 3/0
uhid0 at uhidev0: input=0, output=64, feature=8
uhidev1 at uhub0 port 4 configuration 1 interface 1
uhidev1: vendor 0x1130 Tenx Nonstandard Devic, rev 1.10/1.00, addr 2, iclass 3/0
uhid1 at uhidev1: input=0, output=8, feature=0
phone 1# usbhidctl -f uhid0 -a
No_Event=1 [0]
No_Event=1 [1]
No_Event=1 [2]
No_Event=1 [3]
No_Event=1 [4]
No_Event=1 [5]
No_Event=1 [6]
No_Event=1 [7]
usbhidctl: USB_GET_REPRT(output) [probably not supported by device]: Input/output error
phone 2# usbhidctl -f uhid0 -a
Report descriptor:
Feature size=8 count=8 Array page=Keyboard usage=No_Event0x00ff, logical
range 0255
size=8 count=64 Array page=Keyboard usage=No_Event0x00ff,
logical range 0255
Collection page=Generic_Desktop usage=Undefined
Total input size 0 bytes
Total output size 64 bytes
Total feature size 8 bytes
I thought I'd write a missile control library, so I looked for a python
driver:
and a Linux driver:
They both claim the device directly and try to detach the kernel uhid
driver before writing a very simple usb control message. This seems a lot
simpler than messing around with libusbhid, but I can't see how to achieve
it on NetBSD.
I've open()ed /dev/uhid0 and checked the Vendor and Product match, but if
I try to write() I get Invalid argument.

Wed, Feb 28, 2007 at 02:59:25PM +0000, Stephen Borrill wrote:
[]
They both claim the device directly and try to detach the kernel uhid
driver before writing a very simple usb control message. This seems a lot
simpler than messing around with libusbhid, but I can't see how to achieve
it on NetBSD.

Well you can always force ugen(4) to attach on it (using the locators in
your kernel configuration).

Wed, 28 Feb 2007, Quentin Garnier wrote:
Wed, Feb 28, 2007 at 02:59:25PM +0000, Stephen Borrill wrote:
[]
>They both claim the device directly and try to detach the kernel uhid
>driver before writing a very simple usb control message. This seems a lot
>simpler than messing around with libusbhid, but I can't see how to achieve
>it on NetBSD.
>
Well you can always force ugen(4) to attach on it (using the locators in
your kernel configuration).

Yes, I could, but as the python software works on FreeBSD (or at least
it's in their ports), I guess their usb stack must have the capability to
deal with:

self.handle = self.dev.open()
self.handle.detachKernelDriver(0)
self.handle.detachKernelDriver(1)
self.handle.setConfiguration(self.conf)
self.handle.claimInterface(self.intf)
self.handle.setAltInterface(self.intf)

followed by:
self.dev.handle.controlMsg(0x21, 0x09, self.INITA, 0x02, 0x01)
self.dev.handle.controlMsg(0x21, 0x09, self.INITB, 0x02, 0x01)
self.dev.handle.controlMsg(0x21, 0x09, direction+self.CMDFILL, 0x02, 0x01)

am I being stupid? :-)

There doesn't seem to be a lot of documentation about this and usbhid(4)
in particular says:

BUGS
This man page is woefully incomplete.

Wed, 28 Feb 2007, Reinoud Zandijk wrote:
Wed, Feb 28, 2007 at 02:59:25PM +0000, Stephen Borrill wrote:
>I've got a USB missile launcher:
>uhidev0 at uhub0 port 4 configuration 1 interface 0
>uhidev0: vendor 0x1130 Tenx Nonstandard Devic, rev 1.10/1.00, addr 2,
>iclass 3/0
>uhid0 at uhidev0: input=0, output=64, feature=8
>uhidev1 at uhub0 port 4 configuration 1 interface 1
>uhidev1: vendor 0x1130 Tenx Nonstandard Devic, rev 1.10/1.00, addr 2,
>iclass 3/0
>uhid1 at uhidev1: input=0, output=8, feature=0
>
>They both claim the device directly and try to detach the kernel uhid
>driver before writing a very simple usb control message. This seems a lot
>simpler than messing around with libusbhid, but I can't see how to achieve
>it on NetBSD.
>
Is it not a bug in the usbhid code then or is the device a non standard
USB?

I think it's just a difference between *BSD's API and the Linux one. In
pkgsrc/libusb, the function to detach is commented out if you are on *BSD:
int usb_detach_kernel_driver_np(usb_dev_handle *dev, int interface);

By disabling uhidev (so the missile launcher appears as ugen) and taking
the above into account, the Linux driver works. So I can shoot things from
NetBSD now, but it's not an ideal way of doing it (it really is a hid
device - it appears like that under Windows).

2/28/07, Stephen Borrill <netbsd (AT) precedence (DOT) co.ukwrote:
Wed, 28 Feb 2007, Reinoud Zandijk wrote:
Wed, Feb 28, 2007 at 02:59:25PM +0000, Stephen Borrill wrote:
>I've got a USB missile launcher:
>uhidev0 at uhub0 port 4 configuration 1 interface 0
>uhidev0: vendor 0x1130 Tenx Nonstandard Devic, rev 1.10/1.00, addr 2,
>iclass 3/0
>uhid0 at uhidev0: input=0, output=64, feature=8
>uhidev1 at uhub0 port 4 configuration 1 interface 1
>uhidev1: vendor 0x1130 Tenx Nonstandard Devic, rev 1.10/1.00, addr 2,
>iclass 3/0
>uhid1 at uhidev1: input=0, output=8, feature=0
>
>They both claim the device directly and try to detach the kernel uhid
>driver before writing a very simple usb control message. This seems a lot
>simpler than messing around with libusbhid, but I can't see how to achieve
>it on NetBSD.
>
Is it not a bug in the usbhid code then or is the device a non standard
USB?

I think it's just a difference between *BSD's API and the Linux one. In
pkgsrc/libusb, the function to detach is commented out if you are on *BSD:
int usb_detach_kernel_driver_np(usb_dev_handle *dev, int interface);

By disabling uhidev (so the missile launcher appears as ugen) and taking
the above into account, the Linux driver works. So I can shoot things from
NetBSD now, but it's not an ideal way of doing it (it really is a hid
device - it appears like that under Windows).

Wed, Feb 28, 2007 at 06:02:32PM +0000, Hubert Feyrer wrote:
Wed, 28 Feb 2007, Dunceor wrote:
>BSD imported support for it like 3 month's ago.
>
>
>vendor TENX 0x1130 Ten X Technology, Inc.
>
>/* Ten X Technology, Inc. */
> product TENX MISSILE 0x0202 Missile Launcher

I guess having this in usbdevs alone is not the point.
If there's more, I must have missed it in your mail.

the relevant change is:

iow, "Ten X Missile Launcher is not a HID device."

Wed, Feb 28, 2007 at 07:40:43PM +0100, Matthias Drochner wrote:
It claims to be one (albeit a pretty generic one according
to the descriptor dumps in Stephen's mail), and there is
no indication that there is some specific bug which suggests
not treat it as one.
I guess the BSD people just wanted to keep the uhid
driver out, to make the Linux stuff work out of the box.

i was merely describing what the BSD quirk stands for, sorry for the
confusion.

regards,

Wed, 28 Feb 2007, Matthias Drochner wrote:
salo (AT) Xtrmntr (DOT) org said:
>iow, "Ten X Missile Launcher is not a HID device."
>
It claims to be one (albeit a pretty generic one according
to the descriptor dumps in Stephen's mail), and there is
no indication that there is some specific bug which suggests
not treat it as one.

Agreed.

I guess the BSD people just wanted to keep the uhid
driver out, to make the Linux stuff work out of the box.

Agreed again, while this will work, it seems lazy. After all, it's HID
under Windows. TH, I like the flexibility of Linux's idea of telling
uhid to go away and leave us to talk directly. It gives more driver
compatibility and doesn't require kernel changes or quirks.

I'd assume that it would just work to send the 8/64 byte
datablocks defined in the Python script to the uhid device
through USB_SET_REPRT ioctls.

I think I'm missing something here. I've tried writing the data using
USB_SET_REPRT (both UHIDUTPUT_REPRT and UHID_FEATURE_REPRT) by
putting the data in ucr_data[], but it hangs for a while and then gives an
I/ error. Similarly, using hid_set_data() gives similar results.