libretro: Don't plug joypads by default

[Kekun]

This avoid assuming what the frontend will plug in anyway.

Similar to https://github.com/libretro/bsnes-libretro/pull/56

[inactive123]

Just to confirm, the gamepad will still work by default, right?

[hizzlekizzle]

That's going to default to no input, isn't it? If so, that doesn't seem like a good idea to me, as I foresee a lot of "not responding to input" reports.

[andres-asm]

I guess what it's doing is only plug gamepads when input device is gamepad, but some explanation would be nice?

[ghost]

dont think this is necessary as this is immediately overriden in retro_set_controller_port_device()

there are some cases where retro_set_controller_port_device (or something else) fails and defaults to using RETRO_DEVICE_JOYPAD (i still see this sometimes in log that device connected is unknown and defaults to use RETRO_DEVICE_JOYPAD) but without setting input to the main core/emu, input would not work until manually re-setting user input (and hope retro_set_controller_port_device this works).

[Kekun]

You're right my reasoning isn't well conveyed by the PR's message, I'll explicit it. :)

• Except if I'm mistaken, retro_set_controller_port_device() is there for the frontent to tell the core what device is available on the specific port, without this the core shouldn't assume anything: the frontend should be in control.
• If the core requires a specific input to be plugged it should state it in RETRO_ENVIRONMENT_SET_CONTROLLER_INFO so the frontend could check if it has a valid input and plug it in, passing a valid information to the core rather than letting it rely on an assumption.
• The default state should always be the empty state, the frontend shouldn't have to sanitize it by setting it empty first, especialy as there is no way to know the maximum number of ports besides via RETRO_ENVIRONMENT_SET_CONTROLLER_INFO which isn't mandatory to implement.
• The physical ports of a physical SNES are empty by default, it's not like a Famicom or a handheld where you only have a fixed set of hardwired inputs.

So design-wise I think it's better to have "none" by default for emulators of machines with physical ports. On top of that this caused a bug in retro-gtk that I am going to explain below.

Some cores query various types on the same port and don't use RETRO_ENVIRONMENT_SET_CONTROLLER_INFO to inform the core about anything, for example desmume2015 queries many types on port 0 (which is acceptable as there is no notion of port on the machine, though using SET_CONTROLLER_INFO and multiple ports would be cleaner). To handle these cases, retro-gtk has the notion of default input devices: if the core queries an input on a specific port which is not of a type it handles, retro-gtk will check if a default controller of that type exists and return its value, for example this is used for inputs which can only exist in one instance like the window used as a RETRO_DEVICE_POINTER while a physical gamepad is plugged into port 0.

This created a bug in retro-gtk which is that if the core queries multiple ports for the same type without the frontend to explicitely set them, the same physical device will answer the same inputs. For example this makes Street Fighter II unusable because in menus both ports will press start at the exact same time, start a 2P game with the to characters doing the exact same movements.

To sum things up, either completely ignore retro_set_controller_port_device() and preset the controllers or let the frontend control what's plugged into the core mixing and mashing these two approaches is source of problems because neither the core nor the frontend controls everything.

To be clear, the bug in retro-gtk comes both from retro-gtk trying to be smart to handle complex cases well like desmume2015 where the port just does whatever it want and from bsnes wich only partialy let the frontend in control by having non-empty ports by defaults.

I hope my ideas are more clear. :)

[Kekun]

My problem could be solved by dropping the concept of default controller in retro-gtk and by making desmume2015 use RETRO_ENVIRONMENT_SET_CONTROLLER_INFO and plug one kind of input in different ports, but I still think that cores shouldn't silently set their controller types without the frontend knowing.

[inactive123]

OK, so to reiterate my question, is the gamepad still plugged in by default when the user first boots up the core or not,?

Because that is where I draw the line. If the enduser at first startup of this core gets into a default state where no gamepads are plugged in at all and he has to specifically set these gamepad ports at first, that is not something I want to happen. Enduser accessibility trumps any API / frontend considerations in that case.

If this is not the case and the user does not have to manually set the controller port to SNES joypad, then I'm more open to this PR.