Leaderboard

@VaZso That's my understanding too. What Sean is suggesting is definitely an extension of your work taking things even further by making it more generic. Great team work guys.

Yes, my proposal is based on your work 🙂 I am trying to simplify the implementation a bit, and extend it to more remapping cases.

After a bit of thought, it seems like we can enable most of the remapping scenarios people have requested if we create a method for remapping the six modifier keys: shift, ctrl, fn_l, home, alt, and fn_r. I am proposing a new remapping interface that will accept a list of keycodes for these six keys, where 0x00 will designate a key that should operate the way Fn does currently (i.e. no keycodes are sent to Android, and it 'shifts' the internal kernel keymap instead). This will allow maximal remapping of the keyboard, but also enable every possible key combination. I am specifically propos

Don't do anything with your CR. I will push a new one rather than stomp on yours 🙂 If you like it better, you could abandon your CR sometime in the future. But my goal is to collaborate, rather than compete!

Isn't it is what I have done here? Okay, currently if does not remap "ctrl" and kernel interface may use a similar method like what "keymap" interface does (so x:y:z), but it remaps fn_l, fn_r, F(x) keys and 0x00 will keep default behaviour. Also, it has an option to remove special behaviour of fn key currently has as opt out, so special key transformations may also be enabled or disabled which could also make stock behaviour possible by disabling it and setting fn_l and fn_r the same as in stock Android.

That is a case which could *almost* be supported with the additional key remapping feature I am proposing. Currently the '/' and '?' mapping via Fn+P and Fn+L is remappable, as those keys are #28 and #31 in the keyboard matrix. The new idea is to allow remapping additional keys, which would allow you to use a custom keymap to remap fn_r to a single keycode. Two make the keycode it generates vary by context in the kernel, you would have to use 'shift' as the internal kernel keymap shift key (how KEY_FN is currently used in the driver), which would have side-effects for the rest of the mapping

The current custom keymap feature does not support remapping shift, ctrl, alt, home, or either fn_l or fn_r.

To be clear, I am talking about the six keys attached to dedicated GPIO lines. the SYM key is #24 in the keyboard matrix, currently mapped to KEY_RIGHTALT but also remappable using the existing custom keymap feature.

I'm not sure we will ever come to a general agreement about how the keys *should* be mapped. Consequently, I think we should concentrate on enabling even more flexible remapping options, and allow sophisticated users to choose what mappings work best for themselves and their language. I've posted a brief outline proposal in the old remapping thread, and I would appreciate your feedback on the idea.

I never had Gapps installed, but I am pretty sure that at the time LOS 16 was in testing phase, @tdm always reminded people not to forget to reinstall them after flashing a new version via sideload.

This is the change that fixed the problem on our device, but caused problems on others: https://review.lineageos.org/c/LineageOS/android_frameworks_native/+/312770

Did you try:

I guess from what's been reported here so far it's safe to conclude that a run-down battery is largely unrelated to the phenomenon, except that the phenomenon helps a lot in letting the battery run down 😉

My custom 17.1 installed just fine (from the official LOS17.1 recovery) ... to my own surprise. Flashing my boot.img failed because I can't get fastboot to cooperate on my PC (Windows 10 and Ubuntu).

Just a thread for questions about Lineage OS custom builds. See: https://lineageosroms.com/pro1/#build See also: https://slions.net/threads/lineage-os-for-f-x-tec-pro1.90/ ROM update process: Sideload ROM Reboot to recovery Sideload GApps Sideload Magisk Reboot

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.

I am asking because I don't know exactly how this system (Gerrit) work or what related functions it may has. Generally what I wanted is to do something which I can use in a way I would like and what is also suitable for everyone. ...and you are right, what is also interesting would be ctrl, alt and also sym as additional modifiers to reach a maximally custoizable state. ...and I am agree it is not a competition, simply these and additoional features would be really good to have. Also, "custom keymap" option has disabled other options when custom keymap file exists even if i

So you want to extend our keymap to support them too? Sounds good to me.

Maximal flexibility sounds good to me but sensible defaults is also important as most people will just use that. Also keep in mind that you can already remap your modifiers from KCM. However being able to remap them from our keyboard advanced settings sounds a lot more practical to use assuming this is what you have in mind.

I've posted a brief outline proposal in the old remapping thread, and I would appreciate your feedback on the idea.

I did, and I appreciate(d) your instructions :-). Although I don't quite get why fxtec doesn't provide a signed driver ... Anyways, I only got fastboot to detect my phone. Any other command besides "fastboot devices" failed on Windows and Ubuntu, and all USB ports (four ports provided by four different controllers on my mainboard). Flashing boot.img (to boot, boot_a or boot_b) failed either because fastboot claimed the boot partition was too small, or because the phone stopped responding or rebooted. ADB worked without any problems.

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

Indeed, but wasn't that something that's been reported very early and also fixed in the first stock Android update?

I'm using official 18.1 recovery and that's not an issue for my custom builds.

Yes, that's the correct procedure, which worked for me since I got my Pro1. Upon flashing the ROM it switches the active slot. A reboot is then needed to make sure any additional software is actually sideloaded into the right OS.

Yes, I just tried again and it worked. I guess the first time around it was sent to the wrong slot.

Since you are saying you are poor I would say yes, go for big brand high volume phones. You could also save money by not getting the flagships as well, go for midrange models instead. Pro1x is not for poor people I'm afraid as you better make sure you have a backup phone just in case your Pro1 has an issue. Low volume devices from startups are more likely to have technical issues. Moreover if you buy a Pro1x today you just don't know when or even if you will ever get one. It is a risky pre-order and your money is gone long, long before you get the device. Having said that you need to know

Update: I can now run the X.org X11 server inside my Devuan chroot. Yes, the real thing, not TigerVNC or TightVNC. The nice thing with X.org is that I can use it with xorgxrdp in the chroot and connect to my Linux distro via a much better-performing (native) RDP connection as compared to using VNC as backend for XRDP. I still use the Microsoft Remote Desktop 8 App combined with the default xrdp-0.9.9 shipping with Devuan 3/Debian 10. As far as I can see, one can find no information on how to do this on the internet. Either it is really tricky and I am a genius, or no one cares about