Jump to content

Slion

Members
  • Content Count

    1,485
  • Joined

  • Last visited

  • Days Won

    36

Everything posted by Slion

  1. I do not know. I'm new to this. Some people where saying they need to re-sideload Magisk. Maybe either Gapps or Magisk does the trick somehow.
  2. Sideloaded another build from my Virtual Box and got stuck in reboot loop. Sideloading MindTheGapps on top fixed it. Looks like I always have to sideload gapps after ROM update otherwise it won't start.
  3. After sideloading my Virtual Box Ubuntu ROM on top of my WSL ROM it got stuck in a reboot loop. Then I found this: https://www.davehofmann.de/how-i-fixed-a-boot-loop-after-a-lineageos-upgrade/ Flashing the boot.img recovery from that same ROM, did not help, at least not in itself. Sideloading MindTheGapps again fixed it.
  4. I'm using official 18.1 recovery and that's not an issue for my custom builds.
  5. Yes, I just tried again and it worked. I guess the first time around it was sent to the wrong slot.
  6. Was fast for me. Correct. With the UI it would be easier to edit the source code. Maybe you were still pointing to the wrong slot where you had the official build before somehow? I have not idea though, I don't fully understand those slots.
  7. @claude0001 I'm in the process of setting up a VirtualBox for my custom build. Will I need to reset my phone if I sideload the resulting ROM on top of my WSL ROM?
  8. 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
  9. 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
  10. I doubt that, 464 is the actual FUNCTION default in Generic.kl so definitely not a Linux or Android limitation. I wonder if @Sean McCreary may have fixed it last night.
  11. Yes, I figured that's what it must be this morning as I was thinking back about this. Though it's possibly the other way around: A = Case B = Keyboard As A is currently mapped to 468 which is what I've been using to detect the case closure.
  12. @Sean McCreary Thanks for sharing that with us that helps a lot understanding it all. Moving forward I think we should have the following mappings: The left Fn key should be passed through as FUNCTION when no specific keymap entry is present. The right Fn key should be passed through as ALT_RIGHT when no specific keymap entry is present. The Sym key should be remapped to SYM instead of ALT_RIGHT. That would give the application layer maximum opportunities for customization using KCM files. It should enable actual Alt+Tab using right Fn+Tab even though special handling in t
  13. Looks like there is hope for getting proper case open event handling on Lineage OS:
  14. While working on our keyboard I could not help but noticed those oem_halla and oem_hallb GPIO events definition: https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/lineage-18.1/arch/arm/boot/dts/qcom/msm8998-qrd-skuk-t5.dtsi As I'm the developer of Fx Service which provides smart case functionalities for Pro¹ I can tell oem_halla is the case close event and I'm guessing oem_hallb is the case open event. @Sean McCreary Is there any chance we could reroute those events to Android Sensor API somehow? I reckon that should make them more useable especially the case o
  15. 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
  16. 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
  17. Looking at your changes you did not setup in the KL file. See:
  18. Not sure that was my problem. Do we use META at all in the current keyboard? Can't reproduce it.
  19. 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.
  20. Thanks for putting this together. I have not tested it but from looking at the code I fail to see how Android will understand those new scan code you introduced as Fn. Also From the KCM documentation there it no such thing as left and right function so I was thinking we should report them as left and right meta. However I don't know what meta is usually used for on Android so maybe that could conflict with other features. Your changes just report every Fn regardless of the mapping. That's not what I had in mind. For instance your patch would not be able to report '?' or '/'
  21. I'm using ASK too and I don't have auto caps. Nor do I have sticky shifts. At least not in WebView based browsers. Maybe it depends on the app somehow but I doubt it. Settings search field also does not have auto caps and stick shifts here.
  22. Is there not a different set of settings for hardware keyboard?
×
×
  • Create New...

Important Information

Terms