marmistrz

As for autocapitalization, it seems to be some high-level mechanism. I noticed that when I'm writing im in the Messaging app, it's automatically corrected to I'm, even when I'm using Polish for both hardware and software keyboard. This doesn't happen in some other apps, such as Conversations. Btw. it appears that on my old OnePlus 3 running LineageOS 14.1 there's an option for autocapitalization when I plug a USB keyboard, however, this option does nothing. There's no such option on LineageOS 16.0 on the Pro1.

Could you please provide instructions for updates from test22 to official in the OP? It was discussed somewhere, but I don't remember what the conclusion was

I managed to fix the problems with GPS by clearing all caches. Now I'm getting a fix within 5-10s, GPS, GLONASS and Beidou is used. # rm -rf /data/cache # rm -rf /data/dalvik-cache

I'm not sure if it's just the configuration: some time ago, on test16 GPS worked and I used to get a fix within less than a minute. Now I don't get any fix. I don't know if GPS broke directly after updating to test22 or later on. I updated from test22 directly from test16, without any intermediate releases. Maybe I could try wiping all the caches? I know how to do it with TWRP, but the LOS recovery doesn't provide such an option.

I'm always using SatStat and OsmAnd.

I have recently updated from test16 to test22 and today I noticed I can no longer get a GPS fix. SatStat sees a couple of satellites, but marks them red. I attached logcat. I tried clearing the data for com.qualcomm.location and FusedLocation, but it doesn't help. I haven't updated to the official releases yet, but since test22 and current official are mostly the same, this shouldn't matter. Let me know if I should try it. I'd prefer to avoid wiping everything for obvious reasons. gpslogcat.txt

Well, the point is that even while building in-tree, I won't be able to build the kernel unless I apply this patch. It looks like `make bootimage` (and in general the kernel build system) uses the host compiler at some early stage to compile dtc instead of the Lineage DT compiler. This makes sense, because the Lineage DT compiler is an arm64 cross-compiler and dtc will be run on the host and needs to be an x86 binary. SHIPPED scripts/dtc/dtc-lexer.lex.c HOSTCC scripts/dtc/dtc-lexer.lex.o HOSTLD scripts/dtc/dtc

@tdmwe need to cherry-pick this commit to enable build of gcc 10 hosts and regenerate the "shipped" files. (dtc is built using the host compiler and upstream doesn't contain the "shipped" files) https://github.com/torvalds/linux/commit/e33a814e772cdc36436c8c188d8c42d019fda639 I would've done it myself, but I'm not sure how to properly cherry-pick with gerrit to preserve authorship.

Thanks for your reply. I'll try building it within the Lineage tree. You mean an entry in the settings app, so that people can toggle it without command-line tweaking? I can't join the Telegram group without providing my phone number, which I'm unwilling to do. Is there any IRC/Matrix/XMPP/... room/bridge?

Okay, so I'd like to contribute to LineageOS for Pro1, and there are two things I think of 1. Add a possibility to turn off autocapitalization 2. Implement sticky fn. The idea here is to store a boolean flag `fn_sticky_pressed` and set it `aw9523b_check_keys` while checking the state of the keys So I have questions 1. In which part of the software stack is the autocapitalization for hw keyboard handled? This doesn't look like in the kernel driver 2. What's the correct way of building the kernel? I did the following on Arch Linux, gcc 10.1.0 export ARCH=arm64 export SUBARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- make clean make mrproper make lineage-pro1_defconfig make -j $(nproc) However, this fails because of kernel/bpf/core.c: In function 'bpf_patch_insn_single': kernel/bpf/core.c:175:3: warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=] error, forbidden warning: core.c:175 I applied the following patch so that the kernel builds at all: diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped b/scripts/dtc/dtc-lexer.lex.c_shipped index 45a4913958b8..0fa49e70de1d 100644 --- a/scripts/dtc/dtc-lexer.lex.c_shipped +++ b/scripts/dtc/dtc-lexer.lex.c_shipped @@ -622,7 +622,7 @@ char *yytext; #include "srcpos.h" #include "dtc-parser.tab.h" -YYLTYPE yylloc; +extern YYLTYPE yylloc; extern bool treesource_error; /* CAUTION: this will stop working if we ever use yyless() or yyunput() */ otherwise, I'd get `multiple definition of `yylloc'`

Ok, I see what's the reason for the unexpected behavior of alt/fn+alt. fn is handled using these arrays: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/2120e09d09b3a94c4de9395523a587d9909224d4/drivers/input/keyboard/qx1000.c#L257-L335 It appears that KP_LEFTALT is handled in this part of the file: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/2120e09d09b3a94c4de9395523a587d9909224d4/drivers/input/keyboard/qx1000.c#L649-L654 and no check is made for the state of the fn key. What kind of key event is emitted on stock for fn+alt? (I can't find the kernel sources for stock) @tdmis there any reason why alt is handled the same way as fn+alt, is it a bug or a feature?

We really should have a wiki describing all the LineageOS modifications compared to stock. The built-in layout indeed works, unlike on stock. Currently one advantage of using (left) alt instead is that it's sticky, unlike sym (right alt).

Eh, you can't do inline replies on this forum. You're right, one can use left alt as a modifier key. I made mistake while modifying the generation script 🙂 and it's why the generated keymap didn't work for me. Expect a Polish layout using alt for diacritics in finqwerty soon^TM 🙂 Your reddit post doesn't really explain the internals, just the implemented features. How exactly is fn handled inside the driver and why isn't it done in the userspace? If I'd like to prevent alt from opening emoji, is it AOSP keyboard that should be modified? Does it have anything to do with the LOS changes?

My 2015 OnePlus 3 does MUCH sharper photos than the Pro1. (I even checked gcam out of desperation and it's still worse) I'd expect a decent camera for such a high price (especially that the device aspires to be a premium device)

I don't know much about the architecture of Android, but maybe the process responsible for detecting key repeat/long press (probably some equivalent of X.org) has too low priority and gets deprived of the time quantum?