[Android General] limited_imagination:
Hi there, I'm still here, but I only check in on this thread every few days, maybe once a week-ish. I think that if I get quoted or PM'd, then XDA sends me an automatic email notification, so that would get my attention faster than my random visits here. Apparently "mentions" don't generate an automatic email, because I just stumbled on this by chance tonight.

That's interesting to hear your different experience with LKT. So then we are looking for distinguishing facts between our systems, to account for the different experiences. We know that we're running the same kernel, so that's not it. What about the configuration of LKT when it's first installed? I recall there are four levels of speed boost that you must select with the volume buttons when you install LKT, the fastest supposedly being "Turbo". Of course, I picked that one! Maybe you picked one of the other three, which maybe improves stability?

Our different subjective impressions of speed are a potential distinguishing fact, too. That's why I tried to use an objective benchmark through Geekbench 4, which of course is imperfect, but yields interesting results even so. Especially interesting that my LKT on "Turbo" setting gave a marginally slower benchmark than LOS by itself with no LKT.

Pattern recognition, man. Distinguish the facts between the different cases, to learn the ratio decidendi.

In an ideal world, we would have more than just two cases from which to consider possible distinctions, so it would be cool if others tried LKT and posted their results.

When you say it "doesn't support" the device, do you mean that you don't even get LKT as an option to install with the Magisk modules list? That would be interesting to know, whether Magisk tailors its modules to specific devices which are proven reliable. Or, at least, have not been documented as proven unreliable.

So I am for sure not qualified to speak very knowledgably on this yet, but I will hip-shoot a surmise, and then more experienced people than me can feel free to correct me.

I suspect that most of this has to do with the state of the source code for the kernel, as it was initially developed. Functionality that was not envisioned at the time the source code was first developed (or last released) would be very difficult to include in a kernel. It would take a LOT more hours to try to incorporate new functions that weren't even on the radar when the device and its kernel source code were first released, and probably someone would have to have a very strong financial motive to do so. That's extremely unlikely to happen, because we're talking about devices that are by definition obsolete, and the pool of them in existence diminishes with every passing day. So it's not surprising at all that a dev bumps up against limits and moves on.

At a certain point, it becomes a game not worth the candle, because you would have to effectively re-engineer the entire kernel source code, instead of just configuring an existing source code. That's way past my pay grade, anyway.

At the moment, I've just been playing with configurations in the original kernel source code for the TB3-850F. It's relatively easy to get a configuration menu up with "make menuconfig", as I documented earlier in this thread, and then you can configure away to your heart's content. The problem comes after that, when you execute the "make" command and try to compile it, and it throws a ton of errors because the manufacturer released only the minimum parts of the source code that the licensing contract required. So it's hard enough to find all the Easter eggs around the Internet to make the original source code complete enough to spit out a kernel file. Then it's an order of magnitude harder still to make a compiled kernel that actually WORKS when flashed to the device. What you're talking about in terms of "extra functionality", if it wasn't specifically designed to be configured in at the time when the device and its source code were released, would be many orders of magnitude more difficult.

In terms of Android Kitchen, all that program does is unpack the boot.img into its constituent files. One of those files is the kernel itself. So the idea here is that it's possible to compile a kernel file independently with a source code, by using a compiler program. Then once you have that kernel file compiled, you can unpack a boot.img with Android Kitchen, swap the original kernel file out and replace it with your newly-compiled kernel file, then repack it all with Android Kitchen, and then you have yourself a new boot.img.

All very interesting as an academic exercise, but once you actually flash it to the device, then you will see whether you did anything practical and effective, or whether it was just an academic exercise.