How to implement two interface (composite device)?

[rinku]

Hi,
I am trying to implement two different interface in a single device, Not using ReportID, i.e. there should be two different interface descriptor each containing HID and endpoint descriptor, each HID descriptor has its Report descriptor(say one for keyboard with boot capabilities and the other is mouse).

I know that I have to look at wIndex value (though not sure which byte, 0-low or 1-high? ) to send the appropriate HID Report descriptor. I tried both the low and high byte of wIndex but it doesn't work, the device successfully reports up to configuration descriptor but fails in HID Report request.

I also noticed that when the HID descriptor is requested (wValue.bytes[1]==0x21), the driver(V-USB) replies form the point usbDescriptorConfiguration + 18, since there is two HID descriptor lies inline in my configuration descriptor, I am checking the wIndex to reply for the second HID descriptor from usbDescriptorConfiguration + 43, IS THIS RIGHT?

When HID Report descriptor is requested (wValue.bytes[1]==0x22), I am checking the wIndex to reply for the second HID Report descriptor, IS THIS also RIGHT?

Please Help me...

[ulao]

rinku, if you could are you looking to do something like this?

viewtopic.php?f=8&t=2854

I dont have a solution but would really like to know the same, if that what you are asking.

[Grendel]

I am trying to implement two different interface in a single device, Not using ReportID, i.e. there should be two different interface descriptor each containing HID and endpoint descriptor, each HID descriptor has its Report descriptor(say one for keyboard with boot capabilities and the other is mouse).

The 2nd interface will need its own endpoint IIRC. You could enable and use INT IN EP3 for that (see usbconfig.h). An example for the descriptors can be found here (USB Keyboard with Debug Channel, Version 1.0). Even though this is for a AT90USB162, the descriptors are pretty much universal.

I know that I have to look at wIndex value (though not sure which byte, 0-low or 1-high? ) to send the appropriate HID Report descriptor. I tried both the low and high byte of wIndex but it doesn't work, the device successfully reports up to configuration descriptor but fails in HID Report request.

wIndex is a 16 bit value, you should get away w/ looking at the LSB tho since the interface no. is < 256. Note that this will only work for control transfers, for "normal" operation each report needs to be send via its own INT EP.

I also noticed that when the HID descriptor is requested (wValue.bytes[1]==0x21), the driver(V-USB) replies form the point usbDescriptorConfiguration + 18, since there is two HID descriptor lies inline in my configuration descriptor, I am checking the wIndex to reply for the second HID descriptor from usbDescriptorConfiguration + 43, IS THIS RIGHT?

Yes. wIndex contains the interface number during a HID Get_Descriptor request (see HID 1.11, chap. 7.1.1)

When HID Report descriptor is requested (wValue.bytes[1]==0x22), I am checking the wIndex to reply for the second HID Report descriptor, IS THIS also RIGHT?

Yes, same as above (chap 7.1 & 7.1.1)

[Guest]

rinku, if you could are you looking to do something like this?

viewtopic.php?f=8&t=2854

I dont have a solution but would really like to know the same, if that what you are asking.

Thank you for your reply.

Though I didn't exactly understood your requirement, but I think its more or less the same. You can look at https://www.usb.org/phpbb/viewtopic.php?t=14027 , it might be some help, and below Grendel provided some useful information. If there anything else feel free to ask.

[Guest]

Grendel, thank you very very much for your help!

you see, I know I have to use separate endpoints for each interface, but was not sure about things I was doing, thank you again for your assistance.

The firmware is now working (though with little bit problem), it turns out that the problem was "Windows", once it got inappropriate report (during my test), it won't reassign the drivers unless I reinstall the device!(uninstall the device from device manager and search for new devices).

I also have some confusion about the IdleRate, Can you please clarify the use of it?

Thank you..

[Grendel]

The idle rate is fairly well documented in HID 1.11, chap. 7.2.4. In general your device should only send a report if values change (eg. key pressed or released) or if idle_rate * 4ms elapsed (ie. resend last report. Applies only if idle_rate is not infiniy.) Sending a report resets the idle timer. I added some idle rate handling to the 3DP-Vert project as a proof-of-concept; the joystick is way to sensitive for that to have any effect, but the experimental keyboard code makes use of it.

[ulao]

Yes that is what I'm after the link you gave me is missing the file "Kbd_mouse.hid" as it stated would be in the zip. Going to read through this info but any example links would be great! Grendel, thx for the info, at least I know its possible now.

[rinku]

The idle rate is fairly well documented in HID 1.11, chap. 7.2.4. In general your device should only send a report if values change (eg. key pressed or released) or if idle_rate * 4ms elapsed (ie. resend last report. Applies only if idle_rate is not infiniy.) Sending a report resets the idle timer. I added some idle rate handling to the 3DP-Vert project as a proof-of-concept; the joystick is way to sensitive for that to have any effect, but the experimental keyboard code makes use of it.

Grendel,
Thank you for your kind reply and explanation, but I did not understand why and when the host sends a SET_IDLE request? why does it apply for keyboard and not for mouse?

[Grendel]

[..] but I did not understand why and when the host sends a SET_IDLE request? why does it apply for keyboard and not for mouse?

The Set/Get idle requests are general HID class specific requests but not mandatory. Ie. you can chose not to implement them. The general idea of idle is to cut down the USB traffic to only what is necessary. The host may send them at any time, for joysticks and mice most hosts typically only set the idle rate to infinity during enumeration once. The idle rate for keyboards is typically also changed when the delay-before-first-repeat rate is changed.

The recommended default idle rate (rate when the device is initialized) is 500 milliseconds for keyboards (delay before first repeat rate) and infinity for joysticks and mice.

[rinku]

Grendel, Thanks again!
I think now I get the Idea of IdleRate!, as far as I understood, the host sends the SET_IDLE request to notify the device that it can report "The key is still pressed" repetitively after some time delay for each report, which will effectively reduce unnecessary transmission.

[Spider]

rinku, can you show you code?