On Tue, 15 Feb 2005, Martin Blatter wrote: > I'm currently writing a driver for the Philips eHome Infrared Transciever > based on the existing lirc_atiusb driver. Judging from USB Snoopy's > output on Windows XP, the windows driver gets two endpoints > with interrupt-style pipes after enumeration. > > Strangely enough when trying to recreate the exat same thing on Linux > (2.6.8-24.11-default i686 SuSE) I only get two bulk-type pipes and > no interrupt-type pipes although configuration, interface and altSetting > seem to be identical. > > Here's the output from USB Snoopy followed by the code snippet.
> [20 ms] >>> URB 3 going down >>> > -- URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE: > TransferBufferLength = 00000020 > TransferBuffer = 863477f8 > TransferBufferMDL = 00000000 > Index = 00000000 > DescriptorType = 00000002 (USB_CONFIGURATION_DESCRIPTOR_TYPE) > LanguageId = 00000000 > [25 ms] UsbSnoop - MyInternalIOCTLCompletion(f7befdb0) : > fido=00000000, Irp=8628faf8, Context=862432c0, IRQL=2 > [25 ms] <<< URB 3 coming back <<< > -- URB_FUNCTION_CONTROL_TRANSFER: > PipeHandle = 862690d0 > TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, > USBD_SHORT_TRANSFER_OK) > TransferBufferLength = 00000020 > TransferBuffer = 863477f8 > TransferBufferMDL = 861e66d0 > 00000000: 09 02 20 00 01 01 00 a0 32 09 04 00 00 02 ff ff > 00000010: ff 00 07 05 01 02 10 00 00 07 05 81 02 10 00 00 > UrbLink = 00000000 > SetupPacket = > 00000000: 80 06 00 02 00 00 20 00 > Am I right in the assumption that everything up to here is part of the > enumeration > process? Yes. > Is Linux doing something differently here that may cause the problem? No. > Here's what I do after enumration (almost verbatim from the atiusb driver): <...> > And here's the debug output after plugging in the device: > > Feb 15 00:00:15 hanf kernel: usb 3-2: new full speed USB device using address > 3 > Feb 15 00:00:15 hanf kernel: usb 3-2: Product: eHome Infrared Transceiver > Feb 15 00:00:15 hanf kernel: usb 3-2: Manufacturer: Philips > Feb 15 00:00:15 hanf kernel: usb 3-2: SerialNumber: PH001j68 > Feb 15 00:00:21 hanf kernel: module lirc_philipsusb unsupported by > SUSE/Novell, tainting kernel. > Feb 15 00:00:21 hanf kernel: > Feb 15 00:00:21 hanf kernel: lirc_philipsusb: USB remote driver for LIRC v0.1 > Feb 15 00:00:21 hanf kernel: lirc_philipsusb: Martin Blatter <[EMAIL > PROTECTED]> > Feb 15 00:00:21 hanf kernel: lirc_philipsusb: debug mode enabled > Feb 15 00:00:21 hanf kernel: lirc_philipsusb: usb probe called > Feb 15 00:00:21 hanf kernel: lirc_philipsusb: current configuration 1, > current interface 0, num endpoints 2 > Feb 15 00:00:21 hanf kernel: endpoint: length 0x7 descriptortype - 0x5 > endpointaddress - 0x1 attributes 0x2 - packetsize 0x10 - interval 0x0 > Feb 15 00:00:21 hanf kernel: endpoint: length 0x7 descriptortype - 0x5 > endpointaddress - 0x81 attributes 0x2 - packetsize 0x10 - interval 0x0 > Feb 15 00:00:21 hanf kernel: lirc_philipsusb: no acceptable endpoint found > Feb 15 00:00:21 hanf kernel: usbcore: registered new driver lirc_philipsusb > > In another desperate attempt, I tried to send the three > USB_REQ_GET_DESCRIPTOR control > messages that appear in the USB Snoopy log. To no avail. They went > through fine but > still no interrupt pipes, just bulk. > > What am I doing wrong? You're not doing anything wrong. The question is, what is USB Snoopy doing wrong? If you decode the TransferBuffer contents for URB 3 coming back, you can easily see that both endpoints are listed with bmAttributes = 0x02 = Bulk. Not 0x03 = Interrupt. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
