#1940 Joystick up key gets stuck

[exrom]

Hello VICE Team,

when i press and release the up key on my COMPETITION PRO USB controller, the up key lamp in the bottom area of the GTK window permanently lits. Games react accordingly. This basic code also shows the issue:
10 print peek(56321);:print peek(56320): run
run

Only pressing the down key once, releases the stucked up key (not if "allow opposite directions" is enabled).

The controller i use shows up as "SPEEDLINK COMPETITION PRO Game Controller for Android" and is reported as "0079:181c DragonRise Inc. Game Controller for Android" by lsusb.
It does not happen with another keypad "GreenAsia Inc. USB Joystick" Bus 003 Device 014: ID 0e8f:0003 GreenAsia Inc. MaxFire Blaze2

It happens on both joystick ports but only if option "Swap Joysticks" is not active.
Interestingly, the stucked key gets released if i hover the mouse pointer over any graphical element in the bottom area (Tape, warp, CRT,...) or the menu bar (File, Edit, Snapshot,...)

Steps to reproduce:
I used git commit dd5421 of https://github.com/VICE-Team which is one commit after dd5421 (tag: r44453) on Linux Mint 21.2.
Tested with VICE 3.7.1 from 2023-08-31

$ git clean -dfx && ./autogen.sh && ./configure --enable-gtk3ui && make
$ rm ~/.config/vice/vicerc
$ src/x64sc
i now select the COMPETITION PRO Game controller in joystick settings (USB device need to be attached before x64sc is started to get shown in drop down - hot plug would be nice here...).
At this point everything is still fine - joystick LEDs show the directions and no keys get stuck.
I select "save settings" and close x64sc. Contents of vicerc is now:

    [Version]
    ConfigVersion=3.7.1

    [C64SC]
    Window0Height=649
    Window0Width=720
    Window0Xpos=966
    Window0Ypos=285
    JoyDevice2=4

When i now restart x64sc, the problem appears as described above.
Furthermore, immediately after starting x64sc the UP LED and key lits immediately without even touching the joystick! (don't touch the mouse while trying).

So it seems, problem happens whenever JoyDeviceX=4 is present while x64sc is started.
Side: note: "swap joystick" isn't saved to vicerc. Not sure whether this is intended.

This is likely related to https://sourceforge.net/p/vice-emu/bugs/1822/ https://sourceforge.net/p/vice-emu/bugs/1837/

Thank you!

[gpz]

It might be caused by the default button mappings (which are still hardcoded into the joystick code). Especially if an axis is not 0 at the center, all kinds of weird things happen. Or if two buttons that are mapped to the same emulated button are active at the same time.
However, the whole joystick stuff (and the mapping in particular) is being rewritten right now. You could try using the svn head, and then save a custom mapping using the sdl port, and finally load the resulting file in the sdl port (right now this will require making a copy at the same location, but replace sdl_ in the filename by gtk3_, there is no gui for this yet)

[compyx]

Perhaps the Linux evdev joystick driver fares better with this joystick? That driver doesn't assume axis values are in the range -32767 to +32767 but uses the reported min/max values to calculate range and threshold (including digital axes that only report -1, 0 or +1).

To enable the driver make sure libevdev and its headers are installed (on Debian: apt install libevdev-dev) and pass --with-evdev to configure. This requires r44980 or newer.

[exrom]

Thanks for your feedback.

as the report above is some time ago, i re-tested with r45011 (V3.8) from Mar 04 2024 and the behaviour is still the same.
I then re-built --with-evdev as you suggested and the problem is gone :)

Thanks so much for the hint!

[compyx]

Good to hear the evdev driver works for your controller. Perhaps we should consider enabling it by default instead of the old driver.

[compyx]

I've made --with-evdev the default for Gtk3 Linux builds and updated the build docs and the Github workflow "build-main-on-push". When there are no issues in a while we can update the "make-release" workflow as well.

[Confidant]

So—I'm on a Mac M1 and installed the 3.8 version for ARM64. The gtk3 variant still has this joystick bug. I slogged through running the sdl2 variant and the joystick works, but I'm not sure how to get it to recognise the 4-joysticks I have. (I am able to to this successfully on gtk3). SDL is painful to use, to say the least. Are there step by step instructions for doing a Mac build of GTK3 version with evdev somewhere? Or perhaps will there be a new release version soon which fixes the bug?

[compyx]

Evdev is Linux-specific, you can't enable it on MacOS. Bug fixes for MacOS are unlikely to appear as well, we don't have active MacOS devs at the moment and I don't have the budget for a Mac.

[Confidant]

I appreciate the response. So what might be happening that the sdl2 version is working? Just the fact that I don't have 4 joysticks active?

[dqh]

still here if something serious needs fixing on mac, sounds like this would be hard to replicate though.

[Confidant]

I'm using the iCode Quad Plus Retro USB adapter from here: https://www.icode.com/product/quadplus/
I can experiment further sometime this week. I'm happy to collaborate with you if given some direction.

[Confidant]

@dqh The problem relates to my adapter for retro joysticks. Using a USB Logitech controller works fine.

[dqh]

are you able to test that adapter on a linux or windows machine?

[Confidant]

I'll see about firing up VirtualBox on my old Mac to try that. I had trouble installing it on my M1 Mac. I have a busy week ahead but I'll try to do it ASAP.

[compyx]

I took a look at the MacOS joystick driver code, expecting it to be like the Windows and old Linux driver: assuming each axis always having values in the range INT16_MIX to INT16_MAX, but the code actually queries the device for its available axes and their ranges, and uses those values when calculating what to pass to the shared joystick code for axis directions.

One thing that could be going wrong however is "digital" axes, these report -1, 0 or 1 for their directions, and the code uses integer division to determine if an axis value is in the negative, centered or positive position, which might fail with values in the range [-1, 0, 1].

There are also some assumptions in the code regarding hats and their values, so perhaps the device's centered value for a hat is interpreted by VICE as the value for up.

So we'd indeed need to see what the device reports for its inputs.

[Confidant]

Thanks for checking that. How could I provide that information for you? Not sure where to start.

[compyx]

I have no idea for MacOS, but I'd look for a command line tool that can show HID devices and their (raw) input values. A quick Google search gives me hidutil: https://developer.apple.com/documentation/corehid/discoveringhiddevicesfromterminal
Perhaps that tool can display the properties of your device?

[Confidant]

If I use hidutil list I can see the iCode Retro Gaming Adapter with ProductID of 0x3013. Then I can read properties using hidutil property --matching '{"ProductID":0x3013}' --get "HIDPointerAcceleration"
I'm not sure what property to read though. I'm having trouble even finding a list of available properties. There seems to be one here: https://github.com/FSecureLABS/OSXFuzz/blob/master/OSXFuzz/library_calls/iohidfamily.h

[compyx]

What you're looking for is "HID"usage page" properties ending with an axis name, for example _X or _Ry: the VICE code checks for constants called kHIDUsage_GD_X and kHIDUsage_GD_Ry. So if you can find out how to make that hidutil poll devices and show the raw HID values you should check for constants like the ones I mentioned and see what values show up when you wiggle a joystick left/right/up/down.

The 'r' axes are usually mapped to triggers, so you're probably just looking for plain 'X' and Y' axes and their values. This assumes of course the device maps the connected joystick movements to axis movements, it might be possible the devices maps to hats instead, in that case you're looking for names like kHIDUsage_GD_Hatswitch.

[Confidant]

I don't have my device handy right now but I found this page: https://developer.apple.com/documentation/hiddriverkit/3201486-games
Could it be something like kHIDUsage_Game_MoveRightOrLeft or kHIDUsage_Game_MoveUpOrDown ?