Download Gamepad Driver For Windows 10

0 views

Skip to first unread message

Nicodemo Aidara

unread,

Aug 3, 2024, 4:31:10 PM8/3/24

to soundderweiteas

I am trying to find out how I should go about making my own gamepad compatible with windows based games. I have used some time to read up on windows drivers but I feel kind of lost and unsure about how I should solve my problem. What i am asking for is some guidance toward what kind of solution or approach I should take.

So I have made a Arduino based GamePad which communicates with the computer over serialport(usb). From here I assume I need to make a driver which identifies itself as a GamePad(Device driver, Plug and Play driver)? I am not sure if I am done at this point or if I have to be compatible with DirectInput somehow?

Basically, I'd like to create a game controller with the arduino, simple to begin with, just have a few digital buttons. It will plug into a windows (only) PC via usb, and I'd like windows to recognize it as a gamepad (so I can go into control panel, configure it as one, etc). I'm assuming the arduino will need to host some sort of driver to tell windows what it is and what buttons it has? How would I go about writing one of these?

For DS4/DS5 to properly function on your Windows 10/11 PC you are required to install necessary first and third party drivers. Some of which, of course, are optional but will improve DS4windows capabilities. Here we will list and give a description of every driver needed to allow your DualShock 4 and DualSense 5 to work. Launching the DS4 app will also ask to install the drivers.

DS4Windows uses the FakerInput driver to expose system-wide virtual keyboard, relative mouse and absolute mouse. Allows Keyboard + Mouses events/commands to be usable in some situations where the usual way DS4Windows sends those commands (via SendInput) fails. Examples of those situations are elevated processes and games, UAC prompts and anti-cheat systems that block SentInput events. Use of FakerInput is necessary to allow DS4Windows to work with some games with anti-cheat protection like valorant.

HidGuardian is a driver that can hide controllers from the system and allow only chosen processes to detect them. It was previously used by DS4Windows to solve the double input issue, but was made obsolete by the release of its successor, HidHide, a similar driver that works better and is easier to use.

DS4Windows removed support for HidGuardian in version 3.0.8 in favor of HidHide. As such, users who used and still have HidGuardian installed can be in a state where their controllers are hidden and undetectable to Windows and DS4Windows.

I am writting a custom joystick driver. In a sense, what I have is a USB device that uses the standad windows drivers that come with the OS but it does not look like a joystick!
The hardware provides API so I can detect the axis/button values - and would like to make these be passed as joystick input to the OS (ie. make it look like a joystick)

What I would like ask you guys is if my 2 options are sound or should I pursue another option?
Anyone has experience with HID class devices? I looked at the samples in WDM and generating the HID report descriptor and the HID report is a mess - quite few values that you have to know to set and they have to be correct so the hardware looks like an joystick input device.
Any other input, suggestions is very much appreciated. Thanks in advance.

Btw, this will by my first driver. I have read quite a bit in WDF docs on joysticks and HID, looked at briefly at the USB spec and also reading currently Developing Drivers with the Microsoft Windows Driver Foundation. I have very basic understanding of WDM and the OS related aspects.

In DirectX 5.0, DirectInput starts and offers an alternative, COM-based API. Dinput.dll uses VJoyD and, if available, the Human Interface Device (HID) stack, to provide polling services. HID devices are also reported through VJoyD so that applications that use the older API are still able to read the new devices. A driver supplied by the OEM, which can be either a DLL loaded by Dinput.dll, or an extended VJoyD minidriver, handles the force-feedback.

Joystick hardware that is not polled or that has nonstandard polling requirements can implement a minidriver (which must be a VxD) that VJoyD loads when a device of that type is in use. VJoyD also calls the minidriver to access position and button information. Joystick minidrivers are not required to provide any interfaces other than to process the standard SYS_DYNAMIC_DEVICE_INIT and SYS_DYNAMIC_DEVICE_EXIT messages when the device is loaded and unloaded, and to define and register four joystick-specific callbacks.

User mode APIs are not good for your project, makes life way too complicated. What device class is your hardware ? You will be much better off if you can get the endpoint interface for the hw itself, no need for user mode DLLs. As for vjoyd, VXDs died with windows millenium. DirectX is now on v10 or 11, v5 is no longer supported.

Another option I have is - I could write a virtual joystick driver that listens for custom IOCTLs send from user app and translates these to HID reports so it looks like a joystick but I perfer to not to do that if I can read the hardware itself.

You need to look at the descriptors to figure it out. Since you already have an analyzer, you could easily start calling APIs in a test app and then capturing what transactions on the wire result from those API calls. Or ask phidgets for the wire protocol spec

Those APIs, what exactly do you mean by that? The Phidget API shiped by the hardware dudes that are the user mode functions in the Win32 DLL? Or are these WDM APIs to access the hw endpoints? Or something else?

Because you said you are newby in device driver development, I would suggest
you to go with a user mode UMDF device driver. This way we could use the
user mode DLL Phiget provides and you could debug the driver almost as a
normal application. If you already know COM technologies, developing a UMDF
driver would be very easy.

I know you was concerned about performance, but I would not worry about that
for a device as a joystick except if this joystick have an embedded high
definition video or other very special feature. This is even more true if
you want to run the driver on a modern computer with more core than really
needed.

Those APIs, what exactly do you mean by that? The Phidget API shiped by the
hardware dudes that are the user mode functions in the Win32 DLL? Or are
these WDM APIs to access the hw endpoints? Or something else?

Because you said you are newby in device driver development, I would suggest you to go with a user mode UMDF device driver. This way we could use the user mode DLL Phiget provides and you could debug the driver almost as a normal application. If you already know COM technologies, developing a UMDF driver would be very easy.

I know you was concerned about performance, but I would not worry about that for a device as a joystick except if this joystick have an embedded high definition video or other very special feature. This is even more true if you want to run the driver on a modern computer with more core than really needed.

Absolutely true, but learning COM on a diet without learning its common facets (I say common because certain things you should know about COM to use it effectively,- I dont mean by this learning how to write ActiveX, OLE, etc. - just things COM developer should know) is really not going to be much of use for professional developer.

Yes, COM is very lightweigh - not disagreeing with that and it is not complicated if you have been doing it for few years but the learning curve is rather steep when you consider learning simple concepts such as aggregation, and COM specific concepts such as connection points, threading, etc, etc, also it is easy to forget about AddRef, Release in your code and the smart ptrs only help you so much. COM also suffers from DLL hell.

I rather stick to basics and concentrate on my business requirements by using OOP without magic and it does the trick for me, - COM is not worth the price and clearly we can see that right now - .net just like MFC was not worth the price for WIN32.
Both have their places but in common world I got around with using these technologies sparingly.

As much as I love my Joysticks they are too cumbersome for my small retrogaming space - I was wondering if I could use any of my USB gamepads on a Windows 98 PC.. I'm looking at my Logitech F310 at the moment. The download pagefor the device lists drivers for "Windows XP (and older)" but I'm not sure if that can be trusted.. Does anyone use this gamepad on Windows 98?