[SOLVED] Generic chinese controllers on Lakka? Chinaware Best practice

Libretro Lakka
#14

Well I wrote the autoconfig score code myself so I can swear that we’re doing a plain old good string comparison on the device name, and that there is no way that "usb gamepad [lots spaces] " equals "USB Gamepad [one or two spaces] " in a C program.

There is one case where we can’t do anything:

Joypad 1 : https://github.com/libretro/retroarch-joypad-autoconfig/blob/cf40f1dd9b23a8b59739461634077da60cb84cdf/udev/usb_gamepad___________(NES).cfg#L7-L9

Joypad 2 : https://github.com/libretro/retroarch-joypad-autoconfig/blob/cf40f1dd9b23a8b59739461634077da60cb84cdf/udev/usb_gamepad___________(SNES).cfg

In this case, the 3 criteria are the same, and RetroArch have no way to choose the right config file.

If you happen to be in this case, you need to use Advanced Settings, and load a different retroarch.cfg depending on the core you’re going to run. It can be done through the Main Menu. Certainly not as neet as Recalbox, but still better than nothing.

1 Like
#15

How would autoconfig work for 2 x retropads on 1 usb cable?, i guess they call it dual pads

#16

It seems to work. WOOOOOOHOOOOOOOOOOOOOOOOOOOO :cow::water_buffalo::ox::tiger2::rooster: :raised_hands:

Can you explain me some points. It’s important for me.

When I did, the folder filled. Must I delete all this CFG files?

Do I always have to do systemctl stop retroarch rm .config/retroarch/retroarch.cfg systemctl start retroarch after I make “bind all” and “save autoconfig” on the GUI?

I have Lakka again freshly installed, “bind all” and “save autoconfig” made and only this command executed. And it works.

Why is this not described here? http://www.lakka.tv/doc/Configuring-Lakka/ Or here? http://www.lakka.tv/doc/Configuring-Lakka/

I think that was the big mistake. Because when I had stored a thousand times the autoconfiguration, a reboot or shutdown did nothing. Also in this case not. Only with this command executed is Lakka aware of the changes with the new CFG files.

Tomorrow I will configure all controllers and test all. Then I know for sure if it works.

#17

These files you see in the dev folder are empty files. It’s the consequence of the deletion of the config files. It’s because we use OverlayFS, a layering system for our filesystems. Lakka has a read only rootfs, to allow overriding some files in the system, we use this layer strategy. Deleting a file results in creating an empty file in the top layer. So you don’t need to care about these files. They were not appearing before because they were equal on all layers.

You don’t have to purge your tetrarch.cfg every time. It was just to ensure that your retro arch.cfg is clean after all the changes you tried during the last days.

This is not described in our documentation because I wasn’t aware that some people pushed generic chinese configs in our joypad-autoconfig repository. I’m discussing with these contributors to remove their config files from here, since they are causing conflicts.

You may encounter this bug again if you have two or three controllers with the exact same name:vid:pid. I hope all of yours are different. If so, it will work just fine. The joypad manufacturer have to care about incrementing the product ID when they release a joypad that doesn’t have the same circuit board.

#18

The only thing that brought me further is this command - after I bind the controllers one by one. (for other users helpful to know)

systemctl stop retroarch
rm /storage/.config/retroarch/retroarch.cfg
systemctl start retroarch

You don’t have to delete the configs with rm /tmp/joypads/udev/* Because is more clearer with original empty folder \Joypads\udev and only with the specific configs. After I bind all controllers, I rename the CFG-files like “N64.cfg”. Thats clearer and it works.

And as you say, it works only if at least the vid and pid are different from controller to controller.

#19

I happen to have the NES and SNES controller described in post number 14, the “in this case we can’t do anything” post. What would be the best practice to be able to use them to play, even if i have to tinker a bit manually before doing so? Is there a way to manually load a controller config before playing without having to bind everything manually?

Thanks in advance.

#20

Did you have try this?

But it really makes no sense. If vid and pid are the same, you need other controllers. So changing the cores is no fun.

You have to adapt to each core the retroarch.cfg and always load manually before playing. Have not tried, and know it only theoretically for Lakka.

Here for example you can order more cheap controllers. Order and hope its not the same vid or pid

#21

Thanks for the answer, we should keep track of controllers with the same vid and pid, though, for the sake of others with the same problem.

Controllers I know confirmed to have the same vid and pid and completely different design:

  • Data Frog NES controller.
  • Data Frog SNES controller.
  • Data Frog Genesis controller.
#22

First, it is important to say:

I have two NES, SNES, N64 and PSX controller. All generic chinese controllers except for one N64 controller of the brand Retrolink (For evaluation purposes).

The one PSX controller without DualShock has the same vid and pid as the two SNES controllers.

But because the key assignments of the three controllers are identical and a PSX controller is similar to a SNES controller, I can use them all. I’m doing “bind all” only with the PSX controller and save the CFG file (“save autoconfig”). I do this only with the PSX controller because the PSX controller has the additional keys L2 and R2. When I then connect a SNES controller, the CFG file from the PSX controller is assigned and I can then play SNES games with it. The bound keys R2 and L2 do not care for the SNES core.

If all the keys of your NES controller including B and A match one-to-one to the SNES controller, you can proceed as described.

The one of my N64 controllers has also the same vid and pid as the Retrolink N64 controller.

But there I have the problem that the key assignments of the two controllers are not identical. Here I will have to order another N64 controller, because otherwise it does not really work.

I know these Data Frog Controllers and have intentionally ordered none because they are the same as the others. The silly frog logo simply makes them unnecessarily more expensive. The seller is a parasite in my eyes. Now you have the problem with the same vid’s and pid’s. Isn’t that great?

Except what I wrote. Otherwise it makes no sense in my opinion.

#23

Unfortunately, the data frog Nes and Snes controllers have different button numbers assigned to the A and B buttons, making them uncompatible with autoconfig.

#24

Hi, I’m new to Lakka.

I’ve been trying to map my Bluetooth T3 gamepad, but didn’t succeed. Even though the Bluetooth connection is established and succeeded the jstest, the “Bind all” option in Lakka menu isn’t working at all.

Can anyone help me with this?

#25

@alealv: It should work as we added configuration file for this controller. Is it possible to provide dmesg output ? Thank you.

#26

Here is the post https://pastebin.com/bXWTiMSR. Another thing is that I must also execute bluetoothctl and connect my Gamepad every time.

#27

Can you check if it is working with linuxraw or hid driver in Setting tab > Driver > Joypad driver ?

#28

Hi gouchi, udev was selected. I tried with de linuxraw and hid but it didn’t work.

#29

It seems the udev rule is not applied. Can you try to get the ouput of udevadm --info xxxx ?

Also before connecting your controller check the output of udevadm monitor to see if the udev rule is applied.

Thank you.

#30

Here is the output https://pastebin.com/v8eALkYL I couldn’t realize if the udev rule was applied. Can you explain me the process a lit bit?

#31

Thank you, sorry is it possible to have also the ouput of cat /proc/bus/input/devices I forgot to ask you.

And it seems I made a mistake, it is udevadm test with the path you get from udevadm monitor.

Thank you.

#32

Here are the outputs https://pastebin.com/LGj85c0M

It seems that the SYSTEM key isn’t valid, is it SUBSYSTEM?

#33

Good catch I have submitted a fix so that it will be updated for the next release thank you.

Can you try to copy the file from /usr/lib/udev/rules.d/99-terios-t3.rules to /storage/.config/udev.rules.d/ and modify it ?