Unhandled SDL event of type 0x6(XX)

[Heisenborgar]

Tbh the developer of OpenMW told me to report this error to here in hopes of resolving my issue.

Here's the issue I encounter:

Playing OpenMW with a controller makes the cursor controlled by left thumbstick to stutter unless using a mouse to click to regain control

• Is the problem OpenMW specific or does it also happen in vanilla Morrowind?
  • Yes, OpenMW (Haven't tried on Vanilla Morrowind)
• What is your operating system?
  • Tried on both Vanilla Arch and CachyOS (Arch-based) and the problem occurs on both
• What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used.
  • Using Arch's AUR OpenMW-git package (which is pulled directly here when there are commits to the repo)
• What version of Morrowind are you using (i.e. retail CD or Steam)? What addons (Tribunal, Bloodmoon) do you have installed? What language is your Morrowind install?
  • GOG, all DLCs and other Bethesda Plugins, English
• Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods?
  • Yes, and yes. Tried on both Vanilla and mods from i-heart-vanilla: director's cut with some other mods and the problem still occurs
• What are the exact steps to reproduce the problem?
  • Just move the left thumbstick when on menus, or when the cursor appears, it'll lag until you use a mouse to regain control
• What did you expect to happen? What happened instead?
  • Buttery smooth cursor control on my controller, but it stutters
• Are there any error messages in your openmw.log file? If you're not an OpenMW team member, it's best to upload it.
  • Here's the link (Cant paste it to pastebin due to the 512kb limit): https://drive.google.com/file/d/1PcWlUNCyhzAAyx8BfNt7pPEsmJaAd3Py/view?usp=sharing
• What settings do you use? If you're not an OpenMW team member, it's best to upload your settings.cfg.
  • Here: https://pastebin.com/tLWj46pd
• Where is the in-game location this problem can be observed? Avoid vague statements such as "west of town X". Instead, open the console (` key by default, the key above Tab), click on the problematic object, then use the betacomment (bc) instruction to get useful information about the object that you can copy and paste into the bugreport:
  • Anywhere, as long as when you're controlling the cursor via the left thumbstick on a controller, it will eventually lags and I notice you can still select or highlight with it even though the cursor is frozen in the position

I used my Gamesir T4 Nova Lite and XBOX 360 controller and both stuttered when I control the cursor via left thumbstick.

I noticed that like the majority of my openmw.log contains this error:

[15:53:48.721 I] Unhandled SDL event of type 0x608 [15:53:48.737 I] Unhandled SDL event of type 0x65a [15:53:48.737 I] Unhandled SDL event of type 0x608 [15:53:48.754 I] Unhandled SDL event of type 0x65a [15:53:48.754 I] Unhandled SDL event of type 0x608

[cgutman]

That's SDL_EVENT_GAMEPAD_SENSOR_UPDATE and SDL_EVENT_GAMEPAD_UPDATE_COMPLETE.

Can you collect another log with the SDL_EVENT_LOGGING=2 environment variable set?

[Heisenborgar]

Here's the vid (can't attach it here idk why): https://drive.google.com/file/d/1V1FNqExWgKVFmi1b1hmYlGilx9Yx5YvN/view?usp=sharing

Here's the log of playing OpenMW with default install, no mods and SDL_EVENT_LOGGING=2 and the problem still happens: https://pastebin.com/curjhKMm

[cgutman]

Okay, for some reason the expected log output from SDL_EVENT_LOGGING isn't present in your new log, but it's not a big deal.

I have a theory about what's going on. With your game controller plugged in, can you run sudo evtest and post the list of input devices that it prints? It should look something like this:

No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Lid Switch
/dev/input/event1:	Power Button
/dev/input/event10:	PC Speaker
/dev/input/event11:	HDA Intel PCH Mic
/dev/input/event12:	HDA Intel PCH Headphone
/dev/input/event13:	HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event14:	HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event15:	HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event16:	HDA Intel PCH HDMI/DP,pcm=9
/dev/input/event2:	AT Translated Set 2 keyboard
/dev/input/event3:	ImExPS/2 Generic Explorer Mouse
/dev/input/event4:	FRMW0001:00 32AC:0006 Wireless Radio Control
/dev/input/event5:	FRMW0001:00 32AC:0006 Consumer Control
/dev/input/event6:	FRMW0001:00 32AC:0006
/dev/input/event7:	PIXA3854:00 093A:0274 Mouse
/dev/input/event8:	PIXA3854:00 093A:0274 Touchpad
/dev/input/event9:	Video Bus

[Heisenborgar]

I'll post the result of sudo evtest, as well as other relevant info, later, after work.

I'd like to mention that my Gamesir Nova Lite controller has four modes depending on platform and denoted by LED color:

1. Blue for DualShock 4
2. Red for Nintendo Switch
3. Green for PC
4. Yellow for Android.

With that said, I'm certain I'm on Green since it's the one for PC, and I connected the controller via dongle. Furthermore, I remember that when testing the gamepad from KDE's system settings, it returned my controller with a name of something like: Generic Xbox Controller. Searching online says that putting the controller into green will switch it into Xinput mode.

Here's the manual if you'd like to see it, thanks!

Edit: Here's the result of sudo evtest:

[cgutman]

Hmm, an XInput controller doesn't contain any sensors, so receiving SDL_EVENT_GAMEPAD_SENSOR_UPDATE is definitely unexpected.

My theory was that the Linux joystick code's matching logic is incorrectly matching an unrelated sensor to your controller. That may still be what's happening, but it seems less likely after some local testing shows that the EVIOCGUNIQ should deterministically fail with any device using the Linux xpad driver. That would prevent any sensors from matching with it.

Can you run evtest again, make note of the eventNN values for "Generic X-Box pad" and "2.4G XBOX 360 For Windows Keyboard", then run the following commands for each of those (filling in <NN> with the event device number from the evtest output)

cat /sys/class/input/event<NN>/device/uniq
cat /sys/class/input/event<NN>/device/phys

(You may need to run this as root)

Also for good measure, try running lsusb -v to see what USB interfaces that the dongle is providing and attach the output here.

[Heisenborgar]

Here they are:

$ sudo evtest: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: Lid Switch /dev/input/event1: Power Button /dev/input/event10: HD-Audio Generic Headphone /dev/input/event11: 2.4G XBOX 360 For Windows Keyboard /dev/input/event12: Generic X-Box pad /dev/input/event2: Power Button /dev/input/event3: Video Bus /dev/input/event4: AT Translated Set 2 keyboard /dev/input/event5: PC Speaker /dev/input/event6: ELAN1300:00 04F3:3087 Mouse /dev/input/event7: ELAN1300:00 04F3:3087 Touchpad /dev/input/event8: Asus WMI hotkeys /dev/input/event9: HD-Audio Generic HDMI/DP,pcm=3

$ sudo cat /sys/class/input/event11/device/uniq (Blank)

$ sudo cat /sys/class/input/event11/device/phys usb-0000:04:00.3-4/input1

$ sudo cat /sys/class/input/event12/device/uniq (Blank)

$ sudo cat /sys/class/input/event12/device/phys usb-0000:04:00.3-4/input0

Here's the lsusb -v output

[Heisenborgar]

I got my Steam deck OLED, let me see later if the problem still occurs on a completely different device.

[jfrancis71]

I believe I may be having a related problem:

I am using ROS2 teleop joy for controlling my robots. We are getting an error: "Unknown event type 1544". This number is a decimal number, but it's hexadecimal equivalent is 0x608.

We can solve this with: mamba install sdl2==2.30.10 and it seems to fix the problem. The current Robostack Jazzy (on MacOSX) conda install defaults to use sdl2==2.32.50

Here is the relevant link: https://github.com/RoboStack/ros-jazzy/issues/37

The problem was initially detected on MacOSX and not on Linux. But this seems to be because of the different conda default sdl versions installed. On both MaxOSX and Linux, sdl=2.32.50 fails (with the same error above) and on both platforms sdl=2.30.10 fixes it.

I hope this is helpful.

[slouken]

I believe I may be having a related problem:

I am using ROS2 teleop joy for controlling my robots. We are getting an error: "Unknown event type 1544". This number is a decimal number, but it's hexadecimal equivalent is 0x608.

You should only look at SDL_GetError() if an API function is returning an error result. What API function is failing here?

[jfrancis71]

Here is a snippet of the relevant code:

    int success = SDL_WaitEventTimeout(&e, wait_time_ms);
    if (success == 1) {
      // Succeeded getting an event
      if (e.type == SDL_JOYAXISMOTION) {
        should_publish = handleJoyAxis(e);
      } else if (e.type == SDL_JOYBUTTONDOWN) {
        should_publish = handleJoyButtonDown(e);
      } else if (e.type == SDL_JOYBUTTONUP) {
        should_publish = handleJoyButtonUp(e);
      } else if (e.type == SDL_JOYHATMOTION) {
        should_publish = handleJoyHatMotion(e);
      } else if (e.type == SDL_JOYDEVICEADDED) {
        handleJoyDeviceAdded(e);
      } else if (e.type == SDL_JOYDEVICEREMOVED) {
        handleJoyDeviceRemoved(e);
      } else {
        RCLCPP_INFO(get_logger(), "Unknown event type %d", e.type);
      }

This is from line 435 in: https://github.com/ros-drivers/joystick_drivers/blob/ros2/joy/src/joy.cpp

I believe it is falling through to printing out the info message

[slouken]

Here is a snippet of the relevant code:

    int success = SDL_WaitEventTimeout(&e, wait_time_ms);
    if (success == 1) {
      // Succeeded getting an event
      if (e.type == SDL_JOYAXISMOTION) {
        should_publish = handleJoyAxis(e);
      } else if (e.type == SDL_JOYBUTTONDOWN) {
        should_publish = handleJoyButtonDown(e);
      } else if (e.type == SDL_JOYBUTTONUP) {
        should_publish = handleJoyButtonUp(e);
      } else if (e.type == SDL_JOYHATMOTION) {
        should_publish = handleJoyHatMotion(e);
      } else if (e.type == SDL_JOYDEVICEADDED) {
        handleJoyDeviceAdded(e);
      } else if (e.type == SDL_JOYDEVICEREMOVED) {
        handleJoyDeviceRemoved(e);
      } else {
        RCLCPP_INFO(get_logger(), "Unknown event type %d", e.type);
      }

This is from line 435 in: https://github.com/ros-drivers/joystick_drivers/blob/ros2/joy/src/joy.cpp

I believe it is falling through to printing out the info message

This is fixed in the latest sdl2-compat release, 2.32.54.

[slouken]

@Heisenborgar, the log message should be gone in the latest sdl2-compat release. Does that also fix the stuttering you were seeing?

[jfrancis71]

@slouken,

Based on your comment we have a new conda forge sdl2=2.32.54 and it does indeed fix the problem I was referring to. Thank you.

[slouken]

@slouken,

Based on your comment we have a new conda forge sdl2=2.32.54 and it does indeed fix the problem I was referring to. Thank you.

Glad to hear it. I'll wait to hear from @Heisenborgar before closing this bug.

[Heisenborgar]

Unfortunately it still doesn't work, and I verified it on both of my deck and laptop using the latest version. Maybe it's a different bug?

BTW, I find it odd that my steamdeck even without using my controller and only using the deck's gamepad controls also has this problem of cursor lagging or was stuck in it's last position since the touchpad or mouse has been moved.

Video sample below on a fresh install too: https://github.com/user-attachments/assets/af553bf2-7f48-4ee8-8932-ffddc79c768d

P.S: Idk if it's clear already, but if you look in the video where I specifically highlighted the "Agility" by moving the cursor there, you'll notice different things like "Strength, Intelligence" where highlighted but the cursor was still stuck in agility. Happens the same on the Steamdeck too

[Heisenborgar]

TBH I gave up, and I think my controller is the culprit (which it has various firmware versions in which I wouldn't mess with anyway). Using steam deck's controls while playing OpenMW are fine, but when I use my controller, the cursor thingy happens.

Let me know whether if I still have to proceed with this, though

[slouken]

The fact that it happens with two different controllers and one of them being an Xbox 360 controller makes me think it's probably not the controller. Those are usually pretty reliable.

However, Steam Deck doesn't have sdl2-compat installed by default, and certainly not in the environment which Steam uses when launching a game, so it sounds like this is happening with SDL2?

[Heisenborgar]

Could you point me on what things should I do next?

[slouken]

Here's the log of playing OpenMW with default install, no mods and SDL_EVENT_LOGGING=2 and the problem still happens: https://pastebin.com/curjhKMm

This shows it happening with SDL2, which means it's not an sdl2-compat issue, and likely a bug in OpenMW controller handling. The log message about unhandled SDL events was a red herring and not related to the controller input issue. Can you pass this information to the OpenMW developers for further investigation on their side?

[slouken]

I'm going ahead and closing this bug because the issue in the title is fixed for the next release.

If the OpenMW folks identify the control issue as being a bug in SDL, please feel free to open a new SDL2 bug or sdl2-compat bug, depending on where the issue is.