Hi, On 26/07/06, Alex Villacís Lasso <[EMAIL PROTECTED]> wrote: > Alex Villacís Lasso wrote: > > Recently I bought an IrDA USB dongle with Windows-only drivers. When I > > plugged > > it in in Fedora 4, lsusb reported the following: > > > > Bus 001 Device 005: ID 07c0:4200 Code Mercenaries Hard- und Software GmbH > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 1.10 > > bDeviceClass 0 (Defined at Interface level) > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 8 > > idVendor 0x07c0 Code Mercenaries Hard- und Software GmbH > > idProduct 0x4200 > > bcdDevice 0.00 > > iManufacturer 1 KingSun Co,Ltd
I have two dongles made by KingSun CO., but the vendor id for them is 0x07d0 and not 0x07c0. Nevertheless I suspect the protocol will be very similar. I am also intending to make drivers for them, but I didn't manage to do it yet. The IDs for them are: 07d0:4100 07d0:4959 They are slightly different because the first one has two endpoints, like yours, and the latter only one endpoint. The first in turn reports itself as USB-to-serial, while the second is USB-to-IrDA like yours, though I think the drivers for both of them will be rather serial drivers than IrDA drivers (as in drivers/net/irda/) because it seems none of the dongles does the irda frame parsing automatically and we will have to use something like IrTTY on top of them (although they can do FIR, not only SIR). Here's what I have found out about the protocol so far: I have tried the pl2303/ma600/ma620/es620 drivers with both dongles but the protocol is not at all the same and they won't work with these drivers. However the interface used by the cypress M8 cables is quite similar (which is a USB-to-serial device) and the cypress_m8 driver can be partially reused. The initialisation of the dongle is the same (sorry if the terms for USB protocol that I use are not correct, I haven't had time to read the USB specs yet): First a "control message" with "request" number 0x09 is sent with 8 bytes of data where the first 4 bytes contain the desired baudrate, the value in the fifth byte describes the flow control settings (parity, stop bits, data bits) and the three remaining bytes can be zero but for the 07d0:4959 they apparently don't have to be always zero and I don't know what information they carry. You can copy this piece of code from the cypress_m8.c driver. Then a dummy 0 byte write is needed, again like in cypress_m8.c. What happens later is different for the two dongles. With the first dongle (07d0:4100) you can then use just "interrupt reads" and you will get just the plain data received by the dongle, and this works. I don't yet know how to emit any infra-red signals because plain "interrupt write" won't work. For the 07d0:4959 device I haven't figured out neither reception nor emission, yet, but I'm more positive about it because I have a working Ms-Windows driver for this dongle, while for the 07d0:4100 device I haven't found *any* working driver for *any* operating system. My plan is to run this Ms-Windows driver inside the QEMU emulator and make it talk to the dongle, then capture the data that is being transmitted between the driver and the device using the QEMU usb debugging output and start writing a Linux driver from there. I have already done some tests but I was using a real PC with Ms-Windows and the SnoopyPro program that is supposed to capture data transmitted to/from USB devices. These are my observations from this experiment: the initialisation was identical to that from cypress_m8 but then only the "control messages" were being used, with "request" numbers 0x01 and 0x09 (#defined in cypress_m8.c as REQ_GET_REPORT and REQ_SET_REPORT) for emision and for reception of data from the dongle. The driver used poll-waiting on the device, issuing the same USB request every 8 or so milliseconds even when completely idle -- I hope we don't have to reproduce this behavior in the Linux driver. For the simplicity of it, I wanted to first make a userspace program using libusb that would just read and write some infra-red data through the dongles, and only when this is working, convert it into a real driver. A simple libusb program compiles in a fraction of a second and can be tested inmediately and if you make a mistake you will get a simple segfault instead of an Oops and you don't have to reboot then. My little program can currently only receive the data from the 07d0:4100 device but not send anything. > > iProduct 2 USB to Irda > > iSerial 0 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 41 > > bNumInterfaces 1 > > bConfigurationValue 1 > > iConfiguration 4 Usb to Irda > > bmAttributes 0x80 > > MaxPower 100mA > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 2 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 85 > > bInterfaceProtocol 0 > > iInterface 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0008 1x 8 bytes > > bInterval 1 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x02 EP 2 OUT > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0008 1x 8 bytes > > bInterval 1 > > > > > Googling around, I found the following post, that suggests that the > pl2303 driver might be more appropriate than irda-usb for this dongle: > > > I came across the text below, telling about the MA620 dongle, which > > seems to > > be quite related to the problem I have with the ES620 USB-IrDA dongle. I > > don't know whether it holds or not. > > I'm including the USB information from the dongle and hope you can > > help me > > out. I've found some clues saying that I should rebuild the PL2303 > > (kernel)module as a separate one, but I'm too unfamiliar with that > > kind of > > stuff to do it myself. > > > > I've tried to solve the problem using specific vendor-id and > > product-id with > > usbserial, but that will complain: > > kernel: usb 1-2.2: new low speed USB device using ohci_hcd and > > address 6 > > kernel: usbserial_generic 1-2.2:1.0: Generic converter detected > > kernel: usbserial_generic 1-2.2:1.0: Generic device with no bulk > > out, not > > allowed. > > kernel: usbserial_generic: probe of 1-2.2:1.0 failed with error -5 > > > > So, I don't have the knowledge to solve the problem, I do have the > > hardware to > > test a solution to it. > > Could you have a look? > > > > Many thanks in advance, > > Rob. > > > > > > > > Bus 001 Device 006: ID 07d0:4100 Dazzle > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 1.10 > > bDeviceClass 0 (Defined at Interface level) > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 8 > > idVendor 0x07d0 Dazzle > > idProduct 0x4100 > > bcdDevice 0.00 > > iManufacturer 1 Kingsun Semiconductor > > iProduct 2 USB to Serial > > iSerial 0 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 41 > > bNumInterfaces 1 > > bConfigurationValue 1 > > iConfiguration 4 USB to Serial > > bmAttributes 0x80 > > MaxPower 100mA > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 2 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 85 > > bInterfaceProtocol 0 > > iInterface 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0008 1x 8 bytes > > bInterval 1 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x02 EP 2 OUT > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0008 1x 8 bytes > > bInterval 1 > > > > > > > > > > > > [Written by Martin Diehl <[EMAIL PROTECTED]>, modified by me] > > > > > > > i've bought a irda-usb dongle MA620 and i can't get it work with > > > > > kernel driver irda-usb.c - it's not supported. Does anybody have > > > > > experince with this? > > > > I don't have this hardware, but a few comments anyway: > > > > 1) Despite it's an USB device the MA620 has nothing to do with the > > IrDA-USB class spec. Therefore irda-usb.c is not the right driver. > > > > 2) Reportedly the MA620 is made by glueing a SIR encoder+transceiver to a > > pl2303 usb-to-rs232 bridge. Therefore the required setup is basically > > irtty on top of the usbserial+pl2303 driver - maybe the device id's have > > to be added to the pl2303 driver. > > > > 3) Furthermore it was also said the SIR silicon appears to be > > connected to > > the pl2303 the same way which is used for the MA600 serial dongle. > > Therefore the ma600 dongle protocol is needed on top of irtty. > > > > 4) With 2.4.x any setup with irtty (or similar drivers like ppp) on > > top of > > usb-serial has severe problems (might sleep with spinlock held). To fix > > this, backporting the usbserial from 2.6 would be required - which is > > rather unlikely to happen AFAICS. Furthermore even with this fixed > > the old > > irtty from 2.4.x has some potential locking issues wrt. tty and network > > layer. In conclusion irtty over usb will not work with 2.4 - sorry! > > > > 5) In 2.6 the usbserial issue is fixed and we have the new irtty-sir > > there. I know from my own 2.6-testing pl2303/usbserial/sir_dev/irtty-sir > > are all working together happily with some supported serial dongle behind > > an usb-to-rs232 bridge. Hence the remaining issue is to get the converted > > ma600 dongle driver working. This should be pretty easy if the MA620 > > internal wiring is really the same as MA600 and someone with the hardware > > would do the required testing. > > > > 6) You need to use irattach version 0.9.16-pre7 or later > > > So I went and added 07c0:4200 as a new ID to the pl2303 driver in the > sources, just to see what would happen. At first, the device was > "recognized", but on the first open of /dev/ttyUSB0 (by irattach) I get > a kernel oops: > > Jul 25 20:58:48 karlalex kernel: usb 1-1: new low speed USB device using > uhci_hcd and address 2 > Jul 25 20:58:48 karlalex kernel: usb 1-1: configuration #1 chosen from 1 > choice > Jul 25 20:58:48 karlalex kernel: usbcore: registered new driver usbserial > Jul 25 20:58:48 karlalex kernel: drivers/usb/serial/usb-serial.c: USB > Serial support registered for generic > Jul 25 20:58:48 karlalex kernel: usbcore: registered new driver > usbserial_generic > Jul 25 20:58:48 karlalex kernel: drivers/usb/serial/usb-serial.c: USB > Serial Driver core > Jul 25 20:58:48 karlalex kernel: drivers/usb/serial/usb-serial.c: USB > Serial support registered for pl2303 > Jul 25 20:58:48 karlalex kernel: pl2303 1-1:1.0: pl2303 converter detected > Jul 25 20:58:48 karlalex kernel: usb 1-1: pl2303 converter now attached > to ttyUSB0 > Jul 25 20:58:48 karlalex kernel: usbcore: registered new driver pl2303 > Jul 25 20:58:48 karlalex kernel: drivers/usb/serial/pl2303.c: Prolific > PL2303 USB to serial adaptor driver > Jul 25 20:58:48 karlalex kernel: BUG: unable to handle kernel NULL > pointer dereference at virtual address 00000030 > Jul 25 20:58:48 karlalex kernel: printing eip: > Jul 25 20:58:48 karlalex kernel: deba24e8 > Jul 25 20:58:48 karlalex kernel: *pde = 00000000 > Jul 25 20:58:48 karlalex kernel: Oops: 0000 [#1] > Jul 25 20:58:48 karlalex kernel: PREEMPT > Jul 25 20:58:48 karlalex kernel: Modules linked in: pl2303 usbserial > binfmt_misc nls_ascii nls_cp437 vfat fat dm_mirror dm_mod video button > battery asus_acpi ac lp floppy nvram snd_via82xx_modem snd_via82xx > gameport snd_seq_dummy snd_ac97_codec snd_ac97_bus snd_seq_oss > snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm ehci_hcd > uhci_hcd snd_mpu401_uart snd_rawmidi snd_seq_device snd_timer parport_pc > snd via_agp parport i2c_viapro soundcore via_ircc i2c_prosavage > via_rhine mii agpgart irda ide_cd pcspkr crc_ccitt snd_page_alloc cdrom > rtc usbcore ext3 jbd > Jul 25 20:58:48 karlalex kernel: CPU: 0 > Jul 25 20:58:48 karlalex kernel: EIP: 0060:[<deba24e8>] Not > tainted VLI > Jul 25 20:58:48 karlalex kernel: EFLAGS: 00010297 (2.6.18-rc2 #1) > Jul 25 20:58:48 karlalex kernel: EIP is at pl2303_open+0x28/0x9c0 [pl2303] > Jul 25 20:58:48 karlalex kernel: eax: 00000000 ebx: 00000000 ecx: > deba5e20 edx: ddf7c240 > Jul 25 20:58:48 karlalex kernel: esi: dd78f280 edi: ddb75c00 ebp: > dd6d3c80 esp: dcad1e3c > Jul 25 20:58:48 karlalex kernel: ds: 007b es: 007b ss: 0068 > Jul 25 20:58:48 karlalex kernel: Process irattach (pid: 1394, > ti=dcad1000 task=ddf211d0 task.ti=dcad1000) > Jul 25 20:58:48 karlalex kernel: Stack: dcad1e60 c0117008 00000000 > 00000000 00000003 00000292 dcb8b800 00000000 > Jul 25 20:58:48 karlalex kernel: c02fc524 dcb8b800 c0228b36 > 00000000 c0229a64 00000246 c031cc17 deb2934f > Jul 25 20:58:48 karlalex kernel: 00000000 ddb75c00 dd78f280 > ffffffed dcb8b800 deb26269 00000000 c02fc48f > Jul 25 20:58:48 karlalex kernel: Call Trace: > Jul 25 20:58:48 karlalex kernel: [<c0117008>] __wake_up+0x38/0x50 > Jul 25 20:58:48 karlalex kernel: [<c02fc524>] > _spin_unlock_irqrestore+0x14/0x30 > Jul 25 20:58:48 karlalex kernel: [<c0228b36>] tty_ldisc_enable+0x26/0x30 > Jul 25 20:58:48 karlalex kernel: [<c0229a64>] init_dev+0x254/0x690 > Jul 25 20:58:48 karlalex kernel: [<deb26269>] serial_open+0x139/0x1f0 > [usbserial] > Jul 25 20:58:48 karlalex kernel: [<c02fc48f>] _spin_unlock+0xf/0x30 > Jul 25 20:58:48 karlalex kernel: [<c0228a29>] check_tty_count+0x49/0xb0 > Jul 25 20:58:48 karlalex kernel: [<c022bb5e>] tty_open+0x16e/0x340 > Jul 25 20:58:48 karlalex kernel: [<c016f639>] chrdev_open+0xd9/0x1d0 > Jul 25 20:58:48 karlalex kernel: [<c016464a>] __dentry_open+0xea/0x270 > Jul 25 20:58:48 karlalex kernel: [<c0164885>] nameidata_to_filp+0x35/0x40 > Jul 25 20:58:48 karlalex kernel: [<c016f560>] chrdev_open+0x0/0x1d0 > Jul 25 20:58:48 karlalex kernel: [<c01648db>] do_filp_open+0x4b/0x60 > Jul 25 20:58:48 karlalex kernel: [<c02fc48f>] _spin_unlock+0xf/0x30 > Jul 25 20:58:48 karlalex kernel: [<c0164541>] get_unused_fd+0xa1/0xc0 > Jul 25 20:58:48 karlalex kernel: [<c016493a>] do_sys_open+0x4a/0xe0 > Jul 25 20:58:48 karlalex kernel: [<c0164a0c>] sys_open+0x1c/0x20 > Jul 25 20:58:48 karlalex kernel: [<c010310d>] sysenter_past_esp+0x56/0x79 > Jul 25 20:58:48 karlalex kernel: Code: 8d 76 00 55 57 89 c7 56 53 83 ec > 44 8b 1d 00 65 ba de 8b 30 8b a8 0c 02 00 00 85 db 0f 85 51 04 00 00 83 > 7d 34 02 74 1a 8b 47 6c <8b> 50 30 8b 06 e8 6e 1b c9 ff 8b 47 5c 8b 50 > 30 8b 06 e8 61 1b > Jul 25 20:58:48 karlalex kernel: EIP: [<deba24e8>] > pl2303_open+0x28/0x9c0 [pl2303] SS:ESP 0068:dcad1e3c > Jul 25 20:58:48 karlalex kernel: <6>usb 1-1: USB disconnect, address 2 > Jul 25 20:58:49 karlalex kernel: pl2303 1-1:1.0: device disconnected > > Now my question is: is this kernel oops the result of adding a foreign > USB ID that would not work with this driver (pl2303) anyway, or is this Yep, it's because (I think) the dongle replied to the driver in a way that the driver wasn't expecting because the protocol used by the pl2303 was apparently different from the one used by the device. > oops caused by something else going on? Thanks in advance for any reply > at all. > > Alex Villacís Lasso > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Linux-usb-users@lists.sourceforge.net > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-users > -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
