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: cde63895a2d47780de0ec5e09bbd894007d23387

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