Ok, some progress... here is the output of a small test program to sent a three byte packet to the device. Had to recompile the kernel to keep it from trying to claim the device and attach the usbhid driver. Here is the enumeration data <<<<<<<<<<<<<<,,
> T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 > D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=04b4 ProdID=0202 Rev= 1.01 > S: Manufacturer=LFS Technologies > S: Product=LFS Technologies HID > S: SerialNumber=? > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 52mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=(none) > E: Ad=81(I) Atr=03(Int.) MxPS= 6 Ivl=10ms >>>>>>>>>>>>>>>>>>.... and the output from a small test program sending a usb_control_msg <<<<<<<<<<<,, lfs> Looking for the lfs lfs> bus/device idVendor/idProduct lfs> 005/002 04B4/0202 * Device ID of devices 1 lfs> 005/001 0000/0000 lfs> 004/001 0000/0000 lfs> 003/003 0FC5/1222 lfs> 003/002 049F/000E lfs> 003/001 0000/0000 lfs> 002/003 046D/C214 lfs> 002/002 0FC5/1222 lfs> 002/001 0000/0000 lfs> 001/001 0000/0000 lfs> Interface Number 0 lfs> Set Configuration 1 lfs> Claim Interface 0 lfs> Set Alternative Interface 0 Cmd Packet: 2 2 2 LFStech> USB_CMD( 21 9 2 0 3 ) lfs> Packet Sent Successfully with 3 bytes 2 2 2 >>>>>>>>>>>>>> The control_msg returns three bytes; the basis for the "success msg", but believe that just indicates that three bytes were sent as called for, the returned data packet should return three 0xFF bytes, so I'm a little suspicious if the device really saw the correct packet for the formed urb. Note, there is a timeout value in the msg argument list, just not shown in the packet string above. The device works with a MS windows test program with the same simple test... and I have samples of the actual data packets to compare against linux. Is there a simple, quick, uncomplicated tool to look see what is actually going down the wire? Lots of sniffers for MS stuff, could not find similar tools for the linux OS. Something already in the kernel, module, whatever? Might it be a byte-ordering issue? Here is a trace of the MS windows program doing it's thing Byte 0 = 0x21 Byte 1 = 0x09 Byte 2 = 0x00 Byte 3 = 0x02 Byte 4 = 0x00 Byte 5 = 0x00 Byte 6 = 0x00 Byte 7 = 0x03 Byte 8 = 0x00 Command for get status: Byte 0 = 0x02 Byte 1 = 0xFF (don't care) Byte 2 = 0xFF (don't care) An additional 2 bytes of CRC is received by as well. Byte 3 = 0xDE Byte 4 = 0X4F Not sure if the Linx routine automatically calculates that and adds it to the report buffer or if you neeed to do it. With Windows, the calculation is automatically performed and added to the message. I suspect the USB Host device automatically puts that in. Would seem reasonable, can't find anything to expicitly confirm the CRC calculation. Any suggestions would be appreciated... in the interest of brevity, I'll not include the source for now. This might be the best and most direct approach if I can decipher why the device seems not to be responding... John Jiri Kosina wrote: >On Fri, 13 Apr 2007, John Wojnaroski wrote: > > > >>I'm writing a simple little driver to read three bytes from a hid device >>when plugged in it reports as hiddev96:__________--usb-0000:00:1d.0-2 >>and shows up in /dev/usb/hiddev0 and is enumerated in >>/proc/bus/usb/devices. Thinking a simple usb_control_msg will be good >>and simple enough to have the device send the three bytes >> >> > >Hi John, > >there have been various discussions lately about many topics related to >your question - please crawl through the list archives if interested (the >best keywords probably are "hid bus", "hiddev", "hidraw"). > > > >>Is there a way to do that with the hid interface using ioctl >>open/read/write functions or will it be necessary to use the >>usb_control_msg(...) call directly? >> >> > >What you describe is unfortunately not doable (in a trivial way) through >hiddev - hiddev works in a way that it parses the reports based on the >information obtained from the device's report descriptor, and processess >the fields for outgoing reports also in this respect. > >Therefore it is not well suitable for straigforward submission of 'raw' >HID data. Unfortunately, it's often what userland applications want most - >they are willing to send the raw hid data to the device and don't want the >kernel to tamper it in any way. There may be many reasons for them doing >so, the most significant is broken/undocumented devices which have report >descriptor that confuses the in-kernel HID layer and it parses >reports/fields incorrectly. > >This is why many applications chose to use libhid/libusb instead. This >passes the data directly to the USB transport layer, without letting the >HID layer to touch it. >And this is also the reason for the new 'hidraw' interface being created - >the current prototype of mostly-feature-less version is in current -mm >kernels, and also in the HID git tree. >It's possible that both the API and the internals of the hidraw interface >will change before being merged into mainline - most importantly there is >a hid bus coming soon (hopefully), which might change things. But it might >be interesting for you to look at. > >To sum things up - currently, hiddev doesn't seem to be a feasible option >for you. You can either use libhid/libusb and submit the data directly to >USB transport, or you can experiment with kernel-provided lightweight >hidraw interface in -mm, but it's not guaranteed to be in a frozen-API >state yet. > >Hope this helps, > > > ------------------------------------------------------------------------- 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 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
