Posts by chewitt

I haven't experienced anything similar myself, so no idea what the issue is, but the first step is to update to the current/latest LE13 nightly image (20260817 is available) and test again. If no change, put Kodi in debug mode, scrape media, then run pastekodi over SSH and share the URL generated so we can see the log of what happened.

The historic reason for not implementing the GUI side of those auth methods is simply that nobody on staff has ever had access to networks that used them and thus nothing could be tested; and since OpenELEC days that hasn't changed, and no user with the need for the capabilities and the developer skills to implement it themselves has shown up either. However, to not alienate the very-occasional user who showed up in the forum we left the compile options alone so ConnMan supports those features and config can be hand-rolled over SSH when needed. I do think it would be good to document that process in the wiki so that it's searchable, but (again) that requires a user with practical experience submitting the changes - and so far that has never happened.

I do agree that domestic network kit is ever-more capable these days, but I don't see evidence of Enterprise auth methods being used in the support questions we see in the forum. On that basis (and since we still cannot test things) I don't feel that we need to make the effort. If that changes in the coming years we'll always revisit the requirement.

Quote from wizardknight

I have a known working Realtek 8812BU Wireless LAN 802.11ac USB NIC, but the system doesn't seem to use it

The kernel module (CONFIG_RTW88_8822BU) is enabled in defconfig so the two possible issues are missing USB ID's or missing firmware. You can check if the USB ID's are listed here:

linux/drivers/net/wireless/realtek/rtw88/rtw8822bu.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

If no, it's trivial for me to add and upstream them, run lsusb -tv | paste with the NIC attached and share the URL.

If yes, please run dmesg | paste and share the URL so can see what firmware is missing and then pick the file from linux-firmware into the image. NB: You can also add firmware manually https://wiki.libreelec.tv/how-to/add-firmware to confirm the card works.

chewitt@toolbox:~/connman.chewitt$ pwclient git-am 14752333
Applying patch #14752333 using "git am"
Description: [v2] plugins/wifi: Fix GSupplicantInterface socket leak during teardown
Applying: plugins/wifi: Fix GSupplicantInterface socket leak during teardown
error: corrupt patch at line 10
Patch failed at 0001 plugins/wifi: Fix GSupplicantInterface socket leak during teardown
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
'git am' failed with exit status 128

The v2 patch ^ also doesn't apply. I would strongly recommend you configure git send-email so you can generate patches using git format-patch and send them directly from the terminal. Also, when you iterate patch versions it's good practice to place info on what changed from the previous one below the --- marker. See here for an example:

[v3] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop - Patchwork

In the case of a single patch where there's no cover-letter to place technical before/after evidence and more detailed background info on the problem, this can be placed under the --- marker too. This is then visible to maintainers reviewing the patch, but not part of the code that's eventually merged.

You will need to send a v3 because the v2 patch is broken. I'd start with a brief apology under the --- marker to explain that it's been a while since you used a mailing list

NB: The linux kernel has ./tools/checkpatch.pl to check that patches are valid from a formatting perspective. I sometimes use that tool against other repos to check for obvious style problems. ConnMan/IWD etc. are not the kernel, but maintainers are also kernel devs so the same/similar standards are expected and it's a good benchmark.

btw, I think you need to check the patch state of the branch you submitted from, because it conflicts with existing code, e.g. this first hunk if (wifi == NULL || wifi->device == NULL) does not exist in current code:

@@ -1014,14 +1014,16 @@  static void
interface_removed(GSupplicantInterface *interface)
 	wifi = g_supplicant_interface_get_data(interface);
 
 	if (wifi != NULL && wifi->tethering == TRUE)
 		return;
 
-	if (wifi == NULL || wifi->device == NULL) {
-		DBG("wifi interface already removed");
-		return;
-	}
+	if (wifi != NULL && wifi->device != NULL) {
+		wifi->interface = NULL;
+		connman_device_set_powered(wifi->device, FALSE);
+	} else {
+		DBG("wifi device linkage missing, executing isolated interface

The current code state was introduced in this patch:

commit 4b3c38ec737f3fc0642cd825471763be570fe02e
Author: Hannu Mallat <[email protected]>
Date:   Mon Sep 29 09:19:56 2014 +0300

    wifi: Set interface pointer to NULL on deallocation
    
    As interface_removed() gets called when the interface struct is being
    deallocated, make sure the pointer is set to NULL regardless of the
    other fields' values in wifi struct.

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 45d88b8e..d18dc6cd 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2284,6 +2284,9 @@ static void interface_removed(GSupplicantInterface *interface)
 
        wifi = g_supplicant_interface_get_data(interface);
 
+       if (wifi)
+               wifi->interface = NULL;
+
        if (wifi && wifi->tethering)
                return;

LE13 is using current ConnMan master plus this series to mitigate the invalid-key issue seen with some wifi connections:

[0/3] wifi: Forgive transient errors - Patchwork

nb: the patch submitted also has style problems due to line length/wrap issues.

Doemela when interacting with mailing lists:

a) If you submit a patch as an additional comment within a bug report (as you have) it will be handled in patch tooling as a comment, and not as a patch. Instead submit the patch to the mailing-list as an actual patch; assume general kernel standards and etiquette for the patch submission. Keep the description brief/simple and use imperative (not conversational) tone. Note that AI generated patches are obvious and a human touch is generally appreciated by maintainers.

b) Once you submit a bug report and start a mail thread on the list always reply to the original message (even if this means replying to yourself) to keep everything in the same thread. If you send further information as 'new' messages these will not be linked in any of the list/review tooling that maintainers use.

c) Never top-post replies; always add information and content inline to the original post or append below the original. Again, this is to keep the information flow sequential in patch/review tooling.

Quote from smf007

The question then is, in order to confirm the issue is with Crocus, is there any way to force Kodi (from Kodi side, not Mesa) to use Linear without having to patch the code?

There's no override mechanism for format selection in Kodi so you'd need to patch code.

Quote from smf007

This seems to possibly be related to a ToDo item in the Mesa Crocus source code.

Link?

It would be useful to see the Kodi debug log output, i.e. pastekodi from a current LE13 development image, please.

Quote from atirage21

And where are published these testing builds ?

The same place they are always published, as referenced in the first post, and repeated numerous other times in the thread.

Quote from atirage21

At my device i have kernel 6.19 with last builds: https://paste.libreelec.tv/islandish-vernice.log

Then you are not running a current development image. This thread has no interest in nightlies and low interest in reports from older images with older kernels.

Quote from ht2tweak

I did add a disp_cap_3d because I've had to do so with CoreELEC and OSMC:

This is Amlogic proprietary irrelevance that only applies to things running the Amlogic BSP kernel.

Quote from electrolurch

https://paste.libreelec.tv/rowable-skyla.log

Log shows Linux version 7.1.2 (ubuntu@0f3e7d5c77e9) so you are not running the image from my test share which has a Linux 7.2-rc6 or rc7 kernel. The log is not relevant. I have no interest in nightlies; I am trying to develop the next kernel to fix the known-to-have problems kernel in nightlies.

diederik I currently distrust anything from that contributor as a result of conversations over the RK3588 VP9 driver submission. All of their comments complete with inaccuracies were being generated through some AI tool and they bullied the main author into adding them as Co-Developer on the series despite their contributions being little more than minor fixups found through testing, and one "very important fix" patch that was quickly proven to be irrelevant under maintainer review. The patch you've flagged is worded less aggressively than previous things but that's more likely to be evolution in the AI tooling than human influence.

IMHO the OpenGL path is probably most-used among Kodi overall, due to most of the big distros packaging it, but the preferred direction among the folks currently active and working on Kodi is OpenGLES, so that may evolve and change over time.

Quote from atirage21

Kernel 7.3 have improvements for gpu at arm64 systems.

None of that is relevant to a device currently running a development images with 7.2-rc6/rc7 kernel. Even when 7.3 ships it will make zero real-world difference to any of the devices that LE supports. These changes are the coding equivalent of rearranging deckchairs.

Quote from electrolurch

RK3399 black screen !

The OS is probably running though even if Kodi doesn't start. If you can clean boot and then SSH in and run pastekodi then share the URL it would be useful to see the output.

Even if someone identifies an issue on LE12.2 we aren't going to ship another release so the first/only thing to test next is a current LE13 nightly. Also, if this is a device with an onboard LSPCON chip in the HDMI chain ensure all the firmwares are updated.

I've pushed revised RK3288/RK3328/RK3399/ RK356X/RK3576/RK3588 images to my test share. The main change is a kernel bump to Linux 7.2 with the latest usable iterations of the many patch series that go into current images. Of particular note: older Rockchip hardware is now using the same kernel as newer hardware since Kwiboo has been reworking old bit-rotten patches that broke and reworked patches are slowly being upstreamed.

However !!! WARNING !!! .. I'm on vacation with zero access to hardware so the images are compile tested only, and a few large G&T's have assisted some of the patch wrangling. What could possibly go wrong?

I'd advise taking a backup of KERNEL/SYSTEM before updating in case I messed things up and you need to roll back. I've not kept up with patches since Linux 6.19 so I'm half expecting some feature differences somewhere if I've missed things. Reports of success or failure (or feature completeness etc.) are appreciated.

sunlollyking There was a time where LE13 development images used GL instead, but as GLES now has feature parity with GL in Kodi (and surpasses GL in a few areas) we switched LE13 back to GLES again. The buildsystem supports a Generic 'OpenGL' build target if you want to make one for testing, but we have no plan to release GL images.

NB: I spotted a comment from you in a Kodi PR/Issue thread about lack of testing hardware. Drop me an email on my username @ LE or Kodi domains.