It's supposed to work (has not been intentionally broken) but everything in the Bluetooth world seems to have a lot of moving parts and dependencies so I wouldn't be entirely surprised if it was broken.
Let's start with asking for the usual debug "pastekodi" output 
ah my Intel issue has labels now.
And a reply: https://gitlab.freedesktop.org/drm/intel/-/is…99#note_2270390
Support works a triage script like all support teams: start with testing latest to eliminate bugs that have already been fixed, then if the issue still exists start digging for more. Be responsive, as they have hundreds of other things on their to-do list
The patch I sent upstream adds 0b95:1790 to the "USB_NET_AX8817X" driver but there's a separate "USB_NET_AX88179_178A" driver in the kernel which already has that combo inside, and both drivers are enabled in our kernel config. This means the patch I sent to the list is fundamentally wrong (as it's the wrong driver) but now we need to explain why there's no attempt at probing and loading the correct driver in the logs.
To ensure I'm looking at the right thing. Please update the RPi5 (not RPi4) to the image in my test share. This 100% doesn't contain any patches, and I want to see output from "dmesg | paste" after booting with the ASIX adapter connected before power-on.
You can cross-grade betwen Generic and Generic-Legacy images with the caveat that all binary add-ons compiled against graphics libraries will need to be uninstalled and reinstalled as the graphics stacks in the images are different and incompatible (Generic uses GBM/V4L2, Generic Legacy uses Xorg/X11). As part of that change you need to clear the package cache in /storage/.kodi/addons/packages as Kodi checks the cache for matching filenames before downloading from an online repo; if you don't clear it you'll be reinstalling the now-incompatible add-on that you just uninstalled.
VNC should work in the Generic Legacy image.
Most client applications will generate multiple concurrent sessions in normal communications with their server target and thus use randomly assigned source ports to distinguish each session.
Some background reading: https://www.geeksforgeeks.org/difference-bet…stination-port/
EmuELEC images are based on downstream Amlogic vendor kernels (CE not LE) which means device-tree files are not compatible with LE images using mainline kernels.
2024-02-05 22:57:56.439 T:970 info <general>: Running on Amlogic Meson GXM (S912) Beelink GT1 Ultimate with LibreELEC (official): 11.0.6, kernel: Linux ARM 64-bit version 6.1.38^ That's not the LE12 image from my share. To share blame I'm also guilty of saying "debug log" when I meant "pastekodi" (or show the dmesg log) as I need to see the system boot data not Kodi things. Sorry..
FYI, this is the patch submitted upstream. I've noted that while the NIC 'works' for you the "-32" errors being logged show something is off and these will need to be resolved before changes can be merged:
[1/2] net: asix: add 0b95:1790 to AX88179A device list - Patchwork
As I don't have the hardware I'll need you to do more testing - once I figure out how to implement the next-steps suggestion from the mailing list.
The cec-ctl/cec-client/cec-compliance tools are there. You'll need to Google for help though.
2024-02-04 14:47:18.676 T:1138 info <general>: [WHITELIST] Searching the whitelist for: width: 3840, height: 2160, fps: 11.989, 3D: false
...
2024-02-04 14:47:18.677 T:1138 info <general>: Display resolution ADJUST : 3840x2160 @ 59.940063 Hz (20) (weight: 0.000)
...
2024-02-04 14:47:18.828 T:1138 info <general>: [WHITELIST] Searching the whitelist for: width: 3840, height: 2160, fps: 50.000, 3D: false
...
2024-02-04 14:47:18.828 T:1138 info <general>: Display resolution ADJUST : 3840x2160 @ 59.940063 Hz (20) (weight: 0.000)
...
2024-02-04 14:47:18.857 T:1026 debug <general>: CActiveAE::ClearDiscardedBuffers - buffer pool deleted
2024-02-04 14:47:18.857 T:1139 info <general>: Skipped 1 duplicate messages..
2024-02-04 14:47:18.857 T:1139 error <general>: ffmpeg[0x62698d0]: [aac] Number of bands (72) exceeds limit (49).
2024-02-04 14:47:18.863 T:1140 error <general>: ffmpeg[0x6266460]: [hevc] Failed to end picture decode issue: 18 (invalid parameter).
2024-02-04 14:47:18.863 T:1140 error <general>: ffmpeg[0x6266460]: [hevc] hardware accelerator failed to decode picture
2024-02-04 14:47:18.863 T:1140 debug <general>: CVideoPlayerVideo::CalcDropRequirement - hurry: 0
2024-02-04 14:47:18.863 T:1140 info <general>: Skipped 6 duplicate messages..
2024-02-04 14:47:18.863 T:1140 error <general>: ffmpeg[0x6266460]: [hevc] Could not find ref with POC 16
2024-02-04 14:47:18.864 T:1140 error <general>: ffmpeg[0x6266460]: [hevc] Failed to end picture decode issue: 18 (invalid parameter).
2024-02-04 14:47:18.864 T:1140 error <general>: ffmpeg[0x6266460]: [hevc] hardware accelerator failed to decode pictureNothing specifically enlightening although I note there's an intitial check for some weird 11.989fps that vaguely divides into 59.94, then it detects 50fps but continues to use 59.94, and then there are acc/hevc decode errors. No idea if there's any relation between them. To me it looks like the HEVC format passed to the hardware decoder fails.
In context the number of users rocking up here with latest generation Intel hardware is small and in continuous slow in-decline for the last decade. So audience is not large, there is a workaround (albeit forum sourced) available, and 'Yes' adding hacky stuff to the core image matters and is something to be avoided; largely because once workarounds are merged history shows people end up being happy with the workaround and the root cause is never pursued. If you refuse the hack up-front there's a significantly higher probability of the real issue being resolved (tried and tested). Backporting patches merged/submitted upstream is a no-brainer.
It's in the Linux package.mk: https://github.com/LibreELEC/Libr…/package.mk#L28
I opened a pull request to make the helper script part of official LE
Pursuing the fix upstream then submitting a backported kernel or intel driver patch will probably be faster. I think you'll find that script is a little too hacky for peoples tastes and i'd be surprised if it gets merged at this stage in the release cycle.
So that leads me to think I cloned from the wrong repository?
Correct. LE uses the Linux 6.1.x kernel sources from Raspberry Pi on their boards: https://github.com/raspberrypi/linux/
Is there a way when setting up LibreELEC for the Pi to have it allocate the large partition as NTFS or exFAT, instead of as EXT4, so that it can be read directly in Windows.
NTFS and exFAT do not support Unix filesystem permissions (everything on the drive has 777 permisionss) so lots of things break if the /storage partition is formatted using them (e.g. SSH will not start). There is nothing to stop you partitioning a storage drive so that /storage (EXT4) is relatively small (16GB is more than enough) with a third /media partition that uses NTFS where you dump files. LE will be able to mount the /media volume so you can create a Kodi 'source' for content there. That said, Windows always used to be completely stupid at working with removable storage that contained anything more than a standard 'Windows' partition layout so YMMV and I would be expect some kind of idiocy to be involved. NB: The LE installers do not support partition layout changes and it is not possible to shrink the /storage partition from within LE (as it's mounted/in-use once booted) so you will need to pull the card and do that from a separate Linux setup, e.g. Ubuntu desktop.
Show me the debug log from the LE12 image using the working dtb.
I haven't applied changes to the RPi5 image in that share.
The issue is in the driver not the kernel, so there is nothing new to test unless the driver is bumped.
