Controllers Not Reusing Ports

[DanilaPenzin]

Device: Lenovo TB3-710I
Controller: Ritmix GP-030BTN
Device config name: Amazon Fire Game Controller.cfg
Version Retroarch Git: 81075aa

When I am using this controller via Bluetooth to the Lenovo, if it disconnects for any reason while RetroArch is running then reconnects, it's added as a second port instead of reconnecting to port 1. This leaves RetroArch in an unusable state requiring a force close and relaunch since the controller in port 1 is dead and no way to reconnect it.

[Arjan219]

Device: Linux Mint 20 (Ulyana)
Controller: Wireless XBox 360 controller
RetroArch: v1.7.3 b2ceb50
Compiler: GCC (9.2.1) 64-bitBuilt: Feb 11 2020

This happens for me too.
I can navigate the main menu fine, but the moment i load content the controller reconnects from port #0 to port #1, making it unusable.
A workaround i found is to remove the controller's battery, put it back in, and turn it back on: RetroArch then correctly connects it to port #0. The problem then no longer occurs until i load some other content.

[markwkidd]

Please post logs showing the entire period including when the controller binds to the next port. This is a guide to logs: https://docs.libretro.com/guides/generating-retroarch-logs/

[markwkidd]

This may be the same issue: #9296

[ComradeEcho]

Hello, I'm having the same issue on my system as well.

[INFO] CPU Model Name: Apple M1 (Mac Mini)
[INFO] Capabilities: NEON VFPv3 VFPv4
[INFO] Built: Jul 19 2021
[INFO] Version: 1.9.6
[INFO] Git: GIT_VERSION
Controller: Microsoft Wireless Controller (xbox series x) - Bluetooth

Unfortunately while my logs are set to Debug, they still don't seem verbose enough to get much information out of them.

What I do notice however is that this appears to be caused by the application often not detecting that a controller has been disconnected, so when the controller reconnects, RetroArch appears to think you just plugged in an additional controller.

macOS does show the controller as "Not Connected" in the system bluetooth settings after the controller has been shut off - so it doesn't appear to be an issue with the Operating System thinking the controller is still connected.

retroarch__2021_07_25__17_42_34.log

[ComradeEcho]

#11294

[ComradeEcho]

I think I have mostly fixed this issue, however it has resulted in another major issue being exposed in the pad_matching functionality.
The pad matching code appears to be overwriting the structure that holds the controller's reference handle.
For example in the code passes along a iohidmanager_hid_adapter to void* data in hidpad_ps4_init() but it gets dereferenced as a pad_controller structure resulting in data corruption.

I don't know if the wrong data is getting passed into this function, or if the function is doing the wrong thing with that data.

RetroArch/input/connect/connect_ps4.c

Lines 130 to 147 in 49632bb

	static void* hidpad_ps4_init(void *data, uint32_t slot, hid_driver_t *driver)
	{
	#if 0
	uint8_t magic_data[0x25];
	#endif
	struct pad_connection* connection = (struct pad_connection*)data;
	struct hidpad_ps4_data* device = (struct hidpad_ps4_data*)
	calloc(1, sizeof(struct hidpad_ps4_data));
	if (!device)
	goto error;
	if (!connection)
	goto error;
	device->connection = connection;
	device->slot = slot;
	device->driver = driver;

Here's the work I have done to get the port-reusing mostly fixed.. but I really need help figuring out these issues within the pad-matching to continue this.

This commit has the port-reusing functional, but the pad-matching functionality is disabled due to the bug in it. There's information in the comment on how to re-enable the pad-matching if you want to take a look

ComradeEcho@7b87ab6

[markwkidd]

I think it would be useful to have your patch as a PR. That way folks can easily post code review and other comments directly with your code. Would you be willing to make a PR?

[inactive123]

@ComradeEcho tells me this is fixed now, closing.