MTCKC / ProconXInput

A Windows user-mode XInput driver for the Switch Pro Controller.
198 stars 29 forks source link

Strange Windows inputs and accessibility malfunction while driver is talking to Pro Controller #2

Open MTCKC opened 7 years ago

MTCKC commented 7 years ago

See here. Windows starts doing strange things while the driver is talking with the Pro Controller like opening/closing Magnifier repeatedly, random clicking, volume going up or down endlessly, etc.

Blocked completely by hiding the Procon with HidGuardian, but that's more a cure for the symptom than the cause.

ToadKing commented 7 years ago

The issue is the HID descriptor for the Pro Controller does not match the actual endpoint payloads at all, so the actual input ends up doing weird things. There's not much you can do to fix it other than block it from the OS.

MTCKC commented 7 years ago

Do you know if opening it in exclusive mode by passing 0 as the share mode to CreateFile prevents this? That's what I changed for alpha2, but then Win10 users couldn't open any controllers and subsequently I found out about #8. But the one Win7 user I know of reported no problems and was super happy with the release lol. I have a Win8 laptop put away that I'll have to dig out for testing, but that can wait until after the next time I sleep.

ToadKing commented 7 years ago

I wouldn't think so, since the system would always open the controller device first since it's a HID device. Not sure why it works on Windows 7 in the first place. I would have to try it out later.

ToadKing commented 7 years ago

Was able to do some quick tests on my lunch break:

Normally trying to open the device exclusively results in a ERROR_SHARING_VIOLATION error on my Windows 10 PC. However, with my app when you hotplug the controller it is able to open it with exclusive access without the use of HidGuardian. The OS will take over when you close the helper app though and the same weird input issues will start to happen.

MTCKC commented 7 years ago

Ahh, just grab the controller immediately. That's one way to get around it I guess. It looks like you just create a dummy window with the custom WinProcCallback and handle it there. I'm a bit surprised that can grab the handle before System can, but it's a slick workaround.