From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 8 23:34:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ABE416A4CE for ; Fri, 8 Apr 2005 23:34:14 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 502FD43D45 for ; Fri, 8 Apr 2005 23:34:13 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j38NY7np016599 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 9 Apr 2005 01:34:10 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j38NX3hs084033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2005 01:33:03 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j38NX2E5006812; Sat, 9 Apr 2005 01:33:03 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j38NX2AO006811; Sat, 9 Apr 2005 01:33:02 +0200 (CEST) (envelope-from ticso) Date: Sat, 9 Apr 2005 01:33:02 +0200 From: Bernd Walter To: David Gilbert Message-ID: <20050408233301.GW96690@cicely12.cicely.de> References: <16982.46075.115518.130213@canoe.dclg.ca> <4256B5EB.9080506@savvis.net> <16982.47024.135663.645297@canoe.dclg.ca> <20050408190514.GS96690@cicely12.cicely.de> <16983.465.572693.73195@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16983.465.572693.73195@canoe.dclg.ca> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: Tricky USB device. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2005 23:34:14 -0000 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 bernd@bwct.de info@bwct.de