Xbox One Gamepad not detected on Surface Pro 8 using Surface Kernel

[davidbitterlich]

Hi,

I currently have the problem that I cannot use my Xbox gamepad on my Surface Pro 8 and I would like to know how the MCPELauncher does detect controllers and how it does interact with them.

The controller is currently connected via bluetooth and does a great job in retroarch (Flatpak) but it is not detected at all in MCPELauncher, neither using Flatpak nor AppImage...

I would like to tackle the cause of this problem down to either be a problem with the launcher or with the Surface kernel... When I'm using my distribution's stock kernel, the AppImage is able to work with the controller.

Does anyone here have an idea about how controller support is implemented in the launcher, so that I have some point for further analysis?

[ChristopherHX]

Controller detection varies a lot, there a different implementations

For example here is a SDL3 (successor of SDL2, still in development) a more widely used Game Framework AppImage

• https://github.com/minecraft-linux/mcpelauncher-manifest/releases/download/nightly/Minecraft_Bedrock_Launcher-bookworm-sdl3-x86_64-v0.15.0.369.AppImage that one uses SDL3 for gamepad input may needs gamepad mappings
• flatpak uses glfw for gamepads https://github.com/glfw/glfw (Xbox one gamepad for bluetooth lacks an gamepad mapping with os linux, the windows one is ignored)
• regular appimage uses custom https://github.com/mcmrarm/linux-gamepad (Xbox one gamepad for bluetooth lacks an gamepad mapping with os linux, this implementation takes the windows one)

[davidbitterlich]

Ok, so the bookworm appimage with SDL3 does not detect the gamepad neither in the gamepad tool, nor in the game directly. Plus it crashes my wayland session when I exit the game... (Using Surface kernel). When I use my distribution's kernel, the AppImage does detect my gamepad. It complains that "7 joysticks can not be used as Gamepad Input" - and one of this is my xbox gamepad.

The flatpak version does not complain about any joysticks - and the Gamepad Tool does not provide me anything to configure.

The regular appimage also detects my gamepad when using vanilla kernel (not Surface kernel) and the regular appimage is currently the only launcher in which the xbox controller does work in-game. I did not provide any gamepad mapping. Also my wayland session does not crash, when I close the game...

Well I've seen that the custom linux-gamepad implementation seems to use libevdev. I have created a small C program to list all devices using libevdev and was able to see my Xbox Controller in the output using Surface Kernel. The device also does have an entry /dev/input/js0 in both stock and Surface kernel - and using udev, I am also able to see that my controller is connected/disconnected when I monitor.

What else could be the thing that differs between both kernels which makes the mcpelauncher being unable to detect my controller when using Surface Kernel?!

I wrote two small C programs, one using libevdev (which is what is used in linux-gamepad) and one using glfw to list my connected input devices.
sources.zip

The first file using libevdev does detect my gamepad in both situations: using stock kernel as well as using surface kernel. However the glfw based program only detects my gamepad when I use the stock kernel. Otherwise it's not being detected...

Btw when I use evtest against my xbox gamepad on the surface kernel, I am able to see when I press buttons, move the joystick etc. So it might probably be any detection issue?

[ChristopherHX]

• the gamepad tool in the qt ui always uses glfw even for the sdl3 build

So that would explain that you cannot configure it with the gui

What is the gamepad guid under the surface kernel? I mean if it is different to the one of the stock kernel the mcpelauncher maps every input to null, because like on one of your kernel there are many joysticks that are not gamepads however tgat can be also just gamepads with an unknown guid + os combo

The gamelog tab of the launcher shows gamepad connected # number if one has been found, but that do
not tell you that it's input aren't null mapped

regular appimage is currently the only launcher in which the xbox controller does work in-game

I need to use the configure gamepad for glfw and likewise sdl3 on stock kernel for the bluetooth mode (don't have a surface) because the gamepad mapping for windows is ignored for linux

The flatpak version does not complain about any joysticks

That's weird, the sandbox allows this on my stock ubuntu, every linux configuration has unique bugs

Also my wayland session does not crash, when I close the game...

Because then xwayland is used, but still need to figure out if I do something that indirectly kills wayland on the close event
I noticed flatpak + sdl3 show these problems

[davidbitterlich]

I'm not sure where I could get the GUID for the controller from, but I think you might mean udevadm. For me it seems like it creates different DEVPATHs between both kernels (but there are even more differences, e. g. the surface kernel produces much more data regarding this gamepad than the stock kernel)

output-udevadm-xbox-controller-surface.txt
output-udevadm-xbox-controller-stock.txt

Surface DEVPATH:
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:256/0005:045E:02FD.0008/input/input35

Stock DEVPATH:
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:256/0005:045E:02FD.0007

Currently I'm using Ubuntu 24.04 and I know for sure on my previous Notebook with Ubuntu 22.04 I did not have those problems, the Flatpak version ran well (better than the AppImage) and I was directly able to use my Xbox gamepad... But that's already a year back or so...