Leaderboard
Popular Content
Showing content with the highest reputation on 08/29/2021 in all areas
-
There does seem to be a bug in the settings app that is preventing this from working π I will try to figure out why.4 points
-
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"3 points
-
I tried to read through the lengthy discussion from the past week, and I hope I got the gist. But please correct me if I mischaracterize anything below. The problem with the FinQwerty solution that worked on the stock OS is that it required a new map for each physical layout, while the set of language-specific key character maps supplied with Android were basically useless. @tdm managed to fix this by creating a new keymap layer in the kernel keyboard driver, allowing the key character maps supplied with Android to work with the built-in keyboard of the Pro1. Now, things got a little3 points
-
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 transac2 points
-
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.2 points
-
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!2 points
-
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.2 points
-
Lately, once in a while I get two 'e' characters instead of one, which definitely looks like the result of wear. I still hope that one day we'll get those replacement keyboards Fxtec originally hoped to be able to offer at some point, which seem to be easy enough to replace at home... We'd also be able to exchange a QWERTY keyboard for a QWERTZ then, or vice versa, or a shifted QWERTY for a non-shifted QWERTY...2 points
-
(Very late to last weeks many post in this thread) I think this looks like a PERFECT solution with two optimized build in layout-interpretation, but ALSO to have one additional mirroring stock. I bet it will be very little overhead code, but will be very helpful for various international users to be able to benefit from the work of @Anssi Hannula and others without having this to be redone in LOS-variants.2 points
-
Yes, I see KF_FN is defined as 0x0400 but there is no code to send KEY_FN based on g_logical_modifiers. BTW, keycode 464 isn't handled properly by input_report_key(), so we would probably have to use a keycode < 255 and remap it in the Android .kl file to make that work. The settings app should gain a new 'toggle' setting when a file is placed at '/data/system/keyboard/keymap'. You then need to enable the custom keymap in settings for it to be loaded into the kernel. LineageOS provides root access via 'adb root; adb shell', or with the optional 'su' add-on package.2 points
-
This is normally because META+ALT acts as CAPSLOCK in Android, but does not turn on the LED embedded in the CAPSLOCK key. If your shift state is reversed, try pressing the 'F logo' and 'Alt' key next to it together.2 points
-
"Oops". I have opened a change with this keymap fix at https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315195 I think the problem is that none of us actually have a QWERTZ layout Pro1, so the keymap may not have been well tested π I can revise that change with any other mapping errors you find.2 points
-
Having done this before, the changes are straightforward. See: https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/3151832 points
-
To keep on improving on our Lineage OS keyboard driver implementation here is a proposal about Fn passthrough. At the moment Fn modifiers AKA Yellow slant arrows are being handled internally by the driver and not passed as such to the application layer. Which on one hand is needed, notably to generate the proper key scan code without modifiers, think / and ?, however on the other hand it starves the application layers from an otherwise perfectly valid modifier which could be used in custom KCM layout notably to improve international characters support on thumb keyboard. Therefore thi1 point
-
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 ...1 point
-
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. Th1 point
-
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 π1 point
-
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 ...1 point
-
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.1 point
-
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 ...1 point
-
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.1 point
-
I can charge in the LOS recovery, so it's limited to chaging in LOS.1 point
-
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...1 point
-
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.1 point
-
1 point
-
(Phew that took a while to get through all the posts the last week here π )1 point
-
1 point
-
I disagree, if QWERTZ print-layout only work some languages, it sure should be considered a bug. The smart idea by @tdm to have a setting selecting the print-layout, independent of the language selection, is a MUCH smarter solution than what we got on stock. Look at all the 'doubles' @Anssi Hannula made to make things work, e.g. Danish for qwertY print and Danish for qwertZ print. The idea by @tdm to convert the keyboard to a standard one, and then have standard android languages on top is clever, as it means that any language known by Android should work out of the box. And the point o1 point
-
Yes as it is you need to overwrite the Kernel copy of the keymap for it to work. That would be awesome if you could fix that.1 point
-
As far as I can see, it supports multiple flags (but currently FN is not among them) and somehow it does not automatically load custom keymap, it can only loaded through the kernel module interface. Also, it needs root access.1 point
-
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.1 point
-
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,1 point
-
This is just weird. I tested it just before I posted before I a swear it was working. But closer examination seems to show a highly varied response of different apps in terms of a) whether they autocapitalize, b) whether they follow the soft keyboarsd setting and c) whether they offer a control of their own for Autocapitalization. This is all in terms of what the hardware keyboard does in the case of having the AOSP soft keyboard with the Autocapitalization setting. Aquamail, based on K-9 , ignores the setting and always Autocapitalizes, as does Google messages. The Browser Fulguris ignor1 point
-
Again, as far as I can tell, this is controlled by the the soft keyboard. AOSP keyboard has sticky shift (but no setting for it) but it does have an autocapitilization toggle. If you turn it off in the soft keyboard, the hardware keyboard no longer does it.1 point
-
On the subject of "it's obsolete the day it's out", well yeah, it's true and the price is a little bit out of touch compared to Samsung mega factories, but it's not the same production scale, and we have enough alternatives if we must. But this obsolescence is not very surprising tbh: I never bought a phone people were not scoffing at one year later, asking me when I'll upgrade... at best. Most times they look at you with pity you couldn't buy the latest iphone the day you got your normal "I'd rather buy cheap phones I can break than break a 1.2k iphone and have to pay hundreds for a new scree1 point
-
I wonder if this could be related: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/314887 Maybe there is a fix coming up.1 point
-
In case you have root, you can take a look at /sys/class/power_supply/... For my Moto Z Play, I made an Automate Flow (script) to read and write to certain files (e.g. in /sys/class/power_supply/usb/) to control charging speed, stop charging at 85%, and even prevent apps like the Play Store to detect that the phone was charging. I did not have the time yet to make a script for the Pro1, so I can't tell which subdirectory in /sys/class/power_supply/ controls charging... /sys is a virtual file system connected to the kernel. You can open files under /sys (as text files) to get informat1 point
-
Nothing new here I was doing that back in 99 already ππ1 point
-
First things first: Congratulations! You have just build your own operating system for your phone. May zombie-apocalypse come, you will be among those who rebuild the world. Time to open a beer or something. It's interesting that you have a much more powerful CPU than mine but still get similar build-time (all assuming the amount of code is similar from LOS 16 to LOS 18). Mine is an ageing Core-i3 3220T, with only 3 of its 4 (hyperthreaded) cores assigned to the VM. It is my home server, which I use because its the only machine that runs 24/7 anyway. And, as the server does many othe1 point
-
Yes it will be possible to have a profile matching stock.1 point
-
1 point
-
We are aiming at better than stock π Exactly just offer more driver level layouts As I explained above already, I want to do alt+tab using the right Fn which is what Fx Qwerty does for instance. Doing alt+tab using the left alt is very unpractical with two thumbs.1 point
-
1 point
-
Seriously it worked really well for me under stock OS - I took the project what @Anssi Hannula has created (finqwerty), removed all the layouts from it and only installed two custom layouts for me, but only one of them was in use on my Pro1. That was a custom build renamed to not conflict with original software which was also installed. Anyway, these kinds of custom layouts do not consume power resources like a special application would, these layouts are reachable in the same way like original layouts - absolutely a perfect solution which does not need root access but exactly works lik1 point
-
Actually the driver source code it says: * Note that there are two each of the shift, ctrl, and alt keys, but * each pair are driven by a single gpio. Thus, left and right cannot * be distinguished for these keys.1 point
-
I'm currently busy setting up my Lineage OS build environment. I'm more then happy to take on your feedback. And yes I still think the way forward is to provide more layout in the kernel so that there is something for everyone including crazy remappers like you and me. Here are the layout I envision, keep the current ones with silent Fn: qwerty qwertz Improved layout with non silent Fn and possibly Meta key, thus providing application level with as much modifiers as possible: qwerty-ex qwertz-ex @EskeRahn @Waxberry or @Erik Do you recall which keys are actually1 point
-
@VaZso I did not read all that last big chunk of text. However some of it gave me an idea. It looks like ATM we have like two profiles QWERTY and QWERTZ. I wonder if we could modify the driver to add more profiles QWERTY and QWERTZ variant that would be compatibly with stock so that FinQwerty and other mods would work the same. I would probably also add another profile that's improved on stock. If this is doable I guess we would have good chances to get those changes committed to the official LOS repository. I'm currently downloading the whole LOS source code to inspect it a1 point
-
Fixed it! Thanks @_DW_ for pointing to Google's USB driver. It needs to be installed, however you also need to modify the driver INF file so that it lists Pro1 as compatible. Since you modify the INF you also need to have Windows setup in test mode so that you can install unsigned driver. Thankfully I had that enabled already as I've been working on some Windows driver implementation lately. You need to add the following lines to the INF file [Google.NTamd64] section (assuming you are running Windows 64 bits): ;F(x)tec Pro1 %SingleAdbInterface% = USB_Install, USB\VI1 point
-
And as many phone hardware drivers (including for the Pro1) are closed source, it would be no easy task to rewrite them natively for a pure Linux experience.1 point
-
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.1 point