I believe there was a O(n^2) device walking issues on startup
- MaybeAddDevice gets called for every device at startup
- MaybeAddDevice calls IsJoystick
- IsJoystick calls SDL_UDEV_GetProductInfo
- SDL_UDEV_GetProductInfo calls udev_enumerate_scan_devices
- udev_enumerate_scan_devices walks all the devices
Prior to commit 3b1e0e1 this was mostly masked as IsJoystick only
called SDL_UDEV_GetProductInfo when a JSIOCGNAME ioctl was
successful. This fixes the O(n^2) behaviour by directly getting
the device via udev_device_new_from_devnum (based on type, major,
and minor number) instead of enumerating everything via
udev_enumerate_scan_devices and matching on name.
The udev container issue is mostly to do with device notifications
and netlink. The device classification stuff just pokes file in /sys
and /run/udev. Doesn't hurt to try it first for classifying joysticks
and then fall to the guess heuristics if it fails.
This means the allocator's caller doesn't need to use SDL_OutOfMemory directly
if the allocation fails.
This applies to the usual allocators: SDL_malloc, SDL_calloc, SDL_realloc
(all of these regardless of if the app supplied a custom allocator or we're
using system malloc() or an internal copy of dlmalloc under the hood),
SDL_aligned_alloc, SDL_small_alloc, SDL_strdup, SDL_asprintf, SDL_wcsdup...
probably others. If it returns something you can pass to SDL_free, it should
work.
The caller might still need to use SDL_OutOfMemory if something that wasn't
SDL allocated the memory: operator new in C++ code, Objective-C's alloc
message, win32 GlobalAlloc, etc.
Fixes#8642.
This call is actually a left-over when porting from fcitx4 service to the new org.freedesktop.portal.Fcitx supported by both fcitx4/fcitx5. CloseIC is actually never a part of the new interface on org.freedesktop.portal.Fcitx. It cause any issue user visible effect.
On 32-bit platforms such as i386, if SDL is compiled with -D_TIME_BITS=64
to opt-in to ABIs that will not stop working in 2038, the fields in
this struct change their naming and interpretation.
The Linux header <linux/input.h> defines macros input_event_sec and
input_event_usec which resolve to the right struct field to look at.
The actual field names and types are an implementation detail,
historically signed 32-bit time.tv_sec and time.tv_usec on 32-bit
platforms, but becoming unsigned __sec and __usec when using 64-bit
time (which makes them able to represent times up to 2106).
Signed-off-by: Simon McVittie <smcv@collabora.com>
It is possible for retrieving the machine ID to fail, either because
dbus was installed incorrectly (machine ID absent or corrupt), or in
32-bit builds, because stat() on the machine ID fails with EOVERFLOW
if it has an out-of-range timestamp or inode number.
dbus has historically treated this as a faulty installation, raising
a warning which by default causes the process to crash. Unfortunately,
dbus_get_local_machine_id() never had a way to report errors, so it has
no alternative for that (bad) error handling.
In dbus >= 1.12.0, we can use dbus_try_get_local_machine_id() to get
the same information, but with the ability to cope gracefully with
errors. ibus won't work in this situation, but that's better than
crashing.
Mitigates: https://github.com/ValveSoftware/steam-for-linux/issues/9605
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a device is positively identified as an accelerometer, pointing stick
or clickpad, then we don't need to second-guess it.
In practice this does not change the result for any device in our
test data, so add some artificial records that exercise this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
