Re: ip_reass() - possibly incorrect goto
On Thu, 24 Mar 2005, 04:46-0600, Mike Silbersack wrote: On Wed, 23 Mar 2005, Maxim Konovalov wrote: On Tue, 22 Mar 2005, 12:08-0800, [EMAIL PROTECTED] wrote: Hi hackers, I am looking at the ip_reass() routine. In case of the 1st fragment we create the reassembly queue. After the queue has been inserted in the hash bucket, the if () code does a goto inserted. Should this be changed to goto done instead? Any code that is executed for the 1st fragment, like frag per packet limiting and complete reassembly are not valid. Am I mistaken? Yep, it seems you are right. The second micro optimization - drop the fragment early if maxfragsperpacket == 0. Andre, Mike, what do you think? Looks good to me. Please tell us if you come up with any more optimizations for the reassembly code, Vijay. [...] Committed to HEAD. Thanks, Vijay! -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Tricky USB device.
I've got an OnTrak ADU208. It's a USB device that has 8 relays and 8 ttl inputs. The documentation says it uses two interupt endpoints ... one input and one output. It seems to expect small text commands. Now... firstly, uhid is probing it as uhid0: uhid0: www.ontrak.net ADU208 USB Relay I/O Interface, rev 1.10/0.00, addr 4, iclass 3/0 ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, I've got an OnTrak ADU208. It's a USB device that has 8 relays and 8 ttl inputs. The documentation says it uses two interupt endpoints ... one input and one output. It seems to expect small text commands. ok Now... firstly, uhid is probing it as uhid0: uhid0: www.ontrak.net ADU208 USB Relay I/O Interface, rev 1.10/0.00, addr 4, iclass 3/0 ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. how about getting usb hid descriptor, parsing and dumping it? check out libusbhid - man usbhid(3). it might be that all you need to do is to create hid report and send it to the device. libusbhid(3) will help you with that. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... well comment out 'device uhid' from your kernel config and rebuilding the kernel should do the trick. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. fine, so i presume usbhidctl(1) does not work on the device too. why did they made look like usb hid device then? I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. well, for what i know ugen(4) will only claim the device if no other usb device driver claimed it. so if the uhid(4) claimed it than (i assume) usb interface class on the device is set to the appropriate value. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). another way is to hack /sys/dev/usd/uhid.c and specifically ignore (usb vendor id, usb product id) for the device in the MATCH routine. something like if (uaa-vendor == uaa-product == ) return (UMATCH_NONE); max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: Maksim David, ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. Maksim fine, so i presume usbhidctl(1) does not work on the device Maksim too. why did they made look like usb hid device then? Yeah... it appears to fail. I have no idea, but the guy at the company seemed to imply that he was just using a standard chip to drive the USB logic, so it may be a function of that. Maksim another way is to hack /sys/dev/usd/uhid.c and specifically Maksim ignore (usb vendor id, usb product id) for the device in the Maksim MATCH routine. something like Maksim if (uaa-vendor == uaa-product == ) return Maksim (UMATCH_NONE); Hrm. I thought that there might be some general bogon list, but that will certainly do. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 12:56:16PM -0400, David Gilbert wrote: Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. Then it really shouldn't have claimed to be one in the interface descriptor :( But the HID specification is more today than just _human_ interface. e.g. there are extensions for USV, ... I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). Has this device multiple interfaces? e.g. one HID and another as described. I often thought about getting ugen working at interface level too. -- B.Walter BWCThttp://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]
Call for FreeBSD status reports
All, It's time again for some recapitulation of your FreeBSD activities of the last months. In order to not collided with the preparation of the 5.4 release we extended the cycle from bi-monthly to three months, so this one is open for anything that happend in 2005 until now. Submissions are due by April 15 to [EMAIL PROTECTED] As always, reports about every FreeBSD related activity of the past months and coming weeks are welcome. In the past there was some focus on technical issues. In order to turn this into a more complete PR-vehicle, we highly encourage and welcome reports on non-technical matters as well. If you are yet unfamiliar with the status-reports, please take a look at the past reports: http://www.FreeBSD.org/news/status/ To support you in the process of fitting your report into the xml-template (available from: http://www.freebsd.org/news/status/report-sample.xml for those who still prefer a plain old text editor) Julian Elischer came up with the idea and prototype to have a web based form. Many thanks for that work. The cgi-script is being reviewed on freebsd-www now and will be linked to from http://www.freebsd.org/news/status/ shortly. The new features from last time (categories and task-list) will be available, again. As a reminder the available categories are listed bellow. Please feel free to suggest additional entries: proj - Projects (non-specific) docs - Documentation kern - Kernel arch - Architectures ports - Ports vendor - Vendor / 3rd party software misc - Miscellaneous Submissions are due on April 15. Thanks a lot, and we are hoping for a big turn-out. -- Max pgpliqjbmw6mo.pgp Description: PGP signature
Re: Tricky USB device.
Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Then it really shouldn't have claimed to be one in the Bernd interface descriptor :( But the HID specification is more today Bernd than just _human_ interface. e.g. there are extensions for Bernd USV, ... [...] 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. 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. ... 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: bLength18 bDescriptorType01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 8 idVendor 0a07 idProduct 00d0 bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength41 bNumInterface 1 bConfigurationValue 1 iConfiguration 4 bmAttributesa0 (remote-wakeup) bMaxPower 100 (200 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass03 bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 5 HID Descriptor: bLength 9 bDescriptorType 21 bcdHID0100 bCountryCode 00 bNumDescriptors 1 bDescriptorType 22 wDescriptorLength 102 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 01 (out) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): www.ontrak.net String (index 2): ADU208 USB Relay I/O Interface String (index 3): C02053 String (index 4): Cfg1 String (index 5): EP10In ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, Bernd Then it really shouldn't have claimed to be one in the Bernd interface descriptor :( But the HID specification is more today Bernd than just _human_ interface. e.g. there are extensions for Bernd USV, ... [...] 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. hmm... why even use libusb? cant you just fd = open(/dev/ugen0.1, O_RDWR); and then write(fd, MK255, 5) and read(fd, ...);. note: here i assume ugen0 is the device. 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. i'd guess you have to keep read pipe open at all times. that is what fd = open(/dev/ugen0.1, O_RDWR); will do - it will open both read and write pipes (because of O_RDWR). then you just write(fd, ...); read(fd, ...); max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 03:32:56PM -0700, Maksim Yevmenkin wrote: hmm... why even use libusb? cant you just fd = open(/dev/ugen0.1, O_RDWR); and then write(fd, MK255, 5) and read(fd, ...);. note: here i assume ugen0 is the device. 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. i'd guess you have to keep read pipe open at all times. that is what fd = open(/dev/ugen0.1, O_RDWR); will do - it will open both read and write pipes (because of O_RDWR). then you just write(fd, ...); read(fd, ...); select(2) and non-blocking should work with ugen and interrupt endpoints too. -- B.Walter BWCThttp://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]
Re: Tricky USB device.
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: bLength18 bDescriptorType01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 8 idVendor 0a07 idProduct 00d0 bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength41 bNumInterface 1 bConfigurationValue 1 iConfiguration 4 bmAttributesa0 (remote-wakeup) bMaxPower 100 (200 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass03 bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 5 HID Descriptor: bLength 9 bDescriptorType 21 bcdHID0100 bCountryCode 00 bNumDescriptors 1 bDescriptorType 22 wDescriptorLength 102 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 01 (out) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 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 BWCThttp://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]
Re: Tricky USB device.
Bernd Walter wrote: 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. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 04:47:43PM -0700, Maksim Yevmenkin wrote: Bernd Walter wrote: 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. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. It is a bit more complicated. For control endpoints packets transfers that are bigger than one packet can be transfered using multiple packets using a shortened last packet, which can be even of 0 length if the transfer exactly fits in packets. For bulk endpoints things can be handled specific to the protocol requirements - e.g. most serials don't track transfer borders. We have interrupt endpoints - you are right smaller than max packets are allowed - just checked the specs. The remaining is the same as for bulk endpoints, but interrupt endpoint are different in bus time calculations. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. As corrected above - you are really allowed to have smaller packets. But you can't have larger ones - however you can transfer multiple packets in one transaction, but this is not optimal speedwise as interrupt endpoints are laid out in a specific timeline. bInterval=1 means one packet per 1ms will be transfered and not more. Doing a transfer with e.g. 2 packets will take 1ms longer - even if the bus is idle in the meantime. This is because interrupt endpoints get garantied bus time. -- B.Walter BWCThttp://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]
Re: Tricky USB device.
Maksim Yevmenkin wrote: Bernd Walter wrote: 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. the device may accept 5 bytes of data. if it's feeling charitable. but you probably should send teh number of bytes suggested by the endpoint descriptor. that number is at least guaranteed to work. Hang on.. I'm trying to remember if the 8 includes the header.. if so then you probably only get 5 bytes of data space.. I need to go back to my USB book. From what I saw before, you may need to set the configuration number to 1 before it will do anything. so you may need to do a setConfiguration(1) then you should be able to read on the descriptor for endpoint 81. it should block until there is some activity to report on the switch. I'm guessing writing all 1s to endpoint 1 sets some leds or something. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. yes bMaxPacketSize is the maximum single packet that the endpoint will handle, however many such transactions can be used to make up a USB request fronm the user.. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 06:06:30PM -0700, Julian Elischer wrote: Maksim Yevmenkin wrote: Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: 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. the device may accept 5 bytes of data. if it's feeling charitable. but you probably should send teh number of bytes suggested by the endpoint descriptor. that number is at least guaranteed to work. Hang on.. I'm trying to remember if the 8 includes the header.. The size is just the payload - I was just wrong, as interrupts transfers are allowed to be smaller. However the device should make use of 8 Byte packets or not say 8 Bytes at all. if so then you probably only get 5 bytes of data space.. I need to go back to my USB book. From what I saw before, you may need to set the configuration number to 1 before it will do anything. so you may need to do a setConfiguration(1) ugen will have done that already, otherwise it wouldn't know about the devnodes for the interrupt endpoints in the first configuration. -- B.Walter BWCThttp://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]
