Minor oversight on the 360 wireless mapping was the lack of the guide button being brought forward to the user.
As an aside I notice you check the connect/disconnect packet for the status of the device, but you only call tuh_xinput_report_received_cb when there is new_pad_data. That leaves the caller oblivious to know when a pad has been disconnected.
Should we be calling tuh_xinput_report_received_cb on a disconnect and expect it to check connected to preform operations when the pad was disconnected/reconnected?
Or how else can we let the host code know that a 360 wireless gamepad has been disconnected?
Minor oversight on the 360 wireless mapping was the lack of the guide button being brought forward to the user.
As an aside I notice you check the connect/disconnect packet for the status of the device, but you only call
tuh_xinput_report_received_cb
when there isnew_pad_data
. That leaves the caller oblivious to know when a pad has been disconnected.Should we be calling
tuh_xinput_report_received_cb
on a disconnect and expect it to checkconnected
to preform operations when the pad was disconnected/reconnected?Or how else can we let the host code know that a 360 wireless gamepad has been disconnected?