https://bugs.kde.org/show_bug.cgi?id=524082
--- Comment #3 from Ivaylo Georgiev <[email protected]> --- Update as promised in comment 2 — I found the dominant cause of the stall on my machine, and it is neither the KCM's SDL flags per se nor the udev lookups: a failing USB3 link. This likely also explains why it doesn't reproduce on healthy systems (comment 1). Isolation, using a minimal test program that only calls SDL_Init(SDL_INIT_GAMECONTROLLER), no GUI: - default environment: 12-16 s - SDL_JOYSTICK_DISABLE_UDEV=1 alone: no improvement (~13 s), so the udev cost from SDL#9092 was NOT the main contributor here - SDL_JOYSTICK_HIDAPI=0: 0.06 s - SDL_HIDAPI_LIBUSB=0 alone: 0.10 s -> the entire stall is inside SDL's bundled libusb HID backend The system's hidapi (hidraw backend) and system libusb enumerate the same devices in under 0.01 s. Sampling /proc/<pid>/wchan during the stall shows the thread blocked in bConfigurationValue_show, i.e. a sysfs attribute read. SDL's vendored libusb is built without udev support, so its hid_enumerate reads USB descriptors/attributes directly from sysfs, and those reads take the kernel's per-USB-device lock. The lock holder: the kernel had been logging "usb usb2-port1: Cannot enable. Maybe the USB cable is bad?" every 4 seconds (55000+ messages over 3 days) — a USB3 hub whose SuperSpeed link fails to train. Its USB2 side works fine, so all devices on it function normally and nothing visibly misbehaves; the hub driver just retries the SS link forever, holding the root hub's device lock, and SDL's sysfs read blocks behind it for many seconds. Confirmation: after disabling the SuperSpeed side of that port (echo 1 > /sys/bus/usb/devices/usb2/2-0:1.0/usb2-port1/disable), SDL_Init dropped from ~15 s to 0.10 s with no SDL hints/env vars at all, and System Settings cold starts instantly. One caveat: my journal shows the port retries only began on Aug 14, while the original 12.3 s measurement in this report is from Aug 9, so slow HIDAPI probing can evidently also happen without a wedged link (hardware-dependent, as described). But for a reliable, extreme reproduction: plug in a USB3 hub/device with a marginal SuperSpeed connection (kernel spamming "Cannot enable" while USB2 still works) and the multi-second SDL_Init should appear immediately. The architectural point stands regardless of what makes enumeration slow on a given machine: a blocking SDL_Init on the System Settings main thread turns any USB subsystem hiccup into a 10+ second frozen window for the entire application. Running the game-controller relevance check asynchronously / off the main thread would make startup robust against this whole class of stalls. -- You are receiving this mail because: You are watching all bug changes.
