Posts by chewitt

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.

All drives manufactured in the last ~30 years have head auto-parking technology to avoid mechanical damage. That scratchy/clunk noise is the drive doing whatever it needs to do to safely stop when power is cut. Scripting shutdown might generate less noise but makes no real-world difference to the drive. If a drive died; it was just it's time (they don't last forever).

If the bitrate is low enough 4K content will play, but it needs to be really low to work so most 'normal' 4K content behaves badly.

Is that log using DHCP or manual? .. have you configured NTP servers? - In short, I'd like to see a log using normal DHCP and no additional configuration; thus anything we see in the log is your network pushing config to the device through the DHCP scope.

I'd also like to see a log with connman debug logging enabled. How that's achieved seems to have changed, but perhaps just add debug to kernel boot params in cmdline.txt and reboot.

Your network is definitely unusual, as evidenced by the NTP server responding with Kiss-of-Death packets.

I scrolled through the log as far as the piracy add-ons, then I lost all interest in this problem. NB: the add-ons are not technically on the Kodi banned list at the current time, but I've flagged them to be added.