Two HID devices with different names on one AVR

[Guest]

Hi.

I'm trying to use two HID game controllers with one AVR. It's not too difficult to do, just use two separate HID applications in the controller, but the problem is they both end up with the same name in Windows.

I really want one to be "Controller Player 1" and the other "Controller Player 2" or something like that. Is there a way of doing it?

[Guest]

This should work, it is not necessary to implement 2 seperate HID implementations on one controller.

Example from the HID usage Tables p. 136

This example shows how to implement multiple instances of a set of controls by defining a device with two
pointers, each with X and Y axes. An application looking for Pointer usages would find two of each type
enumerated.

Code: Select all

UsagePage(Generic Desktop),
Usage(Pointer), ; Pointer
Collection(Logical),
UsagePage(Ordinal),
Usage(Instance 1), ; Pointer 1
Collection(Physical),
UsagePage(Generic Desktop),
Usage(X-axis),
Usage(Y-axis),
Collection End,
UsagePage(Ordinal),
Usage(Instance 2), ; Pointer 2
Collection(Physical),
UsagePage(Generic Desktop),
Usage(X-axis),
Usage(Y-axis),
Collection End,
Collection End,

Regards...

[Guest]

Thanks, that's basically what I'm doing, except that I use two separate applications which each has it's own set of x/y axis and buttons.

However, when you open the "Game Controllers" applet in the Windows Control Panel, you see two identically named controllers. That is confusing for the user. What I want to do is have each controller named differently.

It's not the end of the world as MAME and most other good software at least tells you which controller a button or axis is on.

[henni]

However, when you open the "Game Controllers" applet in the Windows Control Panel, you see two identically named controllers.

IMHO, the strings come from .INF file, [Strings] section. But Windows uses its own .INF files for HID devices, so you probably have no chance. But you can install a custom .INF file for your device. A two-interface HID device and a custom .INF file may solve your problem. Of course, this approach has the disadvantage that you have to supply an .INF file and a note what users should do with it.

There are a couple of SetupDiXxx named functions; maybe you can write a small .EXE file that renames your device(s) accordingly. But I don't know whether SetupDiXxx functions allow this. Or you may patch the registry.

I see no way to solve this problem with ATmega firmware only, you must supply some Windows code, unluckily.

If you want to do a very risky job, implement a virtual USB hub (!!) with two hard-connected downstream ports inside ATmega firmware, and pray to Microsoft that their usb.sys will support low-speed hubs too (somehow).

[Grendel]

In my experience Windows uses the product string from the device descriptor as the name for an otherwise unknown device. Since there's only one device descriptor it's the same name for both entries.

[Guest]

Thanks for the ideas. I think there may be a solution, but not an easy one.

henni, the custom INF idea is interesting but probably won't work because there is only one HID descriptor. However, that did give me an idea.

Grendel, you are correct. Herein lies the solution.

I think the only way to do it would be to have more than one endpoint. Then send the same HID descriptor for both, but a different PID and description string. It's going to require some hacking but should be doable.

This seems to be the official way to do composite devices which cannot simply use multiple reports.

[christian]

String descriptors and the device descriptor (which contains the PID) are unique for the device, not a particular endpoint. They are always queried through endpoint 0. It won't help you to implement a second endpoint.

Even a composite device has only one name. It's only one device (although composite) after all.