[LG V20 Guides, News, & Discussion] emdroidle:
Seems the hardware of the H990 has some difference(s) which mean the kernel needs some sort of other tweaks to get it operational. Mostly this means tweaking the initial ramdisk to allow debugging and then going in and figuring out what is different on it. This surprises me. :(

I doubt this rooting process could cause this, but I do have two concerns which could account for this. First, I've got a suspicion the photodiode used on the V20 (and V10) isn't all that sensitive and isn't all that wonderful at correctly capturing IR signals. Second, LG's back-end software for capturing IR signals may be poor; you can see this in LG's app in that it doesn't give any feedback as to whether it is capturing anything.

Android included a standard API for sending IR signals, but none for capturing them. As a result for IR learning, developers end up using one or another manufacturer's API for accessing the photodiode. LG has one API, HTC has another, and Samsung has yet another. AnyMote supports HTC's API, but not others. :( I've been left with the impression LG's API/library isn't really all that great.

Currently the key step makes use of the "DirtyCOW" exploit, so the downgrade is required. :( I hope to make upgrading to later firmwares possible, but that is in progress right now.

You definitely don't want those. Trying those will cause problems. Problem is I've never seen this battery drain issue, so I really have no idea right now. :(

Yes, I'm very worried. Problem is right now I've got no idea what is up. :( My preferred solution to most of these issues is trying to climb to the HEAD of LineageOS's kernel tree, at which point any problems would be shared with them and a bigger brain trust should be better for figuring out issues. Trick is getting based off their HEAD is going to be an interesting process. I'd been planning to target system updates first, so I'm unsure which direction to jump.

Ah ha, this is something I can target. I'd noticed the DirtySanta bootloader was adding "androidboot.selinux=permissive" to the kernel command-line, but hadn't thought it a big deal. Now this suggests this actually is a big deal, this I'll need to place higher priority on this. Hopefully this takes care of other issues too.

At least one person has tried and succeeded. They reported it worked fine. Do a search and you should find the message.

Technical geekery below:

Problem is the LineageOS kernel tree has a number of landmines. Their maintainer decided to replace the Bluetooth driver with one which worked for AOSP and LineageOS, but was incompatible with LG's Android installation. Then later found out that driver didn't work for AOSP or LineageOS, but because they did it in their only branch, the Bluetooth driver in drivers/bluetooth/broadcom doesn't work for anyone.

They also disabled the second screen. This is reasonable given how LineageOS has no support, yet they disabled it by modifying the code and not introducing a kernel option to enable or disable it. As such in order to reenable it, you have to manually modify a few magic spots. I'll be introducing a kernel option to control this, but this behavior is kind of anti-social. :(

There is the issue of the H990 owners reporting an inability to boot with the kernel I tried to build. I'm wondering about the cause. Presumably the H990 has some kind of hardware difference, but the question is: what is that difference? I'm suspecting it might be they've got a different flavor of UFS chip and could be as simple as needing an extra driver. The kernel source LGE provides is the same for the H990 and H990ds so the difference shouldn't be that large. Badly needs to be figured out though. :(

The above seems easiest to query during kernel installation. Instead of adding "lge.sim_num=# lge.dsds=*" inside the kernel, add them to the portion of the kernel command-line in the boot image; include "model.name=LG-H990*" as well. At which point instead of fixing the "model.name=LG-US996" string, I simply remove that string. Then I need to modify the modem fixing code to retrieve the strings from the command-line instead of having them configured at kernel build time.

FYI, seems the "nt-code" isn't an issue at all. This kernel doesn't bother to touch it, yet it works for most cases.

Certainly seems doable. I'd been pondering using the boot image portion of the command-line from the start, but that had its own share of complexities.

I've been kind of feeling a bit off the past few days. I've made some progress on the KDZ system upgrade task, though that has uncovered some different entertainment (apparently the OS resizes /data during normal operation?!). Hopefully I'll have a revised kernel in a day or two.