LE uses alsa. Pulse is present and running but only used for BT output, unless you manually reconfigure it and then it's a layer on-top of alsa, so it won't solve anything (you only add to the layers of problem) if alsa isn't working.
Please share a proper debug log not snippets of what you think is revelant. You omitted all the stuff that's actually useful. Use the built-in log paste function (uploaded zip files are a pain in the rear).
Is it the same for le too?
IIRC the breakage occurred earlier than Linux 6.16 but there were no patches to be found anywhere when it occured and we waited a while before moving to drop the driver. As exorcising external drivers with no hope of ever moving upstream has been a long-term initiative, even if patches for 'wl' did appear now, we have no plans to reinstate support. Sadly the 'b43' driver is not in great shape either and we're a little surprised it's not been purged from the kernel due to its equally unmaintained state; hence why we didn't enable that as a replacement.
#!/bin/bash
for param in $(ls /sys/module/btusb/parameters/*); do
value=$(cat $param)
printf '%-20s= %s\n' "$(basename $param)" "$value"
doneGives output like:
disable_scofix = N
enable_autosuspend = N
force_scofix = N
reset = YRepeat the same four lines for other modules and their paths and you're done. Tweak the %-20s= value to change the = offset.
The latest sysfsutils code appears to have been released and last updated in 2006 so whatever it is or does is probably superseded by other tools by now. It's also the first time I heard of anyone requesting it (in the decade+ time I've been hanging around the project) so the number of users who might think it's handy is probably you and .. (don't hold breath).
Step back a level. What were you trying to do?
The same has been reported on aother Allwinner board so there's likely an issue in the u-boot (or related code) somewhere that's used to perform initial boot. We've pinged the main Allwinner maintainer, but he's on an extended vacation so there might be a delay in someone seriously looking at the issue .. I'm not sure if other staff have hardware to test with.
I’d start with updating a current LE (and thus Kodi) release. I doubt any developer is testing addon code on Kodi Matrix these days.
Even if the TV is 4K the Kodi desktop should be run at 1080p: https://wiki.libreelec.tv/configuration/4k-hdr
If you append video=HDMI-A-1:1920x1080M@60 to boot params in cmdline.txt (to force the initial kernel DRM state to 1080@60) does that solve the issue? - I'm wondering if it's trying to output at 4K (for reasons unknown) and the TV isn't liking that.
I'd also be interested to know what shows on screen if you remove the SD card and let the RPi boot to the test screen. Does it show that an HDMI device (and EDID) are detected?
Argon cases are "the gift that keeps on giving" for support issues 
I'm wondering if this might be relevant: https://patchwork.kernel.org/project/dri-de…s.qualcomm.com/
Snapcast is not something I use so I can't test the theory on casing issues causing problems, but the fix for that has been committed to their 'develop' branch https://github.com/badaix/snapcas…dab403dcb9991b5 so should be in their next release. Once that's tagged we can update/bump the add-on from our side.
I found out that the most recent LE version is 12.2, but I can't update to this version inside LE
Set auto-update to manual then change the release series from LibreELEC 12.0 to LibreELEC 12.2, and then the 12.2.0 release will be available in the list of releases you can update to.
Am I doing something wrong? I've got expert mode turned on.
The wiki article that mentions the PQ setting links to two GitHub pull requests; one for Windows, one for Android. TL/DR: the setting is not currently supported on Linux.
It's always cheaper to acquire something locally from Amazon than have people ship something to the UAE, and we have funds for that kind of thing .. so it's not an issue. Time is a greater factor.
You are using the Q201 device tree file which is created from:
Neither of them describes the &uart_A connection required for BT to work, e.g.
It's probably easiest to experiment with some other GXM device-tree files as GXM hardware is all pretty similar and other files will probably give you a working (or working okay enough) system.
It's interesting that N150 might also be impacted with that issue, I'd previously believed it was limited to N100.
I probably need to order a box to do some testing and experimentation with, although the current queue of stuff on my desk is getting long and I'm probably lying to myself about available free time.
