Touch screen not working with new build.

[gwaland]

My touch screens are no longer working with the latest updates. I tested with the 2021623 debian build and they are working. when I build the latest from source they become unreactive.

I've attempted to use it as a mouse by setting touchscreen=0. the mouse pointer does not respond without touch enabled.

[gwaland]

ee.log
X.log

[gwaland]

So weird discovery. If touchscreen=1 I can select by using a 2 button press. I'm guessing it's a side effect of this being designed for non-multitouch screens?

[daid]

I think this could be very well be solved in the latest build, as there have been many changes and cleanup to the input system.

[gwaland]

So I'm just getting this setup again. on the latest official build and on the latest git this still seems to be happening. I can select if I double click with 2 fingers.

I'm trying to setup input logging that was recommended when I was working on this last year but I'm finding my coding skills in this case to be lacking.

I'll keep poking at it.

[gwaland]

I've been going back through commits trying to find where it actually broke. Right now it looks like it broke right after the SDL 2 migration as suspected.

I've traced it back to these commits:
serious proton: 6e83c28e7f01b9fddd5b88678710912f6f3a0ce9
ee: cde6389

interestingly, in these commits single pressing will highlight the button I want to press then using 2 fingers it will select like I clicked so it's still seeing the input on this commit, just not treating it like a click.

[gwaland]

I found a post on discord I missed with instructions for logging. I'm back to trying to fix this again. Sorry to spam this.

[WarlockD]

I think I located most of the issues with this. Many of the gui button presses ignore the ID of the press and just return true when pressed. Using two fingers sends two signals and it also gets two singlas when fingers are are removed. No real way to track this however as the gui bits do not record the state of the finger presses individualy. Might fidle with it, I got me one of those dell touch screen pc's I gave to my grandma so it should be fully compatable to how SDL2 does it.

[gwaland]

So I've finally managed to finagle ints out of Serious Proton for my touch screen.
https://github.com/daid/SeriousProton/blob/b059605c011ae1a7d6ea222f18f71ff076829373/src/io/keybinding.cpp#L518
At this line I added the following above the switch:
std::string event_type = std::to_string(event.type);
LOG(INFO) << "keybindings: " + event_type;
I also added some log info lines at finger down and finger up.
So now when I press the screen I get this output:
INFO: keybindings: 1025
INFO: keybindings: 1026

for the down and up events.
and the double click which triggers the FINGERDOWN/FINGERUP I get this:
INFO: keybindings: 1792
INFO: finger down keybingings.cpp
INFO: keybindings: 1026
INFO: keybindings: 1793
INFO: finger up keybingings.cpp

Which looks like those are mouse down and mouse up events?
I'm confused again as to why it's not working.

[oznogon]

1792 and 3 are SDL_FINGERDOWN and SDL_FINGERUP, respectively.

1025 and 6 are SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP, respectively.

I would want to know which button event is being passed by SDL_MOUSEBUTTONDOWN/UP at the point when you're collecting the event type. I'd typically expect a single-finger touch to send a left click and a two-finger touch to send a right click, but maybe that's reversed here, or they're sending unexpected buttons.

---

https://wiki.libsdl.org/SDL2/SDL_MouseButtonEvent:

button may be one of:

SDL_BUTTON_LEFT
SDL_BUTTON_MIDDLE
SDL_BUTTON_RIGHT
SDL_BUTTON_X1
SDL_BUTTON_X2

which may be SDL_TOUCH_MOUSEID, for events that were generated by a touch input device, and not a real mouse. You might want to ignore such events, if your application already handles SDL_TouchFingerEvent.

---

SP handles each button as a different io::Pointer event in Keybinding::handleEvent:

    case SDL_MOUSEBUTTONDOWN:
        {
            io::Pointer::Button button = io::Pointer::Button::Unknown;
            switch(event.button.button)
            {
            case SDL_BUTTON_LEFT: button = io::Pointer::Button::Left; break;
            case SDL_BUTTON_MIDDLE: button = io::Pointer::Button::Middle; break;
            case SDL_BUTTON_RIGHT: button = io::Pointer::Button::Right; break;
            case SDL_BUTTON_X1: button = io::Pointer::Button::X1; break;
            case SDL_BUTTON_X2: button = io::Pointer::Button::X2; break;
            default: break;
            }
            if (button != io::Pointer::Button::Unknown)
                updateKeys(int(button) | pointer_mask, 1.0);
        }
        break;

[gwaland]

INFO: keybindings timestamp: 17317
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 958
INFO: keybindings y: 549
INFO: keybindings type: 1025
INFO: keybindings timestamp: 17851
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 958
INFO: keybindings y: 549
INFO: keybindings type: 1025
INFO: keybindings timestamp: 18351
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 958
INFO: keybindings y: 549
INFO: keybindings type: 1025
INFO: keybindings timestamp: 18900
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 958
INFO: keybindings y: 549

So here's the output from clicking around a couple of parts of the screen. Interestingly it appears that the system thinks I'm always clicking at 958:549.

Here's output from a mouse click a few places on the screen for comparison:

NFO: keybindings type: 1025
INFO: keybindings timestamp: 20351
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 2
INFO: keybindings x: 958
INFO: keybindings y: 549
INFO: keybindings type: 1025
INFO: keybindings timestamp: 75917
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 751
INFO: keybindings y: 4
INFO: keybindings type: 1025
INFO: keybindings timestamp: 94134
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 245
INFO: keybindings y: 0
INFO: keybindings type: 1025
INFO: keybindings timestamp: 94868
INFO: keybindings windowID: 2
INFO: keybindings which: 0
INFO: keybindings button: 1
INFO: keybindings state: 1
INFO: keybindings clicks: 1
INFO: keybindings x: 866
INFO: keybindings y: 384

So I'm not sure what's going on there. Just to make sure something else hadn't broken it I removed my test deb and installed the Linux_EmptyEpsilon_EE-2021.06.23.deb that previously worked before the SDL2 upgrade and it's still working as expected.

[oznogon]

Can you dump the diff you're using to test in a comment so I can reproduce and play around with this? There are a ton of variables and I can't reproduce the behavior yet, so I'm poking around blindly and it'd help to confirm exactly where these logged values are coming from.

I feel like I'm safely assuming it's from the SDL event, but SP has its own Button enum, SDL can report position coordinates differently for touch and mouse, and there are some variable outcomes depending on SDL version (ie. EE 2022.10.28 for Windows bundles a 2.0.16 DLL, Ubuntu 22.04 ships 2.0.20, SDL2 2.0.22 fixes and breaks a bunch of touch/mouse emulation, like libsdl-org/SDL#5652 and libsdl-org/SDL#4518).

[oznogon]

Also,

• are you in windowed mode or full screen?
• multi-monitor or single monitor?
• running plain X11 or Wayland/XWayland?
• got Windows on the same device? if so, is the Windows 2022.10.28 build affected?
• what's the brand/model of the touch device? I fished the driver-reported device name out of the X.log, but Googling it seems to be used in a wide range of things, from laptops to standalone monitors to advertising signage

[gwaland]

• Full screen with no window manager.
• Xorg/X11
• I installed windows 10 on one of the touch systems to see if it had any issues and it doesn't appear that this touch issue affects the windows client, however the 3Gigs of RAM in the clients makes them really not happy to run windows 10.
• the monitors are acer ut220hql screens
• lsusb -v output shows it has an SIS hid controller in it:
  root@ee-client:/tmp# lsusb -v -s 001:004

Bus 001 Device 004: ID 0457:1122 Silicon Integrated Systems Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0457 Silicon Integrated Systems Corp.
idProduct 0x1122
bcdDevice 3.00
iManufacturer 1 USBest Technology
iProduct 2 SiS HID Touch Controller
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 748
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1

[oznogon]

Dug up a touchscreen Lenovo P40 (Wacom digitizer supporting finger input) running pop_OS! 22.04 and built EE on it off the master branch. It seems to register only fingerdown/up on the touchscreen, no mouse events.

SDL 2.0.20, X11, GNOME 3, with this SeriousProton patch:

diff --git a/src/io/keybinding.cpp b/src/io/keybinding.cpp
index 3c7584f..21fc213 100644
--- a/src/io/keybinding.cpp
+++ b/src/io/keybinding.cpp
@@ -527,6 +527,7 @@ void Keybinding::handleEvent(const SDL_Event& event)
         break;
     case SDL_MOUSEBUTTONDOWN:
         {
+            LOG(INFO) << "SDL_MOUSEBUTTONDOWN button: " << (int)event.button.button << "\nx.y: " << event.button.x << "," << event.button.y << "\nwhich: " << event.button.which << "\nclicks:" << event.button.clicks << "\nwindowID: " << event.button.windowID;
             io::Pointer::Button button = io::Pointer::Button::Unknown;
             switch(event.button.button)
             {
@@ -543,6 +544,7 @@ void Keybinding::handleEvent(const SDL_Event& event)
         break;
     case SDL_MOUSEBUTTONUP:
         {
+            LOG(INFO) << "SDL_MOUSEBUTTONUP button: " << (int)event.button.button << "\nx.y: " << event.button.x << "," << event.button.y << "\nwhich: " << event.button.which << "\nclicks:" << event.button.clicks << "\nwindowID: " << event.button.windowID;
             io::Pointer::Button button = io::Pointer::Button::Unknown;
             switch(event.button.button)
             {
@@ -595,10 +597,12 @@ void Keybinding::handleEvent(const SDL_Event& event)
         break;
     case SDL_FINGERDOWN:
         //event.tfinger.x, event.tfinger.x
+        LOG(INFO) << "SDL_FINGERDOWN event.tfinger.x,y: " << event.tfinger.x << " " << event.tfinger.y << "\ntouchId: " << event.tfinger.touchId << "\nfingerId: " << event.tfinger.fingerId << "\nwindowID: " << event.tfinger.windowID;
         updateKeys(int(io::Pointer::Button::Touch) | pointer_mask, 1.0);
         break;
     case SDL_FINGERUP:
         //event.tfinger.x, event.tfinger.x
+        LOG(INFO) << "SDL_FINGERUP event.tfinger.x,y: " << event.tfinger.x << " " << event.tfinger.y << "\ntouchId: " << event.tfinger.touchId << "\nfingerId: " << event.tfinger.fingerId << "\nwindowID: " << event.tfinger.windowID;
         updateKeys(int(io::Pointer::Button::Touch) | pointer_mask, 0.0);
         break;
     case SDL_JOYBUTTONDOWN:

I get output like this using trackpad input only:

INFO: SDL_MOUSEBUTTONDOWN button: 1
x.y: 600,284
which: 0
clicks:1
windowID: 2
INFO: SDL_MOUSEBUTTONUP button: 1
x.y: 600,284
which: 0
clicks:1
windowID: 2
INFO: SDL_MOUSEBUTTONDOWN button: 1
x.y: 1009,488
which: 0
clicks:1
windowID: 2
INFO: SDL_MOUSEBUTTONUP button: 1
x.y: 1009,488
which: 0
clicks:1
windowID: 2

All mousebutton events, no fingerdown/up.

I get this from touchscreen finger input only:

INFO: SDL_FINGERDOWN event.tfinger.x,y: 0.23 0.17
touchId: 10
fingerId: 103
windowID: 2
INFO: SDL_FINGERUP event.tfinger.x,y: 0.23 0.19
touchId: 10
fingerId: 103
windowID: 2
INFO: SDL_FINGERDOWN event.tfinger.x,y: 0.63 0.68
touchId: 10
fingerId: 104
windowID: 2
INFO: SDL_FINGERUP event.tfinger.x,y: 0.63 0.68
touchId: 10
fingerId: 104
windowID: 2

All fingerdown/up, no mousebutton events registered.

EDIT: Same behavior with the same patch on an aarch64 ChromeOS touchscreen device in Crostini/"Linux container" mode. Trackpad reports mousebutton events only, touchscreen reports fingerup/down events only.

Didn't get logs but I've not seen weird touch behavior on several Android phones and tablets, with or without keyboards involved.

I suspect that either the touchscreen device is doing something unusual and SFML allowed/ignored it but SDL doesn't, or you've got a specific set of circumstances between installed SDL libs and drivers that I don't have any way to reproduce.

[gwaland]

Yeah that's what I expect too. But with these displays at least the finger only events only happen with 2 or more fingers pressed.

[oznogon]

This might be something: there were three models of that display, one with a standard SiS digitizer, and one with an optical TPV digitizer, and one with a TPV driver that had a relative mouse mode, where the touch device behaved like a joystick: https://forum.odroid.com/viewtopic.php?p=115380&sid=27193017ee17c72834ef3e95e4477ab5#p115380

• Tap would return the "center" coordinates and click whatever's under the cursor.
• Tap and drag would return a vector that would move the mouse cursor in that direction and not pass a click.

This mode was inherently not multitouch, so putting a second finger on the display passes a normal touch event.

If i Disconnect the Usb cable and reconnect it everything is working as it should.
OR: If I connect the usb cable once the odroid is fully booted it works as it should.

In this case, I think that behavior is either coming from the device or the kernel. Why SFML ever worked with it, I don't know.

cf. https://wiki.libsdl.org/SDL2/SDL_SetRelativeMouseMode

[gwaland]

Yeah I dunno. I'm guessing SFML just pulled from the standard X input? I'm currently installing ubuntu 22.04 on the sd card for the hp T610 and the touch screen is registering just fine for the install.

[gwaland]

So I'm fairly confident it's got to be something in the minimal configuration that's causing the events to not read right. I did a full desktop install of ubuntu 22.04 and installed my logging version of EE on the system and the touch screen appears to work with the fingerup and fingerdown code that exists.

Now I just have to figure out what the full desktop experience has installed that's missing.

[oznogon]

I wonder if there's a difference using a minimal WM, like openbox? SDL has some checks for whether a window manager's in use.

[daid]

On linux, with evtest you can check what kind of events the driver is generating. That will also be interesting to see. As this bypasses X11, SDL2 and EE.

Also, which SDL2 version is your linux system running? This could just be an SDL2 bug that is fixed upstream.

[gwaland]

I played with evtest last night before bed. If I run it with no window manager it gives me the same output we're seeing in EE, (x,y always 958,459). I get the same with TWM. but as soon as I moved up to icewm it switched from from mouse button at 948,459 to touch at the correct coordinates. So there's SOMETHING getting flipped with the window managers. So now my hunt is for a small window manager that will autostart the ee script I have and doesn't need to write to the file system since this is for an environment where only /tmp is writeable. :p But I've made a ton of progress on this thorn in my side the last few days. Thank you for the help. :)

[daid]

I am surprised Xorg has influence on input events like that...

[gwaland]

Yeah I'm not sure what's going on but I'm not going to question it after how long I've been fighting this. :p

I've now got icewm starting underneath the application and the touch screens are functioning as expected. As such I'm going to close this issue.

Thanks again.

[oznogon]

From evtest's man page:

The output of evtest shows the information presented by the kernel; based on this information it can be determined whether the bug may be a kernel or an X.org issue.

If nothing's changing in the kernel and nothing's changing in the device, then evtest behavior changing with the WM don't make much sense.

There might be two differently behaving driver layers, the kernel (evdev) and Wayland-derived libinput (xf86-input-libinput, "the driver for input devices using libinput library. It can handle keyboards, mice and touchpads, and essentially replaces the separate -evdev and -synaptics drivers").

So I'm curious if some WMs, or even your minimal environment, use or install xf86-input-libinput, and if so whether its presence has any correlation to whether touch works.

(SDL had known issues with libinput and ibus, including duplicated events, and - again - I'm still very very very curious what version of SDL you're using to build, because some of those issues are also fixed or introduced in SDL 2.0.22. )

libinput provides some troubleshooting tools: https://wayland.freedesktop.org/libinput/doc/latest/tools.html

If libinput's already installed I'd especially be interested in the output of

sudo libinput list-devices
sudo libinput list-kernel-devices --hid

and then the output of running sudo libinput debug-events --verbose (which captures libinput's events) and tapping, and then sudo libinput record for the touch device (which captures kernel events) and tapping.

EDIT: Started writing this before it got closed, but if you reopen this, I'd still be curious.

EDIT: The X.org log linked in the ticket suggests libinput was present:

[    21.052] (II) config/udev: Adding input device USBest Technology SiS HID Touch Controller (/dev/input/event2)
[    21.052] (**) USBest Technology SiS HID Touch Controller: Applying InputClass "libinput touchscreen catchall"
[    21.052] (II) Using input driver 'libinput' for 'USBest Technology SiS HID Touch Controller'

[gwaland]

I don't pretend to understand what's happening. I just know when it was just xterm and evdev with no WM I got one output and when it was icewm and evdev I got another. But it's been 2 years of fighting with it to get it to work so now that it works I'm ready to quit thinking about it. :p

Well that was a pain. the libinput command wasn't installed so I had to go chase down what provided it.

root@ee-client:~# sudo libinput list-devices
Device: Power Button
Kernel: /dev/input/event1
Group: 1
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: Power Button
Kernel: /dev/input/event0
Group: 2
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: HD-Audio Generic HDMI/DP,pcm=3
Kernel: /dev/input/event12
Group: 3
Seat: seat0, default
Capabilities:
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SEM USB Keyboard
Kernel: /dev/input/event2
Group: 4
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SEM USB Keyboard Consumer Control
Kernel: /dev/input/event3
Group: 4
Seat: seat0, default
Capabilities: keyboard pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: disabled
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SEM USB Keyboard System Control
Kernel: /dev/input/event4
Group: 4
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SINO WEALTH Gaming KB
Kernel: /dev/input/event6
Group: 5
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SINO WEALTH Gaming KB System Control
Kernel: /dev/input/event7
Group: 5
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SINO WEALTH Gaming KB Consumer Control
Kernel: /dev/input/event8
Group: 5
Seat: seat0, default
Capabilities: keyboard pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: disabled
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: SINO WEALTH Gaming KB Keyboard
Kernel: /dev/input/event9
Group: 5
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: Optical Mouse
Kernel: /dev/input/event10
Group: 6
Seat: seat0, default
Capabilities: pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: disabled
Nat.scrolling: disabled
Middle emulation: disabled
Calibration: n/a
Scroll methods: button
Click methods: none
Disable-w-typing: n/a
Accel profiles: flat *adaptive
Rotation: n/a

Device: USBest Technology SiS HID Touch Controller
Kernel: /dev/input/event5
Group: 7
Seat: seat0, default
Size: 455x273mm
Capabilities: touch
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: identity matrix
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: HDA ATI SB Mic
Kernel: /dev/input/event13
Group: 3
Seat: seat0, default
Capabilities:
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: HDA ATI SB Headphone
Kernel: /dev/input/event14
Group: 3
Seat: seat0, default
Capabilities:
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Device: HP WMI hotkeys
Kernel: /dev/input/event11
Group: 8
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

root@ee-client:# sudo libinput list-kernel-devices --hid
libinput: list-kernel-devices is not a libinput command or not installed. See 'libinput --help'
root@ee-client:#

the SDL versions of the two build environments I used:

ii libsdl2-2.0-0:amd64 2.0.10+dfsg1-3 amd64 Simple DirectMedia Layer
ii libsdl2-dev:amd64 2.0.10+dfsg1-3 amd64 Simple DirectMedia Layer development files

ii libsdl2-2.0-0:i386 2.0.14+dfsg2-3+deb11u1 i386 Simple DirectMedia Layer
ii libsdl2-dev:i386 2.0.14+dfsg2-3+deb11u1 i386 Simple DirectMedia Layer development files