Leaderboard

Fixed. The CR is under review here: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315298 Oh, and there is an associated SELinux policy change that is also needed, but the implementation is still under discussion

Don't worry, I don't think your criticism regarding users' rights would have made anyone infer that you wouldn't care about world hunger. Maybe even less so if there might be agreement about both issues, different as they may be, having common causes.

I have made a lot of keyboard-related changes on the code, now I will try to summarize them. Also, I have tried to reach a state what probably all of us may find useful and also original working can be kept in case someone does not need additional features at all. Driver-related changes I have initialized some additional virtual nodes of keyboard driver's kernel module where driver's behaviour can be changed. Some additional settings were necessary to make them accessible to system UI. Also, I have borrowed some of the ideas like what @Sean McCreary has already done. Th

Just wanted to provide links to source files that makes our Pro¹ keyboard. That can be used as reference for anyone wanting to understand and customise Pro¹ keyboard experience by building Lineage OS. From low to high level files we have identified the followings key components: Device Tree Structure Include, contains GPIO pin mapping to scan codes: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/lineage-18.1/arch/arm/boot/dts/qcom/msm8998-qrd-skuk-t5.dtsi Permalink Driver, brings together GPIO and aw9523b controller input to define the scan codes sent to user space: h

Sounds a bit like "Trust the authorities, they will know what is good for us." 👮‍♀️ I am not saying they have no reasons for doing what they do. I am saying that those reasons have nothing to do with technology and are thus not valid. I believe they check against rooting as that breaks the App for only few technically-skilled customers, while giving all others the warm feeling that they care about security. Technically, checking the Android patch level (and refusing to run on outdated systems) would make much more sense. However they will never do that as it would affect way to

Indeed. It gets even weirder when not only a rooted, up-to-date LineageOS, but even an unrooted, up-to-date LineageOS with the latest security fixes is seen as a security issue by many banking apps, while an ancient Android 7 phone that never received any fixes is deemed secure enough for those apps to not complain... Don't get me started on this 😉

For an example of how to use the key layout file (.kl) to remap Linux keycodes to Android ones, see: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315173/1 That patch maps the Linux keycode KEY_CYCLEWINDOWS (154) to the Android keycode APP_SWITCH. Beware that the symbolic names for Android keycodes are not exactly the same in the C++ source code and the Java source code or the key layout files 😕 This can be a source of confusion and frustration.

I've implemented a new feature in Lineage OS Pro¹'s keyboard driver to be able to use Fn+Tab as Alt+Tab as this is most convenient for multitasking with two thumbs. This thread is to track that issue specifically so please stay on topic. I'm trying to contribute this back to official Lineage repository. Here is my change request on Gerrit: https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315155 There was also a pull request on GitHub but that's just going to be closed as the GitHub repositories are just mirrors I guess: https://github.com/Linea

Dear Members, I have tried to do some modifications on Pro1's keyboard driver and settings UI under LineageOS 18.1 For details, please look here: Compiled system can also be downloaded here for a while in case someone would like to try it. Be aware, this is a custom build and it will definitively not work applied on an official LineageOS build without doing a factory reset. The keyboard driver-related changes were pushed here: https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315281 UI-related changes were pushed here: https://review.l

Looks like there is hope for getting proper case open event handling on Lineage OS:

464 is by default associated with FUNCTION on Android: https://android.googlesource.com/device/google/atv/+/master/Generic.kl However for some reason @Sean McCreary wants us to use scan codes below 255. In your changes you took over some of Sean's defining left function as 195 and 196. That mean you should have something like that in your KL file: key 195 FUNCTION key 196 ALT_RIGHT Providing that you want the left function key to be passthrough as FUNCTION and the right function key to be passthrough as ALTGR which I reckon is the way we should go. I'm going to

Looking at your changes you did not setup in the KL file. See:

(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.

Well, authentication at an ATM is done using that same 4-digit pin. And banking cards get stolen all the time. So I am not sure about that argument. 🤔 We are wandering off-topic here, but I think it is an interesting discussion, so let's go. First, even looking at things in the most positive way, I fail to see how preventing root access from user space adds any security to the latter. After all, even with root access enabled, Apps do not gain that access right any more "easily" than any other permission. User interaction is required all the same. But then, there are more fundam

Yes, it seems to be yet to done.

I have uploaded temporarily the update file here. @EskeRahn, @Slion and others who may have chance for it - could you please try it and tell me if you find anything which could be improved? Edit: Naturally, additional layouts (key arrangement) can also be applied more easily.

Don't get me started on this 😉 After thinking about it, I see now that that rhetoric question was not very compassionate. That millions of children suffer from hunger is indeed unbelievable. That Apple and Google feist on user rights may be deplorable too, but it is also not that inevitable, after all ...

That sounds good. I wonder why there is no "light" version of Magisk as spritual successor of AddonSU. I really do not need all of that advanced stuff related to "hiding" the fact that I am rooted. Know what: I am proud of running a rooted device! I hate all that FUD spread by Apple and Google around rooted phones (despite them knowing better, of course). Guess what: I have root access to my desktop PC, my laptops and my (Internet exposed) home server. Of course that does not mean that *all* software on them runs with root privileges! And, yes, of course, my bank allows me to make transac

I know that isn't your only reason, but for others, if you sideload Magisk as a zip, it pretty much works as AddonSU did. Gives you root, doesn't require Magisk Manager (although it does install it—I ignore it), doesn't require any bootloader dance. It just gives root to the apps you grant root access to. Acts just like AddonSU for me. With Magisk 23.0, you have toe rename the apk to zip to flash it. And this install method is allegedly depreciated, but it works fine.

Well, even within Android there are use cases that require root management. E.g. file managers. However, the main reason is that I run a GNU/Linux chroot in parallel to Lineage that requires root access for all kinds of things. Last, I simply like the idea that I have full control of the system from userland if I want or need it. I consider my Pro1 to be more of a computer than an appliance. So I expect to have the same possibilities as admin than on my PCs. 🙂 Of course, Magisk could do all of that. I like AddonSU because it is low-profile, nicely integrated in LOS, and an "official"

I think I managed to fix mine ... or make it less crappy ... 🙂 When I removed the protective cover, I noticed that the double sided adhesive tape overlapped with the camera cut-out. We are talking 0.5 mm here, but it might have been enough to restrict the lens from moving. On the picture, I already moved the lower part out of the way. I ended up removing the adhesive completely ...

I'm curious about how you use 'su' or root access, if you're willing to describe it. For my part I haven't needed anything more than 'adb root; adb shell' for occasional administrative (mostly development) work in many years.

Sadly yes. As far as I know, that happened because changes in Android security mechanisms made porting AddonSU to LOS 17 non-trivial at best. One of the reasons I am camping on LOS 16 ...

Wow, I hadn't even noticed that the F-logo key was now indeed working as the search key with the Android keyboard short-cuts. Thanks. I also (though I may not be interpreting correctly) would hate to see any keyboard feature be exclusive to the launcher as I always use different launchers. As long as I'm interrupting. thanks to all of you working on this. Most of the current keyboard conversations going on are way over my head, but I'm sure I'll benefit in the long run from what you folks accomplish @Sean McCreary, @Slion, @VaZso, @Rob. S., @EskeRahn Thanks!

FWIW, I chose to map the 'F logo' (a.k.a. home) key as meta to mirror the app shortcut feature in stock. Of course, it works differently, and it uses the shortcut implementation built into Android rather than customizations in the launcher app. But the customized launcher is not open source, and we did not have permission to redistribute it.

Yes, you're right. The 'su' extra package was discontinued after LineageOS 16.0 😕 I don't use it, so I haven't been paying attention...

Maybe the usage of the Logo/Meta-key as the selector for the non existent physical keys would be even better than Alt/Sym/†, so the hardcoding does not touch the normal modifiers at all. This way any 'missing' key produced with Logo could be used combined with any modifier. And obviously if Logo is not pressed with a recognised key, it should be handled as Android Meta. The only drawback I see with this is that the Logo key pressed alone would not act as a Meta pressed alone, but plain Meta could be mapped just like any other 'missing' key. ....One could perhaps even map if met

Android uses meta for shortcuts, e.g. meta+B to switch to the web browser, and meta+E to switch to the email app. Also, META+ALT only works as CAPSLOCK in some contexts. For example, it will cause the shift state to be 'reversed' compared to the CAPSLOCK key LED in termux.

Allocating new keycodes is a workaround for a problem with input_report_key(), as it does not work for keycodes as large as KEY_FN (0x1d0, 464). Android supports remapping in the key layout file, and this is the strategy I have used in the past to generate Android keycodes. You can see the full list of Android keycodes here: https://github.com/LineageOS/android_frameworks_native/blob/lineage-18.1/include/android/keycodes.h Android uses the meta key for shortcuts, which is why the 'F logo' key is mapped to meta. For example, meta+B will switch to the web browser from anywhere in the O

Indeed, it would be clever if Fn was a modifier if (and only if) not hardcoded to produce a plain key (physically not present on the Pro1) (And whether this is to be Fn or Alt is an entirely different discussion *LOL* )

It is the key often represented with a magnifier glass for search, Also used combined for short cuts - I have no idea what else it is used for...

While my hardware (qwertz) in principle works well with AOSP keyboard (can disable autocapitalization in the settings, sticky shift works), I also observe some quirks in K9-Mail only. So maybe test also in other apps. Most annoying for me is that whenever I type "im" (german for "in"), that gets auto-replaced by "I'm", although AOSP keybaord is set to german input language and all auto-replacements are disabled in the settings. K9 is my only app that does that. Still hoping that misbehaviour will disappear with some update of the app as it seems to be the only (open-source) one to support

We can't really debug the problems without a test case that demonstrates them. However, it seems like the current custom keymap ought to support the uses you describe. Specifically, you can combine keycodes with any of the flag bits to make the driver issue whatever modifiers you need: I haven't tested whether the driver will correctly handle multiple flag bits set (e.g. for CTRL+ALT+Z), but we should be able to make that work too.

Nothing really special, it tries to use fn + mostly non-alphanumeric characters, so USA layout of [];'\/-= are all need to be used together with a modifier. The solution in keyboard driver uses another layer of emulated keypresses with the help of an array containing these keys. (So it can also say you pressed ctrl+c when fn+k was pressed and alt+j when fn+a was pressed or even ctrl+alt+z when you press fn+r where fn is the slant arrow.) This array was filled with really mixed AltGr, Shift or none additions of the base keypresses. As there are no modifiers applied or if there is,

It took a while, actually a long while. Seems like the first package got lost, but the second arrived in a week (+1 week customs). I was able to replace the camera and the backplate today in 1-2 hours. It was pain and not fun at all as I'm not used to so small connectors 😄. If you are careful it is possible though. I broke my power button a bit, which is not so clicky anymore and feels so wrong 😄 It was successful though, the camera works again. So it wasn't a software issue. The back is also as new now. And I could learn something new today.

Well the camera is Sony IMX363, but I don't think it's so easy replacing camera, as you can see in service manual, you have to disassemble the phone quite in complete (with de-soldering and other tricky things. And I think it will be difficult finding a spare camera by Sony, or you should take it from an other phone. In fact my advice is : - remove the plastic-glass behind -camera is a dual-lens rear shooter that combines a 12MP lens with a 5MP one. Try to move a little the 12MP (the big one, the small one doen't move), carefully. For what I see, stabilizer is a very small

Hello, Using gelraen teardown I disassemble my Pro1. I remove dust and (thanks to @DieBruine) screw down with loctite all what I see with abnormally operating clearance. I play a little with cameras stabilizer, everything looks normal. (My phone felt 2,50 m a month ago, and I only had VERY blurry pictures). I reassemble, and test. Oh, pictures look blurry (a little). Then I disassemble the cameras plastic-glass behind, play a little with cameras stabilizer, reassemble glass. (see attached picture from service manual) Surprise ! This camera works perfect, I can now taking pictures

That is perfect, thank you - I think that is why it can be used in .kcm files as FUNCTION 🙂 ...but that also mean this should be used in .kl, so thanks again. Yes, I have used them for slant arrows. I think no - key 195 and 196 may remain intact (unused) but keyboard driver may report 464, so I should do the map of: key 464 FUNCTION ...at least this is what I thought it would work. In the driver what I am worked on, there is a variable which defines the scancode of each function keys present (so left arrow, right arrow and f(x) key). This variable can be set using

Same issue here. double "e", sometime no "d" or "a" and now and then the keyboard lags (words displaying on screen 3 to 4 words behind what I'm typing). I had the lag issue on my Nokia E7 a couple of months before switching to a BB Priv, so after about 3 years of use. Really a shame since typing turned from fun to annoying. Both issues described above not happening constantly, so this makes me think they are both software issues. I monitored CPU usage for a bit, but as of now, I couldn't pinpoint an app that bottlenecks the CPU.