I’ve installed the scummvm snap on a desktop and used a joystick (now joystick is autoconnected) to navigate the user interface. However the same snap running on Ubuntu Core with mir-kiosk, the joystick doesn’t work in the application.
The device shows up when disconnected/attached:
[Tue Jul 14 09:08:05 2020] usb 1-1.3: USB disconnect, device number 3
[Tue Jul 14 09:08:05 2020] xpad 1-1.3:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
[Tue Jul 14 09:08:08 2020] usb 1-1.3: new full-speed USB device number 5 using xhci_hcd
[Tue Jul 14 09:08:08 2020] usb 1-1.3: New USB device found, idVendor=0e6f, idProduct=0413, bcdDevice= 1.00
[Tue Jul 14 09:08:08 2020] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Jul 14 09:08:08 2020] usb 1-1.3: Product: Afterglow Gamepad for Xbox 360
[Tue Jul 14 09:08:08 2020] usb 1-1.3: Manufacturer: BDA
[Tue Jul 14 09:08:08 2020] usb 1-1.3: SerialNumber: 0ABED28D
[Tue Jul 14 09:08:08 2020] input: Afterglow AX.1 Gamepad for Xbox 360 as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input3
Is there some reason we should expect joysticks to not work on core? Has anyone else got a joystick working on core?
Is the joystick interface connected on this UC device too (just asking as sometimes there are situations where interfaces don’t autoconnect the same on UC as on classic)?
If the interface is connected, do you see any system denials while trying to use the joystick ?
for d in $(cat /sys/fs/cgroup/devices/snap.scummvm.daemon/devices.list | awk '{print $2}'); do
udevadm info --query=property --path=/dev/char/$d | grep -Po 'DEVNAME=\K.*'
done
popey@localhost:~$ for d in $(cat /sys/fs/cgroup/devices/snap.scummvm.daemon/devices.list | awk '{print $2}'); do
> udevadm info --query=property --path=/dev/char/$d | grep -Po 'DEVNAME=\K.*'
> done
/dev/null
/dev/full
/dev/zero
/dev/random
/dev/urandom
/dev/tty
/dev/console
/dev/ptmx
syspath not found
syspath not found
syspath not found
syspath not found
syspath not found
syspath not found
syspath not found
syspath not found
syspath not found
/dev/net/tun
/dev/input/event2
/dev/input/js0
/dev/vchiq
syspath not found
/dev/snd/pcmC0D0p
/dev/snd/pcmC0D1p
/dev/snd/pcmC0D2p
/dev/snd/controlC0
/dev/dri/card0
/dev/snd/timer
so these are your joystick devices (presumably), which means that I don’t think confinement is to blame here for why the joystick doesn’t work. Do you know more details about how scummvm tries to access joysticks?
Yes, that’s correct, the /dev/input/js0X devices are the joysticks. I don’t see why it doesn’t work on core yet. ScummVM isn’t doing anything fancy regarding the joysticks, it really just uses the Joystick/Gamepad handling from the SDL2 libraries.
@popey, can you please check if your specific gamepad works on the ScummVM snap not running on core, but on a “full” system instead? I just checked it against a PS4 controller, that works fine (on a full system, I don’t have a core installation ready for testing right now). Can you also check if e.g. the SuperTux snap fails in the same way on core? This would help to rule out if e.g. all SDL2 applications are broken this way or if it’s something specific to ScummVM.
@lotharsm Yes, the same joystick works on my Ubuntu 20.04 classic system in ScummVM with no tweaks.
Sadly if I remove scummvm and install supertux, then connect the joystick interface (that should be automatic?) and sudo supertux sadly it segfaults. I think it probably also needs pulseaudio given there’s nothing to connect audio-playback to?
I have the pulseaudio snap installed (for scummvm) but the supertux (not supertuxkart) snap doesn’t specify the pulseaudio interface, so I can’t plug it.
If you unsquashfs the supertux snap, and add the pulseaudio plug to the plugs in the snap.yaml, and then snap try squashfs-root and then connect all the interfaces does it run ?
Hmm, I think we may be dovetailing too much here on supertux, is there some other game is known to use a joystick well on classic that is easily installable on core ?
This post made me order a cheap gamepad to try to reproduce this problem. Let’s see if I can get it delivered before you fix whatever is causing the bug.
I think that’s a red herring. I have to admit this is my first time trying to debug a SEGFAULT on UC, and the experience isn’t great since we don’t have gdb or gdbserver and it’s non-trivial how to add that to a system so we could run snap run --gdb supertux or snap run --experimental-gdbserver supertux, but I will hack something together that should get us further to at least the point where we can say where supertux is crashing
@popey, just in case we want to follow the libmirclient route and to rule out the red herring: I added libmirclient9 to the stage-packages of SuperTux, so you can re-test it with the latest build from the edge channel.
