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

I updated to 3.7 but my Logitech is still not detected. I also have an Xbox 360 gamepad that has always worked fine though. Any ideas?

What platform are you using? The cross platform project type supports more gamepads than windows. Windows only supports XInput devices.

1 Like

Ah, that’s the problem then. I’m using Windows. I will try converting it to the cross platform project. Last time I did my game crashed and I couldn’t make it work after the menu, but I’ll give it another try soon. Thanks for your help.

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.

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.


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.