Linux: Gamesir-T1s is not detected

[lestcape]

Current Behavior

The Gamesir-T1s is recognized by the Windows version of Cemu without any problems, but on Linux this doesn't happen. The Gamesir-T1s is recognized by the Linux kernel but not works in many places like: Firefox, Chrome, or the Dolphin emulator on Linux. I tried using it as an SDL game controller and it doesn't work either. It have a predefined setting in the SDL database with the id: ac0500002d0200001b010000.

SDL_GAMECONTROLLERCONFIG=05004477ac0500002d0200001b010000,Gamesir-T1s,a:b0,b:b1,x:b3,y:b4,back:b10,guide:b12,start:b11,leftstick:b13,rightstick:b14,leftshoulder:b6,rightshoulder:b7,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,lefttrigger:a2,righttrigger:a3,crc:7744,platform:Linux

It doesn't matter if Steam is open or closed.

Expected Behavior

Cemu should recognize the device on Linux and allow you to interact with it like on Windows.

Steps to Reproduce

Just connect the Gamesir-T1s using bluetooth, then the open Cemu on Linux and try to use/configure the Gamesir-T1s controller.

System Info (Optional)

OS: Debian 12 GPU: NVIDIA GeForce GTX 1660 Ti I have libsdl2-2.0-0 version 2.26.5+dfsg-1 installed in x64 and i386.

Emulation Settings (Optional)

Use the last version with the default settings, not matter if is the Ubuntu version or the appimage version.

Logs (Optional)

No response

[Squall-Leonhart]

I have libsdl2-2.0-0 version 2.26.5+dfsg-1 installed in x64 and i386.

can i ask why? SDL controller compatibility is SDL's domain and by using an older version you open yourself up to issues, one of them being this controller not working

Both this and your other bug with the logitech wheel are absolutely upstream concerns that should be addressed.

It have a predefined setting in the SDL database with the id: ac0500002d0200001b010000.

It does not, there is no defintion for the T1 in SDL_gamecontrollerdb.h

Windows and Linux entries also can and often do have different guid's for the same device within the SDL_gamecontrollerdb.h

05004477ac0500002d0200001b010000 also looks strikingly like an old pre 2.0.16 guid...... its not an old guid, upstream just has no idea what it is.

[lestcape]

can i ask why?

I really need to explain to you why I use a stable distribution instead of a rolling release one and have the official distribution package, instead of having a different installation?

are absolutely upstream concerns that should be addressed.

I don't have a device that actually works as a gamepad on Linux, so I don't know if the reason why Cemu doesn't work on Debian is because it uses an incompatible version of the default library provided by the stable version of my distro or for whatever reason.

It's assumed that if I have a device for which there is no official mapping, but which is detected by the kernel, then writing an environment variable with the controller configuration should be safe and the device should be recognized. Isn't that so?

Well no, it's not recognized by Cemu and I don't know why. That's why I opened the two issues, to really know where the problem is. It seems too hasty to blame the upstream for that. Especially with the other issue, because in the other case, Dolphin, for example, solves it in the same conditions as Cemu does with respect to the Upstream, because really the device is not a gamepad and the correct thing to do is to treat it as what it is.

It does not, there is no defintion for the T1 in SDL_gamecontrollerdb.h

Ok, okay, I used a different database than the official one: https://github.com/mdqinc/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt, but it should have worked. What's actually going on?

[Squall-Leonhart]

I really need to explain to you why I use a stable distribution instead of a rolling release one and have the official distribution package, instead of having a different installation?

a 2 years out of date version of SDL having problem is not unheard of SDL 2.26.x has many problems with BT controllers that were addressed in 2.28 and beyond

It's assumed that if I have a device for which there is no official mapping, but which is detected by the kernel, then writing an environment variable with the controller configuration should be safe and the device should be recognized. Isn't that so?

on Windows, SDL will fallback to a generic DI mapping if one is not in the DB, on Linux it will either spaz out or not work at all. What could be a cemu side issue is whether or not the gamecontrollerdb.txt is actually loaded at start, but i assume it still does as the sdl configurator has been used by others to force remapping of third party switch controls.

[lestcape]

a 2 years out of date version of SDL having problem is not unheard of SDL 2.26.x has many problems with BT controllers that were addressed in 2.28 and beyond

If that the case, my device will work the next year, when a new stable release of Debian will be releases. That should be good. I can try to install a new version of the library by my self, but who knows if it is something simple or if too many dependencies come into conflict. However, I unfortunately don't believe this is the case. As I said, the device works perfectly under Linux. This is not an assumption, everything works and is tested by me, just not work in CEmu:

What could be a cemu side issue is whether or not the gamecontrollerdb.txt is actually loaded at start, but i assume it still does as the sdl configurator has been used by others to force remapping of third party switch controls.

This is where I think the problem is, for some particular reason in my system it is possible that something is failing, but I don't know what it is or how to find out. So, I don't know which software to blame for that yet.

[lestcape]

I can't blame the upstream directly, because, for example, Cemu can add another method to detect devices on Linux, and this can be, for example, the same one used by the "Joystick Preferences", since Cemu actually has its own method to remap the controls, so it doesn't need another library to do it for it. This would be especially useful for cases like this, where things go really wrong, starting from something that obviously works in the kernel.

[Squall-Leonhart]

the same one used by the "Joystick Preferences", since Cemu actually has its own method to remap the controls, so it doesn't need another library to do it for it. This would be especially useful for cases like this, where things go really wrong, starting from something that obviously works in the kernel.

Unreliable and requires distro specific hacks, not likely to happen.

[lestcape]

Unreliable and requires distro specific hacks, not likely to happen.

Is only your opinion. Hardware manipulation is a kernel task, not a distro task. The distros can modify the kernel, but not supporting distros that modify things like these would be even advisable. Continuing to think this way about Linux is not positive. Your point has always been the excuse for everyone to negate the support of something in Linux. However, Cemu itself is the example that if you want it or you need it, you can. Of course, the easiest way is always going to be to use cross-platform libraries, which will take care of all the platform-related issues for themselves. But if libraries can implement something, then you too. It's a matter of whether you want to, not whether you can or not.

I don't know what's going on with SDL specifically, but it's clear to me that something is wrong. Of the 2 devices I have, both with kernel support, neither of them work. That's a very bad statistic and it would make me personally question whether it's really enough to just use something like that or if something else needs to be done. We all know that hardware support in Linux is not good. If you also waste hardware that does work, things get worse.

[lestcape]

The device Gamesir-T1s was tested directly witch my version of libsdl and was not detected by the sdl library. So, this issue can be considered an upstream problem. Anyway, as i mention, it also can be resolved if Cemu add his own native method to detect devices in Linux as the device is detected by the kernel and other softwares.