Mouse device recognition ???

[gbr]

A new problem :

I have successfully done a joystick with a second interface that include a rudimentary keyboard access to send sets of key strokes
That works perfectly
on the same interface I also have a mouse (also rudimentary)as I want only to create movements
in x and y directions only
This shows perfectly on my sniffer but it does not do anything on the screen.
I suspect that I have to do something to allow windows to recognize my device
The big trouble is I dont know how to do that.
Could someone kindly explain that to me please...( Jan again ??  )
It is the last hurdle for my special additional device for IL2(including a separate FFB joystick(not done mechanically yet))
Thanks in advance  
I have read about inf files but I am too stupid to understand........
I forgot to mention :
Pic 18F4550
Tool assembler only (no C)
ASM Oshon

[Guido Koerber]

This has nothing to do with INF files.

First Windows is quite fun when you incrementally develop a USB device. Since Windows has that nice concept called "Registry" it keeps outdated information about your hardware.

Always remove the device from device manager before doing changes to the descriptors.

Second you will need to use ReportIDs. Define one report for the keyboard, another for the mouse. This should work with standard drivers.

[gbr]

Thanks Guido,
I have the following report descriptor for the interface 2(Kbd+Mouse)
I also though of removing some unused mouses drivers and now it seems to do some things (bad ones but it is a beginning) Light a the end of the tunnel....

Code: [Select]

;digits and mouse try
HidReportdescriptor2:
 dw 0x05 ,0x01 ; USAGE_PAGE (Generic Desktop)
 dw 0x09 ,0x06 ;   USAGE (Keyboard)
 dw 0xA1 ,0x01 ; COLLECTION (Application)
 dw 0x85 ,0x01 ;     REPORT_ID (1)
; position of line below is very critical
 dw 0x05 ,0x07 ;     USAGE_PAGE (Keyboard)

 dw 0xA1 ,0x00 ;   COLLECTION (Physical);;;;;;;;;;;;;;;;;;;;;;;;;;;;
 dw 0x19 ,0x00 ;     USAGE_MINIMUM (Reserved (no event indicated))
 dw 0x29 ,0x45 ;     USAGE_MAXIMUM (Keyboard F12)
 dw 0x15 ,0x00 ;     LOGICAL_MINIMUM (0)
 dw 0x25 ,0x45 ;     LOGICAL_MAXIMUM (69)
 dw 0x95 ,0x01 ;     REPORT_COUNT (1)
 dw 0x75 ,0x08 ;     REPORT_SIZE (8)
 dw 0x81 ,0x00 ;     INPUT (Data,Ary,Abs)
 dw 0xC0 ;   END_COLLECTION
 dw 0xA1 ,0x00 ;   COLLECTION (Physical)
 dw 0x05 ,0x01 ;     USAGE_PAGE (Generic Desktop)
 dw 0x85 ,0x02 ;     REPORT_ID (2)
 dw 0x09 ,0x02 ;     USAGE (Mouse)
 dw 0x09 ,0x30 ;     USAGE (X)
 dw 0x09 ,0x31 ;     USAGE (Y)
 dw 0x35 ,0x81 ;     PHYSICAL_MINIMUM (-127)
 dw 0x45 ,0x7F ;     PHYSICAL_MAXIMUM (127)
 dw 0x15 ,0x81 ;     LOGICAL_MINIMUM (-127)
 dw 0x25 ,0x7F ;     LOGICAL_MAXIMUM (127)
 dw 0x75 ,0x08 ;     REPORT_SIZE (8)
 dw 0x95 ,0x01 ;     REPORT_COUNT (1)
 dw 0x81 ,0x06 ;     INPUT (Data,Var,Rel)
 dw 0xC0 ;   END_COLLECTION
 dw 0xC0 ; END_COLLECTION


Endof2:
Double2 equ Endof2 - HidReportdescriptor2
LenOFdescr2 equ Double2/2

;One byte at a time for key board entry ,followed by a zero (simulated release of key)
;For the mouse it tests the value positive or negative relative and send a 1(pos) a 0Xff(neg) or a ;0;(no move)but nothing moves except that my sniffer sometimes now registers a mouse data ...... 


[mdlayt]

Yes.  Often a bad descriptor crashes the device manager and you have to reboot.  If you are "lucky" you get 1 bit of information about your bug:  "Error device cannot start" and you don't have to reboot.

You might find that a test program can give you more feedback about a report descriptor (buggy or not).  Although I was through debugging descriptors by the time I started using the app below.

I'm running USB 2.0 Command Verifier.  I don't remember where I downloaded it.  Maybe usb.org.  Or try googling it.

Mike

[Jan Axelson]

Now called USB20CV and USB30CV:

http://www.usb.org/developers/developers/tools/

Jan

[gbr]

Thanks for the answers,chaps.

I did not need anythong else apart from my trusted sniffer

I suddenly realised that Windows needed to see the mouse buttons and they were missing in the descriptor and of course in the program too
Instead of                                                  ID 2 , x,y                             ===> 3 bytes
I implemented the buttons making:                 ID 2 , buttons(locked to 0), X , Y => 4 Bytes ,and it worked !!!!!
I stil have a super stripped down "keyBoard" :  ID 1 , one byte at a time    ====>>  2 bytes 

Feeling the weight of help at hand by specialists has wipped  my brain into focus 

Have all a merry Christmas and Happy new Year

And thanks again to Jan for this Forum.

g b

[Guido Koerber]

Oh, Windows and its assumptions about devices. There are a number of things to avoid when making USB devices. The sloppy support by Microsoft kills good ideas. Like the simulation controls page which is basically unusable since only few items are supported by DirectInput unless the game developer goes low level.

[mdlayt]

So gbr, if I'm understanding correctly, your *report descriptor* didn't have any buttons, so you never got loaded by Windows as a generic mouse.  Of course, you can see this in the device manager:  Right click on device, select properties, look at Driver tab.

I suppose it does make sense that a "mouse" can't really function without at least a "click."  Unless, of course, it is like yours and is only *supplemental* to some other device with a button.

Probably there is a document somewhere on microsoft.com that explains what a Windows compatible "mouse" must be--but I'm not aware of anywhere where they say what devices will be connected to the generic mouse driver on USB.  There is, certainly, the description of the boot mouse in HID1_11.pdf Appendix B (see usb.org).

[gbr]

Probably there is a document somewhere on microsoft.com that explains what a Windows compatible "mouse" must be--but I'm not aware of anywhere where they say what devices will be connected to the generic mouse driver on USB.  There is, certainly, the description of the boot mouse in HID1_11.pdf Appendix B (see usb.org).

Yes ,but there is some difference of handling for keyboard because my "bare bones" descriptor of Report ID 1(see code above, one byte for ID , one DATA byte). is recognized as a keyboard ,There is a BIG difference with the example provided for a keyboard and in time sensitive application it can be very usefull to strip off the unwanted data transmission.

I suppose that being a GENERIC driver it cannot cope with too many little details and it is left to us to find what it wants by trial and error(short of inspecting the source of the driver).
The important thing is that we must keep records of what WORKS to avoid spending days to find why  it is not recognized

g b