Re: [linux-usb-devel] hid drivers
On Fri, 20 Apr 2007, John Wojnaroski wrote: I've READ the specs, examined countless examples, browsed innumerable websites. This is a silly, simple little keyboard device customized to handle static switches. It has one endpoint and takes a three byte command and sends a three byte packet that reports an event in the switch matrix. that is all it does, that is ALL it will ever do. It works under MS windows. A copy of a SnoopyPro log has been sent along. Replicate the log under Linux and the device should work. Right? Now perhaps the log is missing some data, but that can be provided, descriptors, endpoint class, etc. It appears to use the Cypress Semiconductor series of USB hardware. And I'm clearly doing something wrong or mis-interpreting what is required to communicate with the device. As you said, duplicate the log under Linux and the device will work. The problem is that you're not duplicating the log. The SnoopyPro log shows that Windows always has two Bulk or Interrupt URBs pending, but your program doesn't use any. I don't want to become an expert on writing USB drivers, at least not at this time. Just a simple request as to how to make the device work under linux. If the forum can't handle that request, then IMHO it is the wrong place. It's not a question of Linux vs. Windows, it's a question of making your driver do what it's supposed to do. As for not wanting to become an expert... That's understandable, but you _do_ have to become something of an expert on writing drivers for the type of device you're interested in. Otherwise you'll never be able to make it work. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
No, it's the correct place. But you should start out by learning the basics. Read through parts of the USB 2.0 spec and then you'll be in better shape. I've READ the specs, examined countless examples, browsed innumerable websites. This is a silly, simple little keyboard device customized to handle static switches. It has one endpoint and takes a three byte command and sends a three byte packet that reports an event in the switch matrix. that is all it does, that is ALL it will ever do. It works under MS windows. A copy of a SnoopyPro log has been sent along. Replicate the log under Linux and the device should work. Right? Now perhaps the log is missing some data, but that can be provided, descriptors, endpoint class, etc. It appears to use the Cypress Semiconductor series of USB hardware. And I'm clearly doing something wrong or mis-interpreting what is required to communicate with the device. I don't want to become an expert on writing USB drivers, at least not at this time. Just a simple request as to how to make the device work under linux. If the forum can't handle that request, then IMHO it is the wrong place. John - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Tue, 17 Apr 2007, John Wojnaroski wrote: Hmm, now I'm puzzled. Does the byte order actually depict the sequence of the bits sent by the OS? Yes, although the way in which the order depicts the sequence depends on the formatting of the particular message in question. Is this a difference in bigendian/littleendian digits? If so, I goofed, so on to the fix and next step. Excerpt from the usbmon.txt in ../Linux/Documentaton/usb , - Setup packet, if present, consists of 5 words: one of each for bmRequestType, bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. These words are safe to decode if Setup Tag was 's'. Otherwise, the setup packet was present, but not captured, and the fields contain filler. . Here is the usbmon report when I set the wValue to 0x0200 df99e540 2476601557 S Co:002:00 s 21 09 0200 0003 3 = 020202 df99e540 2476606432 C Co:002:00 0 3 so, that now matches the URB #9 from the SNoopyPro report under windows; bmRequestType = 21 bRequest = 09; wValue = 0x0200 wIndex = 0x wLength = 0x0003 As it shoud. Note that the three word-sized quantities are transmitted in little-endian byte order on the USB bus. That shouldn't matter as far as you are concerned, however. according to the description cited above. And with the s that would indicate the packet was captured, but still not getting a response from the device. What makes you think you should get a response from the device? Your usbmon trace doesn't show that you asked for one. You sent a control-OUT message with the three bytes 0x02 0x02 0x02, but you didn't submit any IN transfers. Just for completness, here is a series of four frames for each call to the control msg. df99e540 2476601557 S Co:002:00 s 21 09 0200 0003 3 = 020202 df99e540 2476606432 C Co:002:00 0 3 That's your control-OUT. df99e540 2476606551 S Co:002:00 s 01 0b 0 df99e540 2476609431 C Co:002:00 0 0 That's the kernel restoring altsetting 0 after your program ended. df99e540 2478577426 S Co:002:00 s 00 09 0001 0 df99e540 2478580115 C Co:002:00 0 0 df99e540 2478580265 S Co:002:00 s 01 0b 0 df99e540 2478583113 C Co:002:00 0 0 df99e540 2478583236 S Co:002:00 s 21 09 0200 0003 3 = 020202 This looks like your program running again, doing a Set-Config and a Set-Interface and then sending the control-OUT message. If the device ever did want to send any data back, your program didn't give it a chance. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
Alan Stern wrote: On Wed, 18 Apr 2007, John Wojnaroski wrote: OK, so an IN transfer might look something like 22 09 0200 Except that it couldn't use 0x22 in the first byte. The high-order bit of that byte determines the direction. It would have to be 0xa2. Then why does the SnoopyPro log indicate that the above byte stream illicits a response from the device, or am I mis-reading the log? It all depends on the device, and what sort of messages it expects to send or receive. Given the SnoopyPro log I provided with the device working under Windows, seems it would be a routine matter to determine what the device expects and how to build the URB with linux calls. Except, for someone like myself who is just beginning. Perhaps this is the wrong forum for this sort of help. John - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Wed, 18 Apr 2007, John Wojnaroski wrote: Alan Stern wrote: On Wed, 18 Apr 2007, John Wojnaroski wrote: OK, so an IN transfer might look something like 22 09 0200 Except that it couldn't use 0x22 in the first byte. The high-order bit of that byte determines the direction. It would have to be 0xa2. Then why does the SnoopyPro log indicate that the above byte stream illicits a response from the device, or am I mis-reading the log? Please be more specific. Which URBs in the SnoopyPro log are you referring to? Numbers 7, 8, 10, 12, 14, and so on? Unforunately the log doesn't seem to mention the endpoint number or the direction for those transfers, but it does say that they are Bulk or Interrupt. So whichever endpoint they use, your program needs to use. Given the SnoopyPro log I provided with the device working under Windows, seems it would be a routine matter to determine what the device expects and how to build the URB with linux calls. Except, for someone like myself who is just beginning. Perhaps this is the wrong forum for this sort of help. No, it's the correct place. But you should start out by learning the basics. Read through parts of the USB 2.0 spec and then you'll be in better shape. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Mon, 16 Apr 2007, John Wojnaroski wrote: OK, attached is a log report.Not all that conversant in analyzing the log. about the only item I note is the order of the last two bytes defining the packet size; SnoopyPro shows 0300 under Windows and usbmon shows 0003 under Linux for the control msg. You are referring to URB #9 in the Windows log, right? It shows: SetupPacket 21 09 00 02 00 00 03 00 TransferBuffer: 0x0003 (3) length : 02 ff ff Significant?? Or just a formatting artifact? de9ab1c0 1992901010 S Co:003:00 s 21 09 0002 0003 3 = 020202 de9ab1c0 1992905882 C Co:003:00 0 3 It is indeed significant. The Windows program has wValue set to 0x0200 and your Linux program has it set to 0x0002. That could be the source of all your problems right there. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
Alan Stern wrote:
On Mon, 16 Apr 2007, John Wojnaroski wrote:
OK, attached is a log report.Not all that conversant in analyzing
the log. about the only item I note is the order of the last two bytes
defining the packet size; SnoopyPro shows 0300 under Windows and usbmon
shows 0003 under Linux for the control msg.
You are referring to URB #9 in the Windows log, right? It shows:
SetupPacket
21 09 00 02 00 00 03 00
TransferBuffer: 0x0003 (3) length
: 02 ff ff
Significant?? Or just a formatting artifact?
de9ab1c0 1992901010 S Co:003:00 s 21 09 0002 0003 3 = 020202
de9ab1c0 1992905882 C Co:003:00 0 3
It is indeed significant. The Windows program has wValue set to 0x0200
and your Linux program has it set to 0x0002. That could be the source of
all your problems right there.
Hmm, now I'm puzzled. Does the byte order actually depict the sequence
of the bits sent by the OS? Is this a difference in
bigendian/littleendian digits? If so, I goofed, so on to the fix and
next step.
Excerpt from the usbmon.txt in ../Linux/Documentaton/usb
,
- Setup packet, if present, consists of 5 words: one of each for
bmRequestType,
bRequest, wValue, wIndex, wLength, as specified by the USB
Specification 2.0.
These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
packet was present, but not captured, and the fields contain filler.
.
Here is the usbmon report when I set the wValue to 0x0200
df99e540 2476601557 S Co:002:00 s 21 09 0200 0003 3 = 020202
df99e540 2476606432 C Co:002:00 0 3
so, that now matches the URB #9 from the SNoopyPro report under windows;
bmRequestType = 21
bRequest = 09;
wValue = 0x0200
wIndex = 0x
wLength = 0x0003
according to the description cited above. And with the s that would
indicate the packet was captured, but still not getting a response from
the device.
Just for completness, here is a series of four frames for each call to
the control msg.
df99e540 2476601557 S Co:002:00 s 21 09 0200 0003 3 = 020202
df99e540 2476606432 C Co:002:00 0 3
df99e540 2476606551 S Co:002:00 s 01 0b 0
df99e540 2476609431 C Co:002:00 0 0
df99e540 2478577426 S Co:002:00 s 00 09 0001 0
df99e540 2478580115 C Co:002:00 0 0
df99e540 2478580265 S Co:002:00 s 01 0b 0
df99e540 2478583113 C Co:002:00 0 0
df99e540 2478583236 S Co:002:00 s 21 09 0200 0003 3 = 020202
Well, I'll keep beating on this problem. Might even learn a few things
in the process ;-)
John
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
Alan Stern wrote: On Sat, 14 Apr 2007, John Wojnaroski wrote: 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 There's something fishy here. This output lists 9 bytes but a control setup packet is supposed to contain only 8 bytes of data. Is it possible that Byte 2 doesn't belong in there at all? Could be the not-yet-stripped ReportID. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Sun, 15 Apr 2007, John Wojnaroski wrote: Ok, here is a copy of the msg and data of the MS windows USB trace I received from the vendor. I'll talk with them tomorrow and see if they can send an unedited trace of a complete packet. Might be quicker than trying to set up another usb sniffer for Windows. This is no good because we don't know what it means. That's why I asked you to use a USB sniffer program whose output we can understand. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
Alan Stern wrote: On Mon, 16 Apr 2007, John Wojnaroski wrote: Okay, I will do that, so if I understand your direction get SnoopyPro from sourceforge, install it under MS windows, and run some traces with the device working under that OS then post the results correct? That's the idea. Alan Stern OK, attached is a log report.Not all that conversant in analyzing the log. about the only item I note is the order of the last two bytes defining the packet size; SnoopyPro shows 0300 under Windows and usbmon shows 0003 under Linux for the control msg. Significant?? Or just a formatting artifact? de9ab1c0 1992901010 S Co:003:00 s 21 09 0002 0003 3 = 020202 de9ab1c0 1992905882 C Co:003:00 0 3 John USBLog2.usblog Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Sat, 14 Apr 2007, John Wojnaroski wrote: Alan Stern wrote: On Sat, 14 Apr 2007, John Wojnaroski wrote: 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 There's something fishy here. This output lists 9 bytes but a control setup packet is supposed to contain only 8 bytes of data. Is it possible that Byte 2 doesn't belong in there at all? Alan Stern Or the last byte, the trace was sent to me by the folks who built the chip and ran it on their test setup. It works just fine, well at least it works with the test and .dll file they provided. If byte 2 is removed that says the bytes are in reverse order. I don't know what you mean by reverse order. They are supposed to be in little-endian order. Since the original call to USB_CMD (not shown above) was USB_CMD( 21 9 2 0 3 ), I assumed that the 2 and 3 really did mean 2 and 3 -- not 0x200 or 0x300 -- and so the correct sequence of bytes should have been 0x21 0x09 0x02 0x00 0x00 0x00 0x03 0x00 I have to recompile my kernel, looks like 2.6.9 does not have the usbmon code as there is no text file in Doc That breaks a few modules I have, nothing major, but one more step -- a lot of work for three lousy bytes , ahhh, the price of progress ;-) You'd be a lot better off using a more recent kernel, such as 2.6.20. Thanks guys, for the help, good news is I have the usb monitor working. here is a bit of output for a control msg de01e2c0 3812071750 S Co:003:00 s 21 09 0200 0003 3 = 021f1f Note that this byte sequence indicates you did the equivalent of USB_CMD( 21 9 200 0 3 ), which is different from what you wrote earlier. de01e2c0 3812076624 C Co:003:00 0 3 de01e2c0 3812076741 S Co:003:00 s 01 0b 0 de01e2c0 3812079623 C Co:003:00 0 0 bad news is the device likes to see a two byte CRC value after the 3 byte data packet, shown here as 021F1F Are you talking about the standard USB CRC? It is added automatically by the computer's USB host controller at the end of every packet which needs it. Or are you talking about some other CRC, something specific to this particular device? If so then you need to put it there yourself, making the data packet 5 bytes, not 3. looks like I need to talk to the folks at Hagstrom who built the chip to see exactly what is possible. If the kernel (devio.c or whatever) does not add a CRC value not sure how to fake it. Trying to add it apriori and upping the byte count to 5 doesn't work and returns a Broken pipe msg. Did you remember to specify the increased length in the call to USB_CMD? USB_CMD( 21 9 200 0 5 ) Guess the chip thinks three+2, runs the CRC to confirm, and then throws it away and acts on the first three bytes if valid. I played with the byte ordering for the h--- of it with no change, data goes out but the chip fails to return a 3 byte response packet It sounds like you don't really know what the chip wants to receive. It's going to be hard to make any progress until you can figure that out. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Sun, 15 Apr 2007, John Wojnaroski wrote: Hi Alan, Thanks for working your way through my mess. I was trying a numer of ideas last night and things got a little convoluted. You've answered my question regards the CRC I sent before I saw your reply. Think I know what the chip needs in the way of a msg data packet, but probably the problem lays in my being able to provide the correct parameters to form the urb and send it to the correct endpoint. It is a little frustrating learning a new topic and trying to ask the right questions. Thank you for help and patience. I have found the most useful reference to be the official USB 2.0 spec, available from www.usb.org. Particularly chapters 5, 8, and 9. If you can post a more-or-less complete Windows USB trace, we ought to be able to interpret it for you. You can always use freely available programs like USB SnoopyPro (from sourceforge) to get such a trace. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
Alan Stern wrote: On Sun, 15 Apr 2007, John Wojnaroski wrote: Hi Alan, Thanks for working your way through my mess. I was trying a numer of ideas last night and things got a little convoluted. You've answered my question regards the CRC I sent before I saw your reply. Think I know what the chip needs in the way of a msg data packet, but probably the problem lays in my being able to provide the correct parameters to form the urb and send it to the correct endpoint. It is a little frustrating learning a new topic and trying to ask the right questions. Thank you for help and patience. I have found the most useful reference to be the official USB 2.0 spec, available from www.usb.org. Particularly chapters 5, 8, and 9. If you can post a more-or-less complete Windows USB trace, we ought to be able to interpret it for you. You can always use freely available programs like USB SnoopyPro (from sourceforge) to get such a trace. Ok, here is a copy of the msg and data of the MS windows USB trace I received from the vendor. I'll talk with them tomorrow and see if they can send an unedited trace of a complete packet. Might be quicker than trying to set up another usb sniffer for Windows. John --- Dave with Hagstrom Electronics, Inc. ;[EMAIL PROTECTED] wrote: - OK, here's what we traced for the received setup packet for a getstatus or report request command: 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 us as well. Byte 3 = 0xDE Byte 4 = 0X4F Not sure if your routine automatically calculates that and adds it tothe report buffer or if you need to do it. With Windows, thecalculation is automatically performed and added to the message. Isuspect your USB Host device automatically puts that in. Command for Request Report: Byte 0 = 0x01 Byte 1 = 0xFF (don't care) Byte 2 = 0xFF (don't care) then the checksum bytes: Byte 3 = 0x2E Byte 4 = 0X4F Thanks, Dave Hagstrom Electronics, Inc. www.hagstromelectronics.com There are just two more commands 0x03 and 0x04 to set row and column masks of an 16x8 switch matrix. The response report consists of three bytes. Silly question? those are loaded into the same buffer that is used by the outgoing command, correct? I could be doing something stupid like looking for the answer in the wrong place! John - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
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 / lfs 004/001 / lfs 003/003 0FC5/1222 lfs 003/002 049F/000E lfs 003/001 / lfs 002/003 046D/C214 lfs 002/002 0FC5/1222 lfs 002/001 / lfs 001/001 / 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-: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
Re: [linux-usb-devel] hid drivers
Alan Stern wrote: On Sat, 14 Apr 2007, John Wojnaroski wrote: 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? The sniffers for Windows don't show you what's actually going down (or up) the wire; they only show what the OS _thinks_ is going down the wire. The equivalent facility in Linux is part of the kernel. It's called usbmon and the instructions are in the kernel source file Documentation/usb/usbmon.txt. Alan Stern Right, understand, a bit of semantics ;-) i.e what is presented at the port where the software meets the hardware, correct? At least to verify the OS is doing things correctly, what happens on the physical media is another matter... Thanks John - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Sat, 14 Apr 2007, John Wojnaroski wrote: 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? The sniffers for Windows don't show you what's actually going down (or up) the wire; they only show what the OS _thinks_ is going down the wire. The equivalent facility in Linux is part of the kernel. It's called usbmon and the instructions are in the kernel source file Documentation/usb/usbmon.txt. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Sat, 14 Apr 2007, John Wojnaroski wrote: 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 There's something fishy here. This output lists 9 bytes but a control setup packet is supposed to contain only 8 bytes of data. Is it possible that Byte 2 doesn't belong in there at all? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
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-: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, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
