If Samba is running (and it is by default) the service is advertised using mDNS via Avahi which helps Linux/macOS devices see the shares, and we also have WSDD2 which broadcasts in the modern format used by Windows.
If you don't need Samba shares turn the service off (10 seconds effort). If you do, configure a user/password credential (30 seconds).
I'm not seeing errors or warnings in the Xorg log and if you're seeing a mouse pointer that suggests Xorg is up/running. The Q is then why Kodi isn't rendering the GUI to the windowmanager?
At mglae suggestion I've made another VAAPI change, so please do the following:
a) Download the latest .tar file from my test share to /storage/.update
b) Create /storage/.kodi/userdata/advancedsettings.xml with this content to enable debug logging
<?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
<!-- enable debug logging -->
<loglevel hide="false">1</loglevel>
</advancedsettings>c) Reboot to initiate the update, then run "pastekodi" to share the system log and Kodi log.
The issue has nothing to do with passphrase characters and it's definitely influenced by signal strength. The error message shown is probably the result of an error handling failure in iwd code. Instead of correctly catching the error and failing gracefully with a meaningful message you end up falling-through to a unintended wrong point in code and seeing "invalid key" instead.
The Amlogic S922X chip in DreamBox I/II devices have HDR to SDR conversion capabilties in hardware, but software support for this is not currently implemented in the upstream Linux kernel used with the AMLGX image.
Kodi supports forced tonemapping in Windows and Android devices should support it subject to underlying hardware support. The Shield does handle conversion. Linux support for colorimetry changes in upstream kernels is currently rather limited. CE images that use Amlogic vendor kernels should support conversion, but CE is someone else's problem (we don't track their releases or state) so you need to visit their forum for info.
The image I posted to my share yesterday morning addresses udev and adds VAAPI support .. I'd already spotted those 
I've squashed/pushed the current changes to https://github.com/chewitt/LibreELEC.tv/commits/nouveau
I was using a GBM based LE master OVA under ESXi over Christmas to poke ideas for tailscale support. ESXi != Workstation/Fusion but no issues seen, so if we broke something it's either a very recent change or something specific to Workstation.
Nothing was breached. LE intentionally ships with Samba enabled to mitigate support issues with typically low/no Linux skilled users and the default shares expose /storage/.kodi/userdata where Kodi subsequently stores passwords in cleartext. You can either disable Samba in the LE settings add-on (as you didn't choose to disable it when prompted during the first-run wizard) or you can configure a credential so there is no open access to the Samba shares.
NB: I'll take an action to formally document our insecurities in the wiki alongside installation instructions. They are widely discussed in the forum for anyone searching for info, but not the wiki.
I wouldn't expect any real-world differences between releases as nothing on the kernel side has really changed (nobody did any real work on the decoders since 2020). That said, Kodi and ffmpeg versions changed so it's not impossible. Seeking is generally okay on H264 in my testing, but the decoders are all known to be imperfect, and there are some unresolved memory buffer management issues that when provoked with lots of stop/start/seek activity will leave the decoder driver in a bad state, although I've not see any Kodi crash/restarts from them.
The sole real-world decoding change is https://github.com/chewitt/linux/…aa21f07ee54d028
I am surprised about the [DEPEND] Dependency failed for windowmanager.service I have seen one time. I did not expect gbm needs an X-server and the X-server needs a window manager (or maybe a display manager?).
I also should expect Kodi should be compiled against gl instead of gles.
The first image I shared was GBM based but after having suspicions on GLES support I switched to X11/GL, and we use fluxbox as a minimal window manager (Xorg requires there to be one).
If you stop xorg.service and manually run /usr/bin/xorg-launch -nolisten tcp vt01 -logverbose 6 -verbose 6 what output do you get on the console?
You can create /storage/.config/udev.rules.d/98-eventlircd.rules with the changes and reboot, or update to the nightly. I wouldn't worry about stability with LE12 nightlies as we don't bump much in release branches. Most changes are for add-ons.
Disabling WiFi isn't going to help with the 2.4GHz device when USB 3.0 is the source of issues.
If the media is 1080p it's unlikely to be an HDMI bandwidth issue unless you're using a particularly rubbish cable. However, 1080p content is normally 8-bit not 10-bit which suggests media has been intentionally encoded that way, which opens the door to people using exotic encoding configs, e.g. in the past the Animé scene used 10-bit H264 which often caused issues. So plan B might be to rerip the media using Handbrake default HEVC settings.
Honestly, no clue.
If you created the /run xorg.conf and restarted the service the journal log should show Xorg starting in debug mode, which will generate a load more output and it would be useful to see that.
I updated the image in the share (Xorg based) to include a couple of things .. but I'm making random guesses.
Not a debug log. Not a complete log. So hard to comment.
Are you using 4K "certified" cables? .. 4K 10-bit media (and often HD audio) combined will be pushing higher data rates on the HDMI cable and dropouts are a textbook symptom of a cable that can't sustain the required data rate.
Is this something I should be worried ?
No, all harmless.
LE doesn't use /etc/fstab although it exists because some tools check for its existence.
Are there any stray .mount files in /storage/.config/system.d ?
