for help or hinderence here is my suggestion

[GoogleCodeExporter]

I haven't been able to look through EVERYTHING related to this project so I may 
be a bit late to say this but I believe you should be looking more into 
chatpad-super-driver (https://code.google.com/p/chatpad-super-driver/). It is a 
fairly solid implementation of a chatpad driver including remapping and I 
believe it either works alongside the native driver or reimplements it (xinput 
and force feedback worked). It had it's issues (wired only, unsigned driver, 
driver not "letting go" of the device) but depending on how deep you want to go 
you might learn something from it. This probably isn't anything new to you 
(especially since it's the only other known working driver) but there's my 2 
cents.

Original issue reported on code.google.com by crimsons...@gmail.com on 10 Oct 2014 at 12:40

[GoogleCodeExporter]

Thank you for the recommendation. We'll have to take a look at that.

Original comment by kytechne...@gmail.com on 14 Mar 2015 at 12:49

[GoogleCodeExporter]

Unfortunately the chatpad super driver is like,comparing Apples to...hmm...very 
different Apples...?

This project was started based on that one...on of,those issue is to get 
wireless working.,if,you look through that thread you'll,find a while slew of 
information.

The bottom line, the architecture they use to allow for native xinput 
functionality will not work with the architecture to get wireless working. They 
use a filter driver that has the ability to sit on top of the normal USB driver 
for the controller and as such they do not have to implement any controller 
functionally, only chatpad functionality.

In the wireless case, the device attached to your computer isn't the controller 
it's the receiver dongle. This is the primary difference because in order to 
intercept the chatpad data we have to intercept it all. We cannot sit on top of 
the existing device. Therefore this architecture requires us to reimplement the 
controller functionality. For XInput to work, vJoy would have to support it as 
we use that library to simulate the controller.

Honestly the best solution is to get Microsoft to update their wireless driver 
to process the chatpad information...as we've seen here it's like a few hundred 
lines of code. 8(

Original comment by ksbarnes@skyag.net on 9 Apr 2015 at 6:06

[GoogleCodeExporter]

microsoft is not gonna do anything. that's why we have you instead :)

there has to be a way of keeping xinput and the controller intact,
so we can have a usable device which doesn't lose any type of functionality and 
can be connected/disconnected reasonably without restarting the entire system.

as-is, the driver is useless, it would be strange to do all this work and just 
leave it like this.

you are so close,
all we need is no loss of native functionality so the controller fully works 
with xinput and xpadder and the ability to connect and disconnect the device 
without restarting the PC or manually unplugging the receiver

there are several posts which you say this is possible
please don't give up, we need you man!!

Original comment by Andrew.R...@gmail.com on 11 Apr 2015 at 6:33