Based on the feedback from @protocultor:
- add the correct Hat mapping value ('h' and not 'hat')
- don't add automatically direction signs for axis mappings since they're only necessary in certain configurations.
However the info from the ES file is not enough to determine those configurations, though they seem to be an exception rather than the norm.
One case where the signs are needed seems to be when the D-Pad is mapped using axis, so that was left implemented.
New version needs WiringPi, but not the original version that got discontinued. There's an active fork of WiringPi which also provides `.deb` files, so check whether this new version is installed first before compiling locally a static version and using it.
Other modifications:
* modified the installation/build to use `$md_build` and handle the installation ourselves, instead of using the upstream `make` targets. This means the driver is copied to `/opt/retropie` (just like `xboxdrv`) instead of being located in `/usr/local`.
* added a `systemd` unit file to start the driver and don't rely on the upstream `rc.d` service scripts.
Added the ability for `runcommand` to load the SDL2 gamecontroller mappings created from the EmulationStation mappings and expose them as a SDL2 hint. Since the user may already have a mechanism to set the hint (from `.bashrc`/`.profile` or perhaps as part of the on-start scripts), don't overwrite the SDL2 hint if exists.
NB: since 2.0.22 the file containing the mappings can be set through the `SDL_HINT_GAMECONTROLLERCONFIG_FILE`, but to accomodate older SDL2 version, we're using `SDL_HINT_GAMECONTROLLERCONFIG` as a hint, which contains the actual mapping strings separated by newlines.
Added an input configuration script which will produce a SDL(2) gamecontroller mapping ([1]) based on the user's choices in the EmulationStation input configuration. The result of the mapping is saved in `/opt/retropie/configs/all/sdl2_gamecontrollerdb.txt`, which can be referenced by `runcommand` to load the mappings through SDL hints ([2] or [3]).
Since we're not trying to overwrite the existing built-in mappings, I've added a query method which needs `python3-sdl2` as dependency.
The mapping produced should follow the user's choices as far as inputs are concerned. The only 'outlier' is the 'hotkey enable' button, which is mapped to the 'Guide' SDL gamepad button IF its value is different than the _Select_ input. This way the extra button present on various gamepads (Xbox/PS) or a dedicated button chosen by the user can be mapped separately.
Ref:
[1] https://wiki.libsdl.org/SDL2/SDL_GameControllerAddMapping
[2] https://wiki.libsdl.org/SDL2/SDL_HINT_GAMECONTROLLERCONFIG
[3] https://wiki.libsdl.org/SDL2/SDL_HINT_GAMECONTROLLERCONFIG_FILE
The recent rebasing of the `xpad` driver onto the latest upstream version has added a new feature present only on 6.5+ kernels.
Back out that change so that we can still use the driver on older kernels and also pin the source to a repo commit, just to prevent a build failure in case upstream reverts also the offending changes.
NB: This should be just a temporary workaround until upstream fixes the compatibility, which may take some time.
Most likely the last v0.9.x release, followed by v0.10.x which will probably not use `dkms` for build/install.
Headlines:
* core, quirks: Add GameSir T4 Nova Lite support
* core, quirks: Add GuliKit KK3 MAX quirks
* core, quirks: Add heuristics to detect GameSir Nova controllers
* hid-xpadneo: Actually allow building with kernel 6.12
* hid-xpadneo: Allow building with kernel 6.12
* xpadneo, core: Add configuration for disabling Xbox logo shift-mode
* xpadneo, core: Fix coding style
* xpadneo, hidraw: Fixup previous commit to properly work with DKMS
* xpadneo, hidraw: Work around other software messing with our udev rules
* xpadneo, quirks: Let another Microsoft OUI bypass heuristics
* xpadneo, quirks: Prevent applying heuristics for some known vendors
VLC's MMAL video output doesn't detect which HDMI port is connected, as `omxplayer` did beforehand.
This results in a black screen instead of a splash video/image on a Pi4 where the display is connected to the 2nd HDMI port. Use `tvservice` when the MMAL video output is used to detect the connected screen and pass it on to `vlc`.
Since we're using just the Bourne shell, had to use `case` for wildcard comparison.
Do note that `CMD_OPTS` is modified during the installation of splashscreen, so it's not 100% guaranteed to stay empty.
There are 2 (uinput) related changes here:
* The SDL2/Uinput based Joy2Key is too slow for Pi1/0 devices, so allow the user to choose the older version. The older version is simpler since it doesn't need or load SDL2/Uinput, thus faster to load on those systems. By default, on ARMv6 devices the old version will be configured.
* The Uinput based event generation of keyboard events is not able to trigger the `runcommand` menu when launching images splash is done via `feh`, since the image display will get always have focus and thus the keybord events will not reach the `runcommand` terminal. So, in order for the `runcommand` menu to work after the splash image, make sure we stop `feh` before launch, just like `fbi` is stopped on non-desktop systems.
Upstream has re-organized the repository with the new versions for DB9/Gamecondriver and removed the version suffix from the source folders. Modified the module to fix the symlink to `/usr/src` needed by `dkms` and also fix the license URL.
Don't install the 05-splash.sh script to kill vlc on Raspberry Pi Buster and below. VLC on Buster on RPI4 will output to MMAL which can overlay on top of EmulatioStation.
Remove 05-splash.sh if already present on Buster.
Due to a recent merge of upstream code, the module no longer builds on Linux kernel 5.10, included in Raspberry Pi OS 'buster'.
The change needed to compile is minimal, it's caused by a missing event code from 'input-event-codes.h', part of the kernel's UAPI headers.
DKMS in Bookworm has a bug[1] where the autoinstall function on kernel updates fails due to a miscalculated version comparison, thinking always that the kernel version is newer than the custom version and skipping the installation. The message shown during upgrades is:
xpad.ko.xz:
Running module version sanity check.
Module version for xpad.ko.xz exactly matches what is already found in kernel
DKMS will not replace this module.
You may override by specifying --force.
Added a module version (copied from the `dkms.conf`'s package version) to have 'dkms' always install the out-of-tree version.
[1] https://github.com/dell/dkms/issues/296, fixed by https://github.com/dell/dkms/pull/297
omxiv / omxplayer only works on the Raspberry Pi legacy and fkms drivers.
This change switches to vlc for both utilities, as it supports mmal output on the Raspberry Pi legacy drivers, and drm output on KMS on Raspberry Pi OS (bullseye).
Remove dependencies for omxplayer / omxiv / insserv
Switch code to use vlc.
Run asplashscreen as $user (not root).
Remove wait for dbus (no longer needed)
Save vlc pid and Exit vlc before launching emulationstation on KMS
Pin vlc version on Buster to version from archive.raspberrypi.org to stop it being overwritten with the vanilla Debian security release.
Enable on 64bit Raspberry Pi OS
Fixes:
- settings the default sink (audio output) with `pactl` doesn't work like `pacmd`. The index of the sink is ignored and it's sink's `object.id` that's accepted by `pactl set-default-sink <id>`. As such, previous version didn't correctly set the audio output for Pipewire/Pulseaudio so a separate hash map was added to translate from `index` to the `object.id` of the sink.
- running `alsamixer` doesn't work correctly as `root` when Pipewire/Wireplumber are started as user services. Thus, run it as the install user in the Pulseaudio context
Tweaks:
- use `card.name` for the name of the card when listed in the dialog. This makes the name of the HDMI outputs nicer, instead of using the `alsa.name` property which outputs `MAI PCM i2s-hifi-0` as the card name (not very user friendly). With the new naming tweaks, the HDMI outputs are shown as `HDMI-0` or `HDMI-1`.
Due to changes in BlueZ added to fix CVE-2023-45866, the PS3 controllers won't pair/work anymore with BlueZ.
Since the path consist in only one change to default option (ClassicBondedOnly default changed, see [1]), it's been quickly added by all distros [2], [3].
This has already been reported in the forums and fixed (for Buster) by downgrading the `bluez` package. The same fix cannot be applied to current distros, so we can switch back the option to the way it works with PS3 controllers.
NOTE:
* while technically this make BlueZ vulnerable to CVE-2023-45866, the exploit mentioned works IIF BlueZ is set to 'discoverable' mode.
However, this mode is set only during discoveries, which in RetroPie means just the pairing dialog - I think the risk for a real break-in through the vulnerability described is very low. See [4] for an explanation of the conditions needed to exploit it on BlueZ and a PoC (which didn't work for me, despite having the vulnerable config in place).
* the configuration is set-up only when a PS3 pairing attempt is made.
* when removing a device, the vulnerable configuration will also be removed if no more PS3 paired devices are left.
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675
[2] https://ubuntu.com/security/CVE-2023-45866
[3] https://security-tracker.debian.org/tracker/CVE-2023-45866
[4] https://github.com/marcnewlin/hi_my_name_is_keyboard?tab=readme-ov-file#linux-keystroke-injection
The `xpad` kernel module is patched locally in order for the 'triggers_to_buttons' option to work on any supported controller. During installation, the option is also enabled automatically. Historically, this has been used to work-around EmulationStation not detecting the analog shoulder triggers, but the detection works now and this extra option is not needed for EmulationStation.
Leaving the option enabled by default has the side effect of breaking SDL's Gamecontroller API DB mappings (no of buttons and axis are different then the upstream mapping). Since more and more applications/games/emulators/etc. are using this SDL sub-system, it's better we don't enable it anymore.
This change removes the module configuration handled by the scriptmodule - both installation and removal. Users can manually add/remove the configuration if they wish.
Since the static binaries provided upstream are no longer working on newer RaspiOS or on 32bit ARM, create a standard scriptmodule to build Pegasus with `pegasus-fe-dev`. The new scriptmodule is meant to work similarly to the `es`/`es-dev` pair, only one can work at a time and they share a set of common functions.
Modified the original scriptmodule and added a theme download function, using @mmatyas's themes. More can be found at [2].
Notes:
* the `pegasus-fe` launcher doesn't need the previous TTY set-up, it's now handled by `runcommand`.
* sometimes the `/dev/dri/card0` is not the right card node since the order of the `cardX` inodes is not guaranteed.
Find the right card node dynamically (see [1]) and tell Qt about it with a minimal config file used in the launcher
[1] https://forums.raspberrypi.com/viewtopic.php?t=351263
[2] https://github.com/mmatyas/pegasus-theme-gallery-db/blob/master/repos.txt
