libretro
[Linux] EMS Triolinker Plus II detected but not working
Description
I have an EMS Triolinker Plus II and i'm on Arch Linux with LTS kernel. I'd like to use my Dreamcast gamepad on it.
Expected behavior
The Triolinker Plus II should detect the gamepads and the inputs should be able to be configured on Retroarch. The gamepad works when tested on jstest and on the Dolphin Emulator.
Actual behavior
The Triolinker is detected by retroarch, with the right name, and can be selected on the gamepads list. Though, no input is registered from it at all. My other gamepad, a generic Xbox One, works with no issues.
Steps to reproduce the bug
- Have a Triolinker Plus plugged on a PC under linux and with Retroarch installed.
- Start Retroarch and go to the input settings.
- Select the Triolinker Plus II in the gamepad selection.
- Attempt to change the gamepad keys.
Bisect Results
It started happening when I tried to actually use my Triolinker Plus.
Version/Commit
- RetroArch: 1.17.0 ad8975cb5a
Environment information
- OS: Arch Linux with LTS Kernel
It seems i'm probably the only being in the entire earth to try to use the Triolinker on Retroarch but I know zero coding. If i can be of any help, feel free to ask.
Which joypad driver did you use maybe udev ?
Did you try other joypad driver linuxraw or sdl2 ?
Also can you give the output of lsusb ?
Thank you.
Which joypad driver did you use maybe
udev? Did you try other joypad driverlinuxraworsdl2?
I tried to find how to get these infos, but I don't find anything relevant. How can I check for this?
Also can you give the output of
lsusb?
Bus 001 Device 009: ID 2006:0118 LenovoMobile EMS TrioLinker Plus II
And while i'm at it, here's what i got with cat /proc/bus/input/devices
I: Bus=0003 Vendor=2006 Product=0118 Version=0100
N: Name="EMS Production LTD EMS TrioLinker Plus II"
P: Phys=usb-0000:00:14.0-7.7/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7.7/1-7.7:1.0/0003:2006:0118.0005/input/input11
U: Uniq=
H: Handlers=event8 js0
B: PROP=0
B: EV=20001b
B: KEY=fff00000000 0 0 0 0
B: ABS=300e7
B: MSC=10
B: FF=107030000 0
jstest also says the "driver version is 2.1.0" without telling me what driver it's talking about.
Thanks.
Thank you for the information.
I tried to find how to get these infos, but I don't find anything relevant. How can I check for this?
Did you check in Settings tab > Drivers > Controller ?
It should be working on Linux, I have found this information about Linux kernel.
Ok I checked and i was using udev indeed.
Though, I tried with all the other ones (sdl2, parport and linuxraw) and none of them worked either. (linuxraw doesn't even work with my working xbox one pad)
And yes, the triolinker works. jstest and the original Dolphin Emulator replies to it. It even works with supertuxkart. Only retroarch ignores it. Which is why i reported it here.
Can you check which driver is used for the joypad for Dolphin and SuperTuxKart, I presume SDL2 ?
So if you select SDL2 driver in RA, and you try to bind your controller it does not detected anything ?
On dolphin it says evdev/0/EMS TrioLinker Plus II. I'm not sure if evdev is the name of a driver. I can't find anything else from there. For supertuxkart i have no idea either. I think supertux (the platformer) uses sdl and it detects the pad too.
On retroarch, the Triolinker itself is detected and the name appears. But no input detected from any buttons or sticks, either in "config all" or configure keys individually. I also tried with and without the memory card (in case it would change anything for some odd reason) but no changes.
Will it possible to get some log when using udev and sdl2 controller driver ?
Here's the logs I got, using sdl2, then udev. I've launched it with --verbose but it looks like there's not much. Is there an "even more verbose" option eventually ?
retroarch.udev.log retroarch.sdl.log
thanks.
You're not the only one using this now venerable adapter. I've had one for several years, but just pulled it out again a couple of weeks ago for a new emulationstation/retroarch combo I've installed on Arch Linux on an Intel NUC 7i5. I run a 'green goblin' HKT-7300 arcade stick through it.
The Triolinker Plus II intermittently just stops working for me and frequently needs to be replugged for either emulationstation or retroarch to detect it. Running lsusb shows it isn't being detected. I've tried all of the USB ports on the NUC as well as two different hubs. The Unitek Y-3089 4-port hub doesn't even detect or passthrough the Triolinker.
So...long story short, I've got a replacement, hopefully more functional and up to date dreamcast-to-USB adapter on the way from Aliexpress. The other commonly mentioned dreamcast-to-usb adapter from raphnet (https://www.raphnet-tech.com/) is sold out until April or May.
Strange as both controllers are detected using udev
[INFO] [udev]: Pad #0 (/dev/input/event8) supports force feedback.
[INFO] [udev]: Pad #0 (/dev/input/event8) supports 16 force feedback effects.
[INFO] [udev]: Pad #1 (/dev/input/event9) supports force feedback.
[INFO] [udev]: Pad #1 (/dev/input/event9) supports 16 force feedback effects.
...
[INFO] [Autoconf]: Microsoft X-Box One pad configuré dans le port 1.
[INFO] [Autoconf]: EMS Production LTD EMS TrioLinker Plus II (8198/280) non configuré.
And SDL2
[INFO] [Autoconf]: PDP Xbox One Controller (3695/354) non configuré, utilisation du recours par défaut.
[INFO] [Autoconf]: Production LTD EMS TrioLinker Plus II (8198/280) non configuré, utilisation du recours par défaut.
What is the output when you have only EMS TrioLinker Plus II plugged ?
udevadm info -q property -n /dev/input/js0
P.S = You can submit controller profile for your xbox controller for SDL2 if you want.
Here's what udevadm returned:
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7.7/1-7.7:1.0/0003:2006:0118.0007/input/input23/js0
DEVNAME=/dev/input/js0
MAJOR=13
MINOR=0
SUBSYSTEM=input
USEC_INITIALIZED=1909612633
ID_INPUT=1
ID_INPUT_JOYSTICK=1
ID_BUS=usb
ID_MODEL=EMS_TrioLinker_Plus_II
ID_MODEL_ENC=EMS\x20TrioLinker\x20Plus\x20II
ID_MODEL_ID=0118
ID_SERIAL=EMS_Production_LTD_EMS_TrioLinker_Plus_II
ID_VENDOR=EMS_Production_LTD
ID_VENDOR_ENC=EMS\x20Production\x20LTD
ID_VENDOR_ID=2006
ID_REVISION=0100
ID_TYPE=hid
ID_USB_MODEL=EMS_TrioLinker_Plus_II
ID_USB_MODEL_ENC=EMS\x20TrioLinker\x20Plus\x20II
ID_USB_MODEL_ID=0118
ID_USB_SERIAL=EMS_Production_LTD_EMS_TrioLinker_Plus_II
ID_USB_VENDOR=EMS_Production_LTD
ID_USB_VENDOR_ENC=EMS\x20Production\x20LTD
ID_USB_VENDOR_ID=2006
ID_USB_REVISION=0100
ID_USB_TYPE=hid
ID_USB_INTERFACES=:030000:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usbhid
ID_PATH_WITH_USB_REVISION=pci-0000:00:14.0-usbv2-0:7.7:1.0
ID_PATH=pci-0000:00:14.0-usb-0:7.7:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_7_7_1_0
ID_FOR_SEAT=input-pci-0000_00_14_0-usb-0_7_7_1_0
DEVLINKS=/dev/input/by-id/usb-EMS_Production_LTD_EMS_TrioLinker_Plus_II-joystick /dev/input/by-path/pci-0000:00:14.0-usb-0:7.7:1.0-joystick /dev/input/by-path/pci-0000:0>
TAGS=:uaccess:seat:
CURRENT_TAGS=:uaccess:seat:
P.S = You can submit controller profile for your xbox controller for SDL2 if you want.
Mmm sure i can do that.
Log level can be set in Settings / Logging / Frontend log level, level 0 (debug) has most details, logs above look like default settings (level 1, Info).
Linuxraw driver has been updated recently (since 1.17.0 release), if you can try a recent nightly build, it may also reveal something, as well as jstest /dev/input/js0.
Log level can be set in Settings / Logging / Frontend log level, level 0 (debug) has most details, logs above look like default settings (level 1, Info).
Linuxraw driver has been updated recently (since 1.17.0 release), if you can try a recent nightly build, it may also reveal something, as well as
jstest /dev/input/js0.
Just tried the nightly build appimage of today and the gamepad worked ! Seems it got already fixed but just not pushed yet. Guess i'll need to wait for the next update. :p
While i'm at it, i'm trying with the other pads as well. Sadly only one pad can work at a time. But it's not Retroarch's fault here. Just the Triolinker being too basic to control 3 pads at the same time. (i could tell that by testing in jstest) Too bad.
Anyway, thanks for the help you guys. I think we can call this case closed. Waiting for the next update. ^^