RawInput or DirectInput used?

[Dr.Venom]

Hi,

I'm using a suzo arcade joystick on my stelladapter and was wondering what input api is used for it. Going through the bootlog I found this:

----------------------------------------------------------
RawInput enumeration..
RAWINPUT: found 16 devices
00010045 keyboard: '\\?\HID#VID_AA55&PID_0101&MI_00#7&1e9aa709&0&0000#{884b96c3-56ef-11d1-bc8c-00a0c91405dd}'
type=81 sub=0 mode=1 fkeys=12 indicators=3 tkeys=110
00010043 keyboard: '\\?\HID#VID_045E&PID_0750&MI_00#8&37c32952&0&0000#{884b96c3-56ef-11d1-bc8c-00a0c91405dd}'
type=81 sub=0 mode=1 fkeys=12 indicators=3 tkeys=264
000B003B mouse: '\\?\HID#VID_046D&PID_C525&MI_00#7&3ae55b64&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}'
id=256 buttons=16 hw=0 rate=0
'HID-muis [046D/C525]' ('\\?\HID#VID_046D&PID_C525&MI_00#7&3ae55b64&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}')
'HID-toetsenbordapparaat [AA55/0101]' ('\\?\HID#VID_AA55&PID_0101&MI_00#7&1e9aa709&0&0000#{884b96c3-56ef-11d1-bc8c-00a0c91405dd}')
RAWINPUT test ok, usage=2
RAWINPUT test ok, usage=6
DirectInput enumeration.. Game controllers..
I=4114DEE0-F5A5-11DF-8007444553540000 P=BEEF04D8-0000-0000-0000504944564944
'Stelladaptor 2600-to-USB Interface' 'Stelladaptor 2600-to-USB Interface' 00010114 [Game controller]
I=21B3BD90-4CA4-11E0-8001444553540000 P=30130E8F-0000-0000-0000504944564944
'USB GamePad' 'USB GamePad' 00010214 [Game controller]
I=21B3BD90-4CA4-11E0-8002444553540000 P=30130E8F-0000-0000-0000504944564944
'USB GamePad' 'USB GamePad' 00010214 [Game controller]
I=9749D2F0-6F41-11E0-8001444553540000 P=88026666-0000-0000-0000504944564944
'TigerGame PS/PS2 Game Controller Adapter' 'TigerGame PS/PS2 Game Controller Adapter' 00010214 [Game controller]
I=2B1FE700-3F66-11E0-8002444553540000 P=0306057E-0000-0000-0000504944564944
'Nintendo RVL-CNT-01' 'Nintendo RVL-CNT-01' 0001021C [Game controller]
Windowsmouse initialization..
Catweasel joymouse initialization..
wintab tablet initialization..
-----------------------------------------------------------------

Does this mean DirectInput API is used for this controller? If so, is there a way I can make it to use RawInput by default? (I'm on W7 64-bit).

Thx for any answer!

[Toni Wilen]

RawInput is only used for keyboards and mice because DirectInput or windows messages don't support multiple separate keyboards or mice.

DirectInput is perfectly fine for joysticks and it has working enumeration support (bit weird but it does work) RawInput does not appear to have any officially documented way to enumerate joysticks features.

[Dr.Venom]

Originally Posted by Toni Wilen

DirectInput is perfectly fine for joysticks and it has working enumeration support (bit weird but it does work) RawInput does not appear to have any officially documented way to enumerate joysticks features.

Unfortunately DirectInput adds overhead/latency to the input polling when compared to RawInput, as mentioned in this article on MSDN:

"DirectInput is a set of API calls that abstracts input devices on the system. Internally, DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly"

Given this my guess is that WinUAE could benefit from having RawInput support for joysticks and joypads, by resulting in lower input latency. I've seen RawInput support for joysticks/gamepads in other applications also, so it should be possible?

With regards to the missing documentation, is it by any chance related to the issue mentioned in this blog?

"The question is – where on Earth do those UsagePage and Usage numbers come from? The MSDN documentation doesn’t explain, but after a bit of digging I found out that they’re part of the USB HID standard (pdf). On page 26 is [...]"

The link to the document doesn't seem to work, but I've found it on USB.org HID page here. (It references to a whole range of devices, including joysticks and gamepads..)

On a sidenote, is there any way currently in WinUAE, that I could manually configure/map my joystick through the game ports or input panel such that it'll make use of RawInput?

EDIT: I noticed that the date of the RAWInput documentation page on MSDN is May 11th, 2011 (here), so maybe it was updated also?

[Toni Wilen]

Originally Posted by Dr.Venom

Unfortunately DirectInput adds overhead/latency to the input polling when compared to RawInput

Maybe, maybe not. From that description it only does USB HID parsing so that applications does not need to parse it manually.

Given this my guess is that WinUAE could benefit from having RawInput support for joysticks and joypads, by resulting in lower input latency. I've

I am still not so sure about latency differences.

Note that DirectInput does not internally use rawinput to read mouse but something else because mouse acceleration for example is different between rawinput and directinput -> Mouse vs joystick is not valid comparison.

seen RawInput support for joysticks/gamepads in other applications also, so it should be possible?

Of course it is possible but I am sure they have only limited support. It is not just about basic joysticks or gamepads.

Manual parsing of HID descriptors shouldn't be part of application. (and required testing to confirm it really works with all kinds of devices..)

Keyboard and mouse rawinput is pre-parsed. You get simple button presses and relative mouse movements. Easy to use.

Unfortunately there is no pre-parsed data available for other devices (including joysticks), you need to parse it manually (you only get low level HID descriptors as described in pdf you linked)

This is the problem. No application should be required to do this.

On a sidenote, is there any way currently in WinUAE, that I could manually configure/map my joystick through the game ports or input panel such that it'll make use of RawInput?

No.

Q: "What about simple support"?

A: Using multiple APIs to read same device can have problems. Biggest problem is that there is no way to know if this DirectInput device is same as this RawInput device. Names can be different etc.. In worst case RawInput device name is "HID compliant <device type>"

A2: Everyone starts asking/requesting to support this and that device. It does not work that way.

Joystick rawinput support isn't programmer (or even user) friendly just yet.
(unless some 3rd party has created some kind of RawInput/HID parser)

[Dr.Venom]

Originally Posted by Toni Wilen

I am still not so sure about latency differences.

I'm also not sure of the differences, for me the proverbial proof of the pudding would be in the eating. That's basicly also why I wanted to try it out..

Q: "What about simple support"?

A: Using multiple APIs to read same device can have problems. Biggest problem is that there is no way to know if this DirectInput device is same as this RawInput device. Names can be different etc.. In worst case RawInput device name is "HID compliant <device type>"

Since the "joystick" device is such an important part of interfacing with an Amiga, and it also being about the only device that really benefits from having the lowest possible latency, would it be a solution to only define a "generic joystick" type (2-axis, max two buttons) for which you could choose either "DirectInput" or "RawInput" as prefered API?

A2: Everyone starts asking/requesting to support this and that device. It does not work that way.

Definately agree, it shouldn't work that way. Probably the only viable and (IMO) most useful way (that is, IF rawinput would lead to lower latency) would be to support say a simple "generic joystick" type, as mentioned above.

In my experience the way other applications do this, is also configure only a generic joystick/gamepad device, then seem to list all available joystick and gamepad HID devices according to their most basic HID classification, enumerating them simply as say JP1, JP2, JP3 (give that say 1 joystick and two gamepads are attached to the system) and having the user push buttons in a config screen to bind the directions and buttons. But I could be wrong here..

[Toni Wilen]

Originally Posted by Dr.Venom

Since the "joystick" device is such an important part of interfacing with an Amiga, and it also being about the only device that really benefits from having the lowest possible latency, would it be a solution to only define a "generic joystick" type (2-axis, max two buttons) for which you could choose either "DirectInput" or "RawInput" as prefered API?

No one has "generic" joystick. Most have d-pad, 1 or 2 analog sticks, buttons. And you want to have at least those available.

I don't care if "others" do it. I only care if there is some good enough example code or ready-made library.

[Dr.Venom]

Originally Posted by Toni Wilen

No one has "generic" joystick. Most have d-pad, 1 or 2 analog sticks, buttons. And you want to have at least those available.

I meant mapping buttons/sticks from those devices to a "generic joystick" layout in the way described. (Given that most Amiga games were developed with only up,down,left,right and firebutton in mind, i.e. the "generic joystick" layout.)

I don't care if "others" do it. I only care if there is some good enough example code or ready-made library.

Is the following code example on the Microsoft Developer Network of any help? It shows how an application can specify raw input from game controllers, both game pads and joysticks.

Example 1
In this sample, an application specifies the raw input from game controllers (both game pads and joysticks) and all devices off the telephony usage page except answering machines.

RAWINPUTDEVICE Rid[4];
Rid[0].usUsagePage = 0x01; 
Rid[0].usUsage = 0x05; 
Rid[0].dwFlags = 0;               // adds game pad
Rid[0].hwndTarget = 0;

Rid[1].usUsagePage = 0x01;  
Rid[1].usUsage = 0x04; 
Rid[1].dwFlags = 0;               // adds joystick
Rid[1].hwndTarget = 0;

Rid[2].usUsagePage = 0x0B;  
Rid[2].usUsage = 0x00; 
Rid[2].dwFlags = RIDEV_PAGEONLY;  //adds devices from telephony page
Rid[2].hwndTarget = 0;

Rid[3].usUsagePage = 0x0B;
Rid[3].usUsage = 0x02;
Rid[3].dwFlags = RIDEV_EXCLUDE;   //excludes answering machines
Rid[3].hwndTarget = 0;
if (RegisterRawInputDevices(Rid, 4, sizeof(Rid[0])) == FALSE) {
     //registration failed. Call GetLastError for the cause of the error.}

The full page is here. Below this example is an example how to read the input from the devices (I guess there's nothing new for you there).

Don't know whether this is "good enough", don't kill me if it's not..

[Toni Wilen]

I do know how to read joysticks using rawinput.

I don't want to know how to parse USB joystick data. It is just low level bit stream (joystick specific) that is explained in descriptors that also needs to be parsed first (as shown in pdf link)

You don't know if this byte or that bit is button on/off value or joystick movement data etc without parsing descriptors.

[Dr.Venom]

Originally Posted by Toni Wilen

I do know how to read joysticks using rawinput.

I don't want to know how to parse USB joystick data. It is just low level bit stream (joystick specific) that is explained in descriptors that also needs to be parsed first (as shown in pdf link)

You don't know if this byte or that bit is button on/off value or joystick movement data etc without parsing descriptors.

OK understood. I'm not giving up yet though . Getting back to your "good enough" example...

On the following page the specific problem you present seems to be explicitly addressed, including explanations and code example linked on the page: Using the Raw Input API to Process Joystick Input . (Hopefully this is a "good enough" example, otherwise I'll quietly go away.. )

Introduction
Microsoft discourages the use of DirectInput for keyboard and mouse input in games, but it is still recommended to process data from a legacy joystick, or other game controller. New applications should use the Raw Input API, i.e., to take advantage of computer mice generating data at 800 DPI or even more. Additionally, Microsoft introduced XInput to allow applications to receive input from the Xbox 360 Controller. Hence, game developers have to cope with up to three different APIs when designing their input system.
In this article, I will show how to use the Raw Input API to process joystick/gamepad data, making at least the use of DirectInput obsolete.

Interesting are the last lines in the further considerations, about the relation to speed. Unfortunately I don't have the knowledge to evaluate or hypothesize what kind of speed improvement could be gained in reality (or not) from the RawInput or other alternatives. Apart from that it at least brings the possibility for lower latency and might be worth exploring further... (being considerate of the fact that in the light of amount of work, priorities etc, you might think differently..)

Further Considerations
I showed in this article that it is possible to use the Raw Input API for joystick input with a little help from the HIDClass driver. I suppose that this API is just a layer on top of the HID user mode library and below DirectInput. In fact, it is also possible to bypass the Raw Input API and do all HID communication by using only the HID user library. Just take a look at the HClient sample of the WDK. It does the same things I do to interpret HID input reports without using Raw Input. You can't get any lower-level interface when developing your game input system as the HID user mode library is the only interface that separates your application from kernel mode, although I doubt that using the HID user library directly will gain much speed.

[Toni Wilen]

Much better. But..

Names/labels are still a problem. Neither example says anything about names.

How to get name of the device? ("USB joystick vendorid,productid" isn't what I would call a name..)

How to get buttons', sticks', etc label?

[Dr.Venom]

Originally Posted by Toni Wilen

Much better. But..

Names/labels are still a problem. Neither example says anything about names.

How to get name of the device? ("USB joystick vendorid,productid" isn't what I would call a name..)

How to get buttons', sticks', etc label?

Not fully sure, but these Intel examples might be helpfull in getting the device names: DisplayHID and DisplayUSB. They are part of an Intel book "USB Design by Example" (and more looking like the "USB bible" ). The examples need a few libraries, which can be downloaded from the Intel page here. Hope this works for getting the proper names from devices..

[Toni Wilen]

Intel examples look too low level (uses IOCTL) but I found out how to enumerate and get name strings from HID devices. Everything appears to be in HID.DLL.

Still not sure if HID device features (buttons etc..) have names or if they are always generated by HID or manufacturer specific drivers..

EDIT: It seems DirectInput names are generated. (http://msdn.microsoft.com/en-us/wind...dware/gg487464)

[Dr.Venom]

Originally Posted by Toni Wilen

Intel examples look too low level (uses IOCTL) but I found out how to enumerate and get name strings from HID devices. Everything appears to be in HID.DLL.

Cool

Still not sure if HID device features (buttons etc..) have names or if they are always generated by HID or manufacturer specific drivers..

EDIT: It seems DirectInput names are generated. (http://msdn.microsoft.com/en-us/wind...dware/gg487464)

OK, I couldn't find documentation myself on it, so hopefully that's it..

Are you currently looking at the possibility of using RawInput, or bypassing the Raw Input API and do all HID communication by using only the HID user library (as referred to in that blog, being the lowest level interface for game-input)?

[Toni Wilen]

Enumeration seems to work. Enumeration is currently done using rawinput API (because code was already there), properties are read using hid.dll (because it is more flexible and code wasn't there yet )

It will use DirectInput-like usage mapping but not 100% exactly (by design, not a bug)

Haven't decided yet how to actually read HID reports.

btw, there may be one "real" advantage in using "Direct HID Input": It should be possible to support HID devices that don't have Windows drivers (only detected as generic USB HID device), at least as long as data format is known.

EDIT:

Lowest level method (ReadFile() directly from device handle) does not appear to work very well, single call to get one HID report takes multiple milliseconds. Reason unknown. RawInput method appears works fine.

[Dr.Venom]

Originally Posted by Toni Wilen

Enumeration seems to work. Enumeration is currently done using rawinput API (because code was already there), properties are read using hid.dll (because it is more flexible and code wasn't there yet )

This is good news

It will use DirectInput-like usage mapping but not 100% exactly (by design, not a bug)

OK, notice taken..

btw, there may be one "real" advantage in using "Direct HID Input": It should be possible to support HID devices that don't have Windows drivers (only detected as generic USB HID device), at least as long as data format is known.

That could be a useful advantage, at least if I understand it correctly. Do you mean that for example something like the in Windows notoriously unsupported Sony PS3 Joypad could be used in WinUAE? (Would make for a great CD32 pad!)

EDIT:

Lowest level method (ReadFile() directly from device handle) does not appear to work very well, single call to get one HID report takes multiple milliseconds. Reason unknown. RawInput method appears works fine.

OK that's unfortunate. It would have definitely been nice to have it work on the lowest possible level. Nonetheless, very cool that you seem to have RawInput fully up and running

[Toni Wilen]

Originally Posted by Dr.Venom

Sony PS3 Joypad

AFAIK PS3 pad is buggy (from HID standard point of view), it can never work under Windows without device driver because to "enable" it (so that it actually does anything, strange gamepad feature..), it needs to receive HID USB report with invalid ID (ID that is not included in pad's USB descriptor)

Windows USB stack simply won't accept invalid report IDs.

[Dr.Venom]

Originally Posted by Toni Wilen

AFAIK PS3 pad is buggy (from HID standard point of view), it can never work under Windows without device driver because to "enable" it (so that it actually does anything, strange gamepad feature..), it needs to receive HID USB report with invalid ID (ID that is not included in pad's USB descriptor)

Windows USB stack simply won't accept invalid report IDs.

Ah, I already suspected something like that would be the case. Thanks for clarifying though...

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip

Quick HID RawInput joystick support test version. DirectInput is disabled in this version.

Tested using XBox360 pad, Competition Pro USB and PS2 and GameCube pads (using USB adapters). "Appears to work". Maybe.

[Dr.Venom]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae.zip

Quick HID RawInput joystick support test version. DirectInput is disabled in this version.

Tested using XBox360 pad, Competition Pro USB and PS2 and GameCube pads (using USB adapters). "Appears to work". Maybe.

First impression is that it works really well . More testing to do later...

[Toni Wilen]

Originally Posted by Dr.Venom

First impression is that it works really well . More testing to do later...

It must be perfect then

Everyone else can also comment and test this if interested. Just include name of game control device and say if it works (and if not, if it works in 2.3.2 in DirectInput mode). Note that you need to re-create your custom input configuration (if you have one) because RawInput device is not same device as "old" DirectInput device (even if names are exactly same).

EDIT: this will be part of next beta but most likely in final version DirectInput is still the default, RawInput joystick requires command line parameter.