Slion 1,201 Posted August 30, 2021 Share Posted August 30, 2021 (edited) 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 open event that's not coming through since your device is locked and keys are apparently not passed to apps and services anymore, that was the case on stock. On Lineage OS, since oem_hallb is set to scan code 0 I reckon it is even less usable and likely to reach apps… Found those resources, maybe that could help:https://forum.xda-developers.com/t/looking-for-help-to-get-flip-cover-working-on-custom-roms.3720299/https://cs.android.com/android/platform/superproject/+/master:frameworks/base/services/core/java/com/android/server/display/DisplayPowerController.java Edited October 17, 2021 by Slion 1 Quote Link to post Share on other sites
EskeRahn 5,460 Posted August 31, 2021 Share Posted August 31, 2021 The Hall_a is the keyboard open/close detector, the Hall_b is the one in the display (case detection) They are called a and b in the 'factorykit'-test (The one just above OTG almost at the bottom) See this 1 Quote Link to post Share on other sites
Slion 1,201 Posted August 31, 2021 Author Share Posted August 31, 2021 3 minutes ago, EskeRahn said: The Hall_a is the keyboard open/close detector, the Hall_b is the one in the display (case detection) 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. Quote Link to post Share on other sites
Sean McCreary 328 Posted August 31, 2021 Share Posted August 31, 2021 2 hours ago, Slion said: 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. 468 is what Google chose to use in the Android framework to signal keyboard slider behavior, for example it is what forces the display into landscape mode when the keyboard is open. Unfortunately, they also use the same keycode for case events 😞 Changes to this will be difficult to merge into LineageOS, as the code is shared among all devices. This is why our fix for non-English keymaps and accessibility apps was rejected... 1 2 Quote Link to post Share on other sites
EskeRahn 5,460 Posted August 31, 2021 Share Posted August 31, 2021 7 hours ago, Slion said: A = Case B = Keyboard Swapped: A=Keyboard, B=Case - at the least that is the naming used in the FactoryKit.... 1 Quote Link to post Share on other sites
Slion 1,201 Posted September 1, 2021 Author Share Posted September 1, 2021 16 hours ago, Sean McCreary said: This is why our fix for non-English keymaps and accessibility apps was rejected... Do you have links to those? Quote Link to post Share on other sites
Sean McCreary 328 Posted September 1, 2021 Share Posted September 1, 2021 8 hours ago, Slion said: Do you have links to those? 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 3 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.