> We were curious if it would work under NetBSD, so we plugged it into
> my laptop which is running 1.4.1.  It turns out this behaves a bit odd ...
> it doesn't show up as a USB device until you hit the "sync" button
> on the cradle.

That probably means that the device is not powered up until you hit the
sync button.


> I knew that the Visor worked fine with the pilot-link tools with the serial
> cradle, so I theorized that the protocol was just the same, just being
> run over USB.  So I hacked on pilot-xfer a small bit to remove the calls
> to set the termios parameters and tried pointing pilot-xfer at
> /dev/ugen0.00

This will never work.  You can only do ioctl() on the control device.


> (BTW, maybe this is a USB thing .... but I don't understand
> why there are 16 devices for each ugen device .... I guess it's one
> device per endpoint?

Yes, one device per endpoint.


>  How are endpoints assigned?).

Endpoints are assigned by the manufacturer of the device.  Have you
read ugen(4)?
If you want to know what endpoints your device has
you should run the usbctl program from the usbutil package.



> Anyway, once I did that, I got a whole lot of messages of the form:
>
> ugenread: no edesc
> ugenwrite: no edesc

This is a kernel bug, you should never get these messages.  You should not
have been able to get that far in the code.  Are you not running -current?
I thought I fixed this bug about a month ago.


> - Am I doing things wrong from a programming standpoint?  Probably,
>   but what else do I need to do?

Yes, you are.  You cannot read()/write() on the control endpoint.  To know
what to do you really need to get the protocol spec from the manufacturer
(good luck!).  Or make some very educated guesses.  If dare a guess I'd
say that the device probably has two bulk endpoints, one for each data
direction.


> - How come you can't open devices with O_RDWR?

This is also something that should work in -current.


--

        -- Lennart