ViGEm Roadmap-thingy


once again I’d like to inform you what’s going on in the development dungeon. Whacking together a quick list of stuff I wanna work on the next couple days/weeks regarding the ViGEm framework.

Redesign user-mode library

Currently ViGEmUM.dll is responsible for interaction with the bus driver and providing developers with access to the emulation sub-system. The library has some serious flaws due to rushed development and bad test coverage. Since fixing most of the stuff I’m unsatisfied with would inevitably break both API and ABI backwards-compatibility I decided to start again from scratch and make it a static library instead since most of my users compile it like that anyways. I’m also investigating some tools to provide decent API documentation, one of the is Read the Docs. Do keep in mind that I’ve never designed an API before this project so I’m learning as I code along 🙃

Redesign .NET stuff

There’s no beating around the bush; my .NET-wrappers are (still) in a pitiful state, mainly caused by their dependency to the native user-mode library which introduces issues with CPU architectures and compatibility between updates. My approach is to port the user-mode functionality entirely to the managed .NET world and implement it a 100% in C# so only one nice and clean assembly is necessary for communication with the bus driver. This would also simplify the creation of a NuGet package.

Blocking device attachment

Actions like adding another virtual device to the bus are inherently asynchronous because once the bus device (FDO) is instructed to report another of its children (PDO) to the system, it’s the Windows PNP-Managers responsibility to bring that new child to live so it becomes available to the system (“boot-up”). This usually takes around 300 to 700 milliseconds. Within this time frame it’s not possible to interact with the PDO through the bus drivers control mechanisms. I never had a problem with this fact but feedback from the community suggests it would be better to have this plugin procedure be a blocking action until the virtual device is truly ready for interaction. I agree. But you need to understand that at the driver level it’s not as easy as it seems because once the bus driver has announced a new child it no more has responsibility or control over it’s boot-up progress. I did some research and found a way of interaction between the FDO and the PDO which could satisfy this need. I’ll keep you updated on this topic.

Generic HID-Device emulation

I receive more and more feature requests to support a dynamic multi-purpose DirectInput-compatible joystick HID device like vJoy can. While I certainly sympathize with the idea behind it due to its complexity I’d rank this a bit further down the list of priorities for now. Time will tell, be assured 😄

Well, that’s it for now,