This makes it possibly to run Linux binaries compiled with udev support on
Linux systems which do not provide udev (typically systemd-less distros).
If udev is missing, we fall back to parsing `/dev/input` like when compiled
without udev support (`udev=no`).
Also adding some verbose debug statements to know which method we're using
when debugging Linux joypad issues.
The libudev so wrappers were generated on Mageia 8 with libudev 246.9 using
https://github.com/hpvb/dynload-wrapper:
```
./generate-wrapper.py --include /usr/include/libudev.h --sys-include '<libudev.h>' \
--soname libudev.so.1 --init-name libudev --omit-prefix gnu_ \
--output-header libudev-so_wrap.h --output-implementation libudev-so_wrap.c
```
(cherry picked from commits a10c259c1d
and e26a1f807b)
Edit: Updated to version 0.2 of dynload-wrapper to fix symbols clobbering as
done in #46143.
This is what GitHub Actions now provide and they removed the previous 21.3.6528147.
A bit annoying to have our hand forced this way but it's still 21.x so should be good
to upgrade.
(cherry picked from commit c730da8b20)
It appears that we can get a fun circle dependency on a shared object on
some system configurations causing issues with our 'fake' function
pointer names. This can lead to a crash.
The new wrapper generator renames all the symbols so this can't happen
anymore. See https://github.com/hpvb/dynload-wrapper/commit/704135e
Cherry-pick from 8d36b17343
By generating stubs using https://github.com/hpvb/dynload-wrapper we
can dynamically load libpulse and libasound on systems where it is available.
Both are still a build-time requirement but no longer a run-time dependency.
For maintenance purposes the wrappers should not need to be re-generated
unless we want to bump pulse or asound to an incompatible version. It is
unlikely we will want to do this any time soon.
cherry-pick from 09f82fa6ea
Valgrind reported two instances of reading uninitialized memory in the batching. They are both pretty benign (as evidenced by no bug reports) but wise to close these.
The first is that when changing batch from a default batch it reads the batch color which is not set (as it is not relevant for default batches). The segment of code is not necessary when it has already deemed a batch change necessary (which will occur from a default batch). In addition this means that the count of color changes will be more accurate, rather than having a possible random value in.
The second is that on initialization _set_texture_rect_mode is called before the state has been properly initialized (it is initialized at the beginning of each canvas_begin, but this occurs outside of that).
The font size of the Find in Files dialog used to get out of sync with
the code editor font size.
The font of the Find in Files dialog is now updated each time there is a
change to the theme. This way, the font size of the Find in Files
results changes in response to the code font size being changed using
Ctrl +/- or using the Editor Settings.
Fixes#35499
(cherry picked from commit 011fdece6d)
