They are all using generic USB encoders which detect as Dragon Rise
Is this the expected behaviour? or a bug?
This is expected - the input configuration is tied to the name of the controller, so configuring one of the controllers will generate a configuration for all of them. When you configure one of the 6 buttons controllers, the same configuration is applied to the rest of the controllers with the same name (including the ones with the 4 buttons layout).
I confirm I now have a working solution to play Backyard Football 2-Player using two built-in joysticks.
Since lr-scummvm already recognized the first joystick as a mouse, I left player 1/joystick 1 untouched. My problem was with joystick 2; ScummVM would not recognize this as a keyboard, and thus Player 2 could not control anything.
I used xboxdrv to configure the second joystick as a keyboard when ScummVM is used. This was done by editing the runcommand-onstart file, as outlined here: https://retropie.org.uk/docs/Universal-Controller-Calibration-%26-Mapping-Using-xboxdrv/. Since Backyard Football only needs the keyboard directional keys and the right-control button, I only mapped these (joystick as the directional keys, and a cabinet button as right-control). Once ScummVM closes, this virtual keyboard gets eliminated through the use of the runcommand-onend file (again, in the doc linked above).
After doing this, a notification would appear when opening ScummVM mentioning that an X-Box Keyboard Emulator has not been configured. This was a positive sign because it shows that the virtual keyboard was being created by opening ScummVM. Unfortunately, Player 2 still was not configured to use this keyboard.
The final step was then editing the retroarch.config file for ScummVM. I first had to map Player 2 to use the new virtual keyboard, which was done by pointing to the new joystick number (2 in my case). I also had to re-do the B=right-control mapping in retroarch that was done in the runcommand-onstart file.
After doing this, Player 2's movements were being registered in ScummVM. Strangely, Player 2's movements were also moving the mouse cursor (Player 1). The final step was to tell the retroarch.config file that player 1 should not have any keyboard functionality. I did this by manually mapping each directional key and right-control to "nul" for player 1, similar to the following: input_player1_up = "nul". Now, moving joystick 1 controls player 1 (mouse), and joystick 2 controls player 2 (keyboard, via xboxdrv).
You helped me get my set up for my controller and helped me with the keys ... i have struggled with this for 4 days lol ... glad it works and i hope others can see this and get the idea how it works :)
@mitu This was it! I have a script that controls an LED light/Power button on my case, (as well as shows heat/fan speed, etc) and it seems that the new update doesn't like it. If I delete the python line, the retropie command line and the RetroPie UI work as expected. Not sure what the conflict is, but it's clearly to do with the script on my end.
Below is the autostart.sh if you're curios. Thanks so much for your help!
I am using a Logitech F310 and i am very satisfied with this gamepad so far. Quality is very good and the price is logical . It is working out of the box with the RetroPIe. I have test it in a Pi3B and Pi3B+ .
The only cons i have found are the loose (but very responsive) d-pad but it is not create problems during gameplay and the luck of vibration.
Before i buy this i had a cheap one and the buttons start to need extra pressure for respond after few weeks of normal use.
@Dagna The beta image at: https://retropie.org.uk/download/
Might be unrelated, but I've had random issues with this build and previous ones, but devs can't reproduce it. For example, ES wouldn't save my inputs until I re-installed ES from retropie-setup. Maybe it's my bad card (a few months old) or the card reader's bad.