EskeRahn

I believe the last remark is not quite accurate. It is the flashing&install of the main image that also changes the active slot. Reboot to Recovery just boots to that. If you do not want gapps/magisk/... a reboot from the main menu will also boot into slot B

Sad to hear you broke the screen. On the call quality, a headset might help you. I use a wired one, and that works fine. (though obviously just a workaround not a fix)

Not new at all... Also there on stock Android 9.

(lineage-18.1-20210906-nightly-pro1-signed.zip on August 5 security patch installed smoothly using adb sideload and Open_Gapps-arm64-11-pico-20210712) ...But the reintroduced Accessibility / keyboard bug is not (yet) fixed, see above.

They do look suspicious, indeed.

PPS looking inside the fastboot_all.bat inside the .7z file, Someone with more understanding of these things might be able to pinpoint the specific file that does the trick: fastboot flash boot_a boot.img fastboot flash boot_b boot.img fastboot flash dtbo_a dtbo.img fastboot flash dtbo_b dtbo.img rem fastboot flash system_a system.img rem fastboot flash system_b system.img rem fastboot flash vendor_a vendor.img rem fastboot flash vendor_b vendor.img fastboot flash vbmeta_a vbmeta.img fastboot flash vbmeta_b vbmeta.img fastboot flash userdata.img fastboot flash abl_a abl.elf fastboot flash

The clipping seems like a firmware/software issue, so most likely not much point in sending it in. Is it related to the two sources? Someone are talking in the background and the music is playing. Could it be some attempted noise reduction that are teasing? It sounds a bit like when e.g. Skyping with someone in a meeting room, and the equipment struggles with recording what is noise and what is signal.

PS on how to flash the stock android see this thread

I doubt that factory resetting will do the trick, that 'merely' erase user data. I think it is in the flashing process it also sends something to the display, but I'm not sure. I would rather suggest flashing the latest version, without wiping the user data/

For those on the same version of stock, I do not think a factory reset would be needed after a re-flash. But I could be wrong, it is more of a hunch, as far as my understanding of this whole flashing circus works. So should I do it on a stock device, I would flash without the wipe first - I mean worst case is a re-flash WITH a wipe... So only time is lost. That said, if people have some extra packages sideloaded, they should most likely be applied again.

Are you sure? I believe that it is the flashing of the stock that ALSO flashes something to the display. So even if on stock I think we might have to re-flash it to get the screen working correctly - but as it is the same image, there should be no need of a factory reset, so not that bad. I have not tried to do it though, so be sure to make suitable backup in case a wipe is needed to get things working after the flash.

Interesting. I must admit I'm a bit confused here, as this would mean that Gapps and Magisk go to different slots. Could you check at next load whether it (in small print) says a or b at the three sideloads?

I'm pretty sure that a reboot to recovery is needed between the first two. At the least that was the case for Lineage 16 - have not tried without since.

That was my point yes 🙂

Let me make an example. Assume we use the left YA key combined with the letters 'P' and 'L' to in the kernel 'emulate' two missing physical keys. But YA combined with 'T' might not be mapped in the kernel, so in this case rather than just sending the 'T', it could be sent as a modifier+'T', for remapping furhter down the pipeline,

It would be nice if the kernel remapping could be so flexible that it only took a modifier key if it was used with on of the defined remappable keys. This way more combinations would be available for the users, with the modifier used with other keys.

I would be surprised if the handling of the physical keys and touch are not substantially different, so do not think we can deduce from differences between the two.

Yes it is stated somewhere that IF you want to use gapps, then it MUST be installed before first OS-boot after a flash, and must be reinstalled after each OS flash.

That sounds like something eats up the processing power, so it is unable to process the keystrokes in real time. But obviously what ever does the processing should have had sufficient priority for this not to happen normally. Anything you are aware of running in the background that might be what is disturbing. E.g. some complex sound decoding, playing high-resolution sound? I would try to install something like GSam or the like, to find out what is using the resources. (GSam registers the battery pull over time, but any substantial CPU activity should also leave a mark in the power cons

Silly me, i did not read the log provided closely enough> .... healthd : battery l=75 v=3983 t=30.0 .... So that should hardly cause anything to shut down

Swapped: A=Keyboard, B=Case - at the least that is the naming used in the FactoryKit....

Most likely a scancode for historical reasons is a byte, somewhere in the 'pipeline', so the map to 464 must happen later.

The Hall_a is the keyboard open/close detector, the Hall_b is the one in the display (case detection) They are called a and b in the 'factorykit'-test (The one just above OTG almost at the bottom) See this

Look at it another way. Why should a bank care if they did not see a reduction in their risk of loosing money somehow?

(lineage-18.1-20210830-nightly-pro1-signed.zip on August 5 security patch installed smoothly using adb sideload and Open_Gapps-arm64-11-pico-20210712) ...But the reintroduced Accessibility / keyboard bug is not (yet) fixed, see above.