SUMMARY Please take a look at this video I made for a visual representation: https://www.youtube.com/watch?v=n-cctsml6qk&feature=youtu.be My PS4 controller works fine, but I noticed the joystick KCM seems to update the position of the stick slowly. I don't know, it's almost looks like it's smoothing the values. You can see on the video both the crosshair and the values go back to zero slowly. It makes no sense to have a KCM to test your controller if it can't show the values accurately. PS: The controller is connected through USB, not bluetooth, so it shouldn't show any delay. It works normally with games too, so I suppose this is a bug with KDE. STEPS TO REPRODUCE 1. Connect game controller (the controller won't show up if the joystick KCM is already open, it needs to be reloaded to detect the controller) 2. Open up system settings and go to Input Devices >> Game Controller 3. Move analog stick OBSERVED RESULT When you look at the crosshair and the raw values, will notice they take some time to catch up with the real inputs. If you move too fast it will just skip around. EXPECTED RESULT It should show accurate values in real time. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.74.0 Qt Version: 5.14.2 Kernel Version: 5.4.0-42-generic OS Type: 64-bit Processors: 6 × Intel® Core™ i5-9400F CPU @ 2.90GHz Memory: 7.7 GiB of RAM Graphics Processor: Radeon RX 570 Series
I can also reproduce this with a cheaper USB gamepad. I noticed my input lag scales around linearly with the KCM window size, so I think it might be something interface rendering related. (Unlimited hammering of the axis table view with new values?) Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-25-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i3-5010U CPU @ 2.10GHz Memory: 7.7 GiB of RAM Graphics Processor: GeForce 920M/PCIe/SSE2
I can confirm this happening for me 100% of the time, also feeling fine in games or real use but just being 'delayed' in the settings panel. I've also noticed that any of the button presses + the dpad (which shows up as an axis, to mix this all up) are all instant when pressed themselves, but if any analog value is being pressed (sticks or the triggers) then the button+dpad presses come in 'smoothed' like the axis graph. Operating System: EndeavourOS KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.14-209-tkg-bmq (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: Radeon RX 570 Series
It happens to me with an Xbox Elite Series 2 plugged via USB cable. I haven't looked into the code, but it feels like the controller sends events faster than the applet can process in real time, and the events get buffered in a queue, which causes the delay in the UI. It's bad to the point that this KDE applet can't be trusted to check if a controller is responding properly. jstest-gtk is an alternative which gives much better response, so we can confirm that it is an issue with this KDE module.
Additionally, I've noticed that if you press and release several buttons at the same time, a few of them sometimes appear 'stuck' in System Settings unless you press them again. I agree that it looks like it's trying to process all events in a queue and getting bogged down, instead of displaying the current status every few milliseconds. This is further backed up by how it lags behind while moving a control stick, but sometimes the 'snap' back to a neutral position is almost instant.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1360
Git commit 7d4a79afac02c0db7ef69bd31018ccbe16280299 by Bartosz Taudul. Committed on 04/02/2023 at 01:19. Pushed by redstrate into branch 'master'. kcms/joystick: process all available events Processing of joystick events is performed in a response to a zero-timeout timer. Previously only one event was handled when the timer fired. The 10 ms timeout of the select call checking if there are events to process prevented 100% CPU usage of a constantly firing timer. The problem with such an approach is that joystick events are visibly slow to process and show up in the buttons and axis readout. In some cases they are even lost. It is not clear why this happens, my guess would be that each update of the button or axis state in the UI triggers a redraw, which then waits for VSync, preventing the timer from running. This commit changes the event processing logic to run until there are no events left to consume. This requires zeroing of the select call timeout, as otherwise a joystick emitting events every 9 ms would be able completely block the UI. To prevent 100% CPU usage, 10 ms sleep calls are issued when the event queue is empty. This has similar effect as the previous 10 ms select timeout. Changes in the joystick calibration dialog are minimal, as I don't have use for it. The behavior there shouldn't be degraded, but that's it. FIXED-IN: 5.27 M +4 -1 kcms/joystick/caldialog.cpp M +1 -1 kcms/joystick/joydevice.cpp M +24 -18 kcms/joystick/joywidget.cpp https://invent.kde.org/plasma/plasma-desktop/commit/7d4a79afac02c0db7ef69bd31018ccbe16280299
Git commit 575e99f5af5e9204b22d7a8bd8e7e9757af05e4f by Joshua Goins, on behalf of Bartosz Taudul. Committed on 04/02/2023 at 01:50. Pushed by redstrate into branch 'Plasma/5.27'. kcms/joystick: process all available events Processing of joystick events is performed in a response to a zero-timeout timer. Previously only one event was handled when the timer fired. The 10 ms timeout of the select call checking if there are events to process prevented 100% CPU usage of a constantly firing timer. The problem with such an approach is that joystick events are visibly slow to process and show up in the buttons and axis readout. In some cases they are even lost. It is not clear why this happens, my guess would be that each update of the button or axis state in the UI triggers a redraw, which then waits for VSync, preventing the timer from running. This commit changes the event processing logic to run until there are no events left to consume. This requires zeroing of the select call timeout, as otherwise a joystick emitting events every 9 ms would be able completely block the UI. To prevent 100% CPU usage, 10 ms sleep calls are issued when the event queue is empty. This has similar effect as the previous 10 ms select timeout. Changes in the joystick calibration dialog are minimal, as I don't have use for it. The behavior there shouldn't be degraded, but that's it. FIXED-IN: 5.27 (cherry picked from commit 7d4a79afac02c0db7ef69bd31018ccbe16280299) M +4 -1 kcms/joystick/caldialog.cpp M +1 -1 kcms/joystick/joydevice.cpp M +24 -18 kcms/joystick/joywidget.cpp https://invent.kde.org/plasma/plasma-desktop/commit/575e99f5af5e9204b22d7a8bd8e7e9757af05e4f