On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: > Bernd> Has this device multiple interfaces? e.g. one HID and another > Bernd> as described. I often thought about getting ugen working at > Bernd> interface level too. > > Here's the output of udesc_dump on it. Right now, using the current > version of libusb (not the version from ports), I can use > usb_interrupt_write(dev, 1, "MK255", 5, 0) to send data to it --- and > the data is sent --- at least lights on the USB hub flash. If I > replace '1' with anything else, it doesn't accept it. However, it > doesn't seem to have opened the relays.
Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. Btw: you shouldn't use 0 as timeout value - this is OK under FreeBSD for having no timeout, but Linux understands it as 0 seconds and things fail. Having a timeout isn't bad anyway - you can still restart the transfer if you want. If portability is not an issue you should take Maksim's advice and directly use ugen* access. > I'm also not entirely clear how/when to use usb_interrupt_read() > ... as many of the commands listed in the manual return data, but > usb_inerrupt_write() doesn't seem to allow for data to be returned, > but following usb_interrupt_write(), the read will hang. Depends on the device's firmware. I wouldn't be surprised if the whole device just hangs after receiving bogus data - it seems to be broken in many points. But it may block if the device has nothing to send. An easy way to check out is using tools like usbdevs -v and see if it hangs when accessing this device. > ... so I'm somewhat at a loss, but I also can't find my multitester > ... and will be fetching another one tonight. > > I'd appreciate any random knowledge anyone can summon on this topic. > > Standard Device Descriptor: > bLength 18 > bDescriptorType 01 > bcdUSB 0110 > bDeviceClass 00 > bDeviceSubClass 00 > bDeviceProtocol 00 > bMaxPacketSize 8 > idVendor 0a07 > idProduct 00d0 > bcdDevice 0000 > iManufacturer 1 > iProduct 2 > iSerialNumber 3 > bNumConfigurations 1 > > Configuration 0: > Standard Configuration Descriptor: > bLength 9 > bDescriptorType 02 > wTotalLength 41 > bNumInterface 1 > bConfigurationValue 1 > iConfiguration 4 > bmAttributes a0 (remote-wakeup) > bMaxPower 100 (200 mA) > > Standard Interface Descriptor: > bLength 9 > bDescriptorType 04 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 03 > bInterfaceSubClass 00 > bInterfaceProtocol 00 > iInterface 5 > > HID Descriptor: > bLength 9 > bDescriptorType 21 > bcdHID 0100 > bCountryCode 00 > bNumDescriptors 1 > bDescriptorType 22 > wDescriptorLength 102 > > > Standard Endpoint Descriptor: > bLength 7 > bDescriptorType 05 > bEndpointAddress 81 (in) > bmAttributes 03 (Interrupt) > wMaxPacketSize 8 > bInterval 10 > > Standard Endpoint Descriptor: > bLength 7 > bDescriptorType 05 > bEndpointAddress 01 (out) > bmAttributes 03 (Interrupt) > wMaxPacketSize 8 > bInterval 10 OK - exactly one interface, which claims to be HID. I'm not familar with HID to say if it really is HID compatible. I personally would say that they took some sample code and just hacked it without really knowing what they do. -- B.Walter BWCT http://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
