[LG V20 Guides, News, & Discussion] emdroidle:
That was a joke. Refusing fingerprint initially on start is to prevent using copied fingerprints after a device has been powered off. If /data is encrypted the pin/password is required to retrieve the key. This is a measure to protect against personal data being retrieved from phones no longer in the possession of the owner.

Which requires you to know the port can support that current, otherwise you can potentially damage the power source. Older PCs often had USB ports protected by a fuse which would blow, protecting the rest of the computer if a bad USB device was plugged in, but would permanently disable the port. (this is why I'd like to avoid such this change)

That repository is a WiP. I've been intending to add the H990 patches on and make it available, but I keep coming back to the issue that the LineageOS source is far better in the longer run. Of particular note, it has full history which makes many operations easier, of note security updates. Right now that repository isn't operational.

Very interesting. Could you point me at this KDZ? I can well believe LG did something funky with one of their KDZ files, but I need to examine the file if I'm to solve the problem.

Did the camera work for you? I'm attaching two updated kernels and have some instructions below. There are some specific details which need observing to confirm a fix.

Yeah, those were kind of obvious. By far msm_actuator.c looks to be suspect. Meanwhile I find the theory of Sony vs Samsung sensors rather doubtful.

There aren't any files named like that in LGE's kernel source. If those are necessary for a functioning sensor then LGE is violating the GPL (possible, but not yet proven). There are some small behavior changes in msm_actuator.c, LGE's camera code could well have been relying on what was undefined behavior to function properly. If so this is merely an issue of staying compatible with old behavior.

I'm attaching two experimental kernels to this message. Both include the main patch for the Blueborne fix. -experiment1 is aimed at the camera focus fix, -experiment2 is aimed at video recording (it also has the theorized focus fix). I need someone who has experienced these issues to report on whether they fix the problem or not.

If you were experiencing the camera focus issue and the problem is fixed, I badly need an extra observation. In the kernel log almost certainly some messages including the string "msm_actuator_" will show up and these will include some extra numbers. If successful they will point to the precise root cause. I don't know whether these will show on phone start or during use of the camera. If you've got a shell this information can be retrieved with the command `dmesg | grep -emsm_actuator_`.

The two most likely messages are "msm_actuator_config bad table returned ######## (opt=<string>)" or "msm_actuator_config() called with undefined cfgtype=### (returning compat 0)". That number and string will be magic.

-experiment1:

MD5: 67ca259a0466ee090fa484e25b8b84ef

SHA160: 49842e66e0a7157b13a3a9dc9bd87324c47fe706

SHA512: b4fcf35ee24b0b00070426ee6957bb187dc25ad1c0afcf0c1e8c6fa235d12f70ff39592b317218667e1c7bb60f8cb69b11f74650184a04bed53c7c2c299943cf

-experiment2:

MD5: 50e1f26b509a1f04d421f52ac61c7809

SHA160: e096c5d1a568dea5bdbf36f55db0afab91c632ea

SHA512: 1f4ded21037e93ec4b1fa7ab36e6b71cb4febf955ba0dd4bb76708fa0016d20a14b847a271db5529e89abee7958ed4c3d89c8df157fc81dc7b448781a874b9a3