Can you finally use generic USB gamepads in the latest versions of Monogame?

Which Logitech pad? Most of them have a switch on the back to go into XInput mode.

1 Like

I just checked and it says “Logitech Dual Action”
I couldn’t find a switch though… :pensive:

You have the last Logitech pad that didn’t have XInput support. The Dual-Action was rebranded as the F310 when they added XInput. Edit: that thing has to be old.

1 Like

How lucky I am! :slight_smile: Does it mean that all the current models have XInput support?

And yes… it’s old, but I forgot it was that much…

Edit: I checked and XInput seems to be the standard nowadays. I don’t play much on my PC and had not idea.

Yeah, they all will. They should say on the box though. PC gamers don’t tend to chew through pads though so it’s not surprising you have such an old pad.

Honestly though, input is probably MonoGame’s weakest link. There’s probably a more robust library out there you could use just for input that would cover your controller. Even if the justification is just budgetary, robust is robust.

You got a good point there. However since I already had it implemented I will leave as it is for now. I have an Xbox 360 controller that works fine and I thought it would work also for this other Logitech gamepad I had collecting dust. I may get another cheap one to do some more testing before releasing it. Thanks for your help.

I have written my own HID handlers for input devices, but they currently require hand coding to map the data packets into useable values.

The data is compressed into a bit stream. So a button is a single bit in the data packet.

There is a “standard” that you can use to automatically map bit fields into values, but it’s not well documented and a pain in the proverbial to work with. I will have to write a handler for generic devices though. It’s on my todo list.

I will do my best to push it up the list and release it as an extension for Monogame so you will have a simple library to support all input devices on Windows,

If it becomes important to you, send me a message and nag me to work on it.

1 Like

Thanks for that. At this moment I think I’m ok with what I got so far, but I’ll let you know in the future if I need it.
In any case, it would be great if you can post that as an extension for everybody to use.

Sorry to start this thread up again, but I need help

I went back to the HID code and added some scanning to see how hard it would be to have a generic USB system.
The most important thing I need to sort out is the mapping of a report data packet into values the game can use.

The code I have written looks perfect.

You can see the device has one set of buttons and 6 sets of values.

Reading those values, I can see that they all match to what I expect. They all are the correct size. All the data indices match.

Job done? Well no.

When I look at the actual data I get from the device, between the buttons and Rx I have 7 bits of data that are not used.

I have gone through everything I can find and cannot see anything in the data packets that tells you why.

So I am guessing that 8 bit values have been forced onto a byte boundary. That will fit the data perfectly… but WHY!!!

It’s a fu&*^&%ing bit stream…

I don’y have anymore devices I can look at to give me more data.

Has anyone got a clue?

Well don’t have anymore time to work on it.

I have published a test app and library with a MonoGame demo for you all to try.



Works with all the devices I have.

Just select a HID device from the list and see what happens.

Please tell me if any devices you have don’t work.

http://southseagamesgurus.co.uk/downloads.html

Wouldn’t happen to round out to one of the USB packet size limits would it (8, 32, 64 and 512 bytes)?

The USB standard doesn’t require it, but I wouldn’t be surprised if most pad to whatever their target packet size is.

I’m on a laptop (Alienware 15 R3) and almost everything I choose in this tool crashes it. Of note is that the HID Keyboard Device and my HID-compliant Game Controller (which is a Nintendo Gamecube controller connected via a Raphnet adapter) throws an IOException in BitStream line 416. Here’s the stack trace:

   at MonoGameDemo.InputManagement.BitStream.BitStream.ReadBit() in C:\Users\Redacted\Desktop\HidLibrary-master\HidLibrary-master\src\MonoGameDemo\InputManagement\BitStream\BitStream.cs:line 416
   at MonoGameDemo.InputManagement.HIDDeviceHandler.ReadProcess(HidReport report) in C:\Users\Redacted\Desktop\HidLibrary-master\HidLibrary-master\src\MonoGameDemo\InputManagement\HIDDeviceHandler.cs:line 110
   at HidLibrary.HidDevice.EndReadReport(IAsyncResult ar) in C:\Users\Redacted\Desktop\HidLibrary-master\HidLibrary-master\src\HidLibrary\HidDevice.cs:line 513
   at System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessage msg)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
   at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Hi Kimimaru,

In the package I included some test code you can use to give me more data. Run the test harness, select the device and press the scan button.

A screen shot of that will give me a lot of data to look at.

Most likely, it is the code I use to handle the un-allocated bits goes wrong for that device so the bitstream is trying to read beyond the length of the data packet.

Cheers
Paul

After rebuilding the projects and testing, the controller no longer throws an exception until I press a button. However, this occurs only in the MonoGame Demo project. In addition, the keyboard still throws an exception when I click on it. The test harness has no issues with the keyboard nor the controller.

Could you use the scan button on the test harness so I can see what is going on please.

Here’s the output of the test harness when scanning my keyboard.

Okay I have found the same problem here.

It is reporting it has 263 buttons, but the report packet is only 8 bytes long (64 bits).

I am looking into it.

I don’t know what is going on.

263 Buttons of which 153 are aliases for other buttons.

Which leaves 110 real buttons.

This matches what is in the USB capabilities (NumberInputDataIndices = 110)

Yet the report package is only 8 bytes long…

WTF!

Ignore this, I just think it’s interesting:
https://www.digikey.com/eewiki/pages/viewpage.action?pageId=28278929

This direction of working through it sounds interesting…

But 110 makes sense to me, however, 263, are there that many extra keys? numpad perhaps?

Code wise, I think Bitwise operations come into play there… ICBW

Yes . I miss the good old days of simple interfaces written by coders.

HID looks to me like a “Standard” written by hardware manufacturers to obfuscate the operation of their devices to make it harder for third parties to write their own drivers.

Then windows comes along and makes it worse.

The HID spec includes a read report descriptor which has everything we need to be able to support HID. Windows blocks you getting it.

Instead you get a pre-parsed data packet, in a format that is not public, which you have to pass to other functions.

It really feels like we are not supposed to support generic USB devices.

The most annoying thing is looking at the device list. I have only one keyboard connected to my PC. I only have one set of hands , so I think one keyboard is appropriate. Yet the HID scanner says I have four.

Two of which show valid data, but don’t work. Two of which have bollocks data. 110 buttons in 8 bytes.

I am thinking keyboards must have another layer of rubbish attached to them somehow.