JInput and Custom USB Devices

Engines, Libraries and Tools JInput
#1

Hi everyone!

Pointless Background

I’ve been using JOGL for the past several months and just love it. I’ve just started a new project where I’m building some custom hardware that will be USB (HID) compatible that I want to use to control interaction in my application.

This is the first time I’ve attempted to build custom hardware/drivers/etc so please forgive me if I’m asking the obvious here. There’s a venerable RAINFOREST of USB documentation that I’ve been trying to wade through and make sense of. I’m still very much in the research and design stage as far as software goes and want to make sure that I understand all of the options available to me before I waste several weeks (months?) writing a driver.

Start Reading Here
My question for you guys: does the Collection/Axis structure of a device directly correspond to the HID descriptor for a device?

For example, I wrote a quick recursive app that prints out the structure of my Microsoft USB Optical mouse. I found the following:

Controller: Mouse Mouse Axises [0] Controller: Mouse Mouse ball Axises [3] X-axis (x) Y-axis (y) Wheel (slider) Controller: Mouse Mouse buttons Axises [3] Button 0 (left) Button 1 (right) Button 2 (middle)

And the typical mouse HID (abbreviated) looks like this:
Usage_Page(Generic Desktop) Usage (Mouse) Collection(Application) Usage(Pointer) Collection(Physical) Usage_Page(Button) // then button 1, 2, 3 ... Usage_Page(Generic Desktop) // then x, y ... End Collection End Collection

So, let’s say that I added another Usage_Page under the “Physical Collection” that reported arbitrary values A, B, and C, would I see those as another Controller with three Axes (A, B, C) under the high level mouse controller?

Translation:
Controller: Mouse Mouse Axises [0] Controller: Mouse Mouse ball Axises [3] X-axis (x) Y-axis (y) Wheel (slider) Controller: Mouse Mouse buttons Axises [3] Button 0 (left) Button 1 (right) Button 2 (middle) Controller: Mouse Arbitrary values Axises [3] A (A) B (B) C (C)

Hope this isn’t too basic… just want to make sure that I understand what JInput is doing. If it will recognize my new device as I’ve specified above (or close to it if I got the controller/axis heirarchy wrong) then that means I just need to worry about the embedded software and don’t need to write a host driver… I can just import JInput into my application and keep coding!

Thanks for your help… you guys are doing great work.

#2

Yes that is the way it is supposed to work. It seems the USB device vendors are very inconsistent though. Many of the standard HID usage codes are rarely used, even though they would fit the function of the controller exactly. For example HID defines usages for a hat switch (thumb operated directional control on the end of a joystick), but you may find that a controller with a hat switch treats it as four unrelated buttons or maybe a single axis with 9 states. Basically the vendors ruined HID so that you can pretty much ignore the standardization that was attempted and you have to write custom tables and stuff for each controller… failing back on the standard stuff for things you don’t recognize and hope for the best… at least that’s how it appeared to me when I was last playing with the MAc plugin.

#3

Hi
The other thing to note is that the mouse is split up into seperate controllers in JInput, that is not based on the HID info. I’m not sure it would show up as a sub controller. Atleast, thats how windows and linux plugins do it.

Endolf

#4

[quote]The other thing to note is that the mouse is split up into seperate controllers in JInput, that is not based on the HID info. I’m not sure it would show up as a sub controller. Atleast, thats how windows and linux plugins do it.
[/quote]
Just look a peak at the source code. In theory if a custom mouse doesn’t register the additional axies/controllers then it seems like it’d be a fairly simple matter of just mucking around with the DirectMouse implementation for Windows to get additional controllers recognized. (Or am I mistaken?)

Is the reason that the mouse self enumerates the Ball and Button controllers due to the fact that many different manufactuers have followed various HID implementations and thus the only way to have a consistent mouse object is to hard code in those controllers?

#5

Hi
My understanding for what it was originally done, is because the mouse ball is two axis, and grouping them together seems to make sense, ideally a coolie hat on a joystick would be one object too, a subcontroller of the joystick maybe, but for now, the mouse is the only one that actually does it.

Endolf