Because of the way HID reports works, if two messages from any two or more of the three profiles (the mouse, keyboard, and gamepad "slots" reported to the PC) are sent, one will override all the rest - this currently leads to dropped inputs, or buttons getting held stuck.
With this commit, when a report of one type is used, we now record whatever profile was last being reported. If any of the three types of reports are triggered, and differs from the last profile that was sent, we intentionally wait 1ms before reporting on the new channel.
Paired with 1ms polling, this seems to resolve any possibility of dropouts (really, how many people are pressing more than three buttons at once?) - though this is just a band-aid solution for the moment. Perhaps autoreport should be disabled and we just handle that separately after polling?
Because of the way HID reports works, if two messages from any two or more of the three profiles (the mouse, keyboard, and gamepad "slots" reported to the PC) are sent, one will override all the rest - this currently leads to dropped inputs, or buttons getting held stuck.
With this commit, when a report of one type is used, we now record whatever profile was last being reported. If any of the three types of reports are triggered, and differs from the last profile that was sent, we intentionally wait 1ms before reporting on the new channel.
Paired with 1ms polling, this seems to resolve any possibility of dropouts (really, how many people are pressing more than three buttons at once?) - though this is just a band-aid solution for the moment. Perhaps autoreport should be disabled and we just handle that separately after polling?