Alright, I must say, I'm not a fan of hardware navigations keys. That is a reason as shallow as it can be to some but not for me, I like it on-screen.
So my question is, is there an existing ROMs around that supports that feature even on a phone with hardware navigation keys?
If yes, are they planning to support 7a? Thanks all in advance.
PS: doesn't want to start with the hardware versus on-screen argument(or get a phone with on-screen instead), just want to know if there are ROMs that do that
Afaik there is a xposed framework plugin that enables onscreen buttons
Dat-Guy said:
Afaik there is a xposed framework plugin that enables onscreen buttons
Click to expand...
Click to collapse
good to know:good:
although, personally, I prefer it be built-in into the ROM coz sometimes xposed(or maybe the module) gets in the way of the ROMs' stability, etc. as far as I've seen on other threads
but if that's the last resort, I may still consider that xposed thingy
If I can set the hw buttons behavior I don't see the point in using SW buttons.. The space is used, so why to reduce dimensions of the useful screen?
andriman said:
If I can set the hw buttons behavior I don't see the point in using SW buttons.. The space is used, so why to reduce dimensions of the useful screen?
Click to expand...
Click to collapse
as i've mention, it's my preference and don't want to start an argument with on-screen versus hardware nav keys
to each his own and i understand that
and yes, it's also good if the hardware can be set as back-HOME-recent setup, I can tolerate that(again personally my opinion only)
I just saw One+'s feature regarding switching to on-screen or capacitive keys. That's quite neat being a built-in feature. Oppo 7 hope will have this built into their ROM as well.
Tapatalked from my Nypon
I prefer on screen buttons myself so I can set them up my way (four across in my chosen order) but I cant say I would be willing to give up screen area for them as you would be doing here. Regardless xposed will usually play well with others if you keep it to a minimum, its when you pile on the changes that things usually go wrong. Might be worth a try if nothing else comes up.
i already found a way to disable capacitive buttons and enable onscreen/soft-keys buttons. Its pretty hacky though and involves root and commenting a few things in Generic.kl in system/usr/keylayout. Also adding a line to build.prop
ayysir said:
i already found a way to disable capacitive buttons and enable onscreen/soft-keys buttons. Its pretty hacky though and involves root and commenting a few things in Generic.kl in system/usr/keylayout. Also adding a line to build.prop
Click to expand...
Click to collapse
PA dev to the rescue! Thanks man.?
Rycon33 said:
PA dev to the rescue! Thanks man.?
Click to expand...
Click to collapse
ill see if i can make a flashable zip with this mod
ayysir said:
ill see if i can make a flashable zip with this mod
Click to expand...
Click to collapse
Great, the 7a will be available here at my place next week. So having this mod ready is really good. Just hope there's no delay on the availability here.
While I've generally been "not a fan" of hacks like this, since CM is officially doing it on the OnePlus - I'm going to look into this eventually for Omni. (I think maxwen has already implemented 75%+ of it on the N1...)
With Omni though, my top priority after basic bringup is figuring out a way to have unified storage in an optional way.
ayysir - don't try to use the omni f7a kernel in its current state BTW. I screwed up merging something somewhere in the display code and it IOMMU faults where stock usually does the contsplash handoff.
I love you for this entropy.
Gesendet von meinem MI 2 mit Tapatalk
Entropy512 said:
While I've generally been "not a fan" of hacks like this, since CM is officially doing it on the OnePlus - I'm going to look into this eventually for Omni. (I think maxwen has already implemented 75%+ of it on the N1...)
With Omni though, my top priority after basic bringup is figuring out a way to have unified storage in an optional way.
ayysir - don't try to use the omni f7a kernel in its current state BTW. I screwed up merging something somewhere in the display code and it IOMMU faults where stock usually does the contsplash handoff.
Click to expand...
Click to collapse
Unified storage? Oh yes. That would rock. I have no idea why OPPO chose to go with the ancient implementation of the 3GB partition for apps.
I prefer hardware keys myself, but giving people the choice would be cool.
I can't wait until I get my 7a.
Sent from my HTC One using Tapatalk
Entropy512 said:
While I've generally been "not a fan" of hacks like this, since CM is officially doing it on the OnePlus - I'm going to look into this eventually for Omni. (I think maxwen has already implemented 75%+ of it on the N1...)
With Omni though, my top priority after basic bringup is figuring out a way to have unified storage in an optional way.
ayysir - don't try to use the omni f7a kernel in its current state BTW. I screwed up merging something somewhere in the display code and it IOMMU faults where stock usually does the contsplash handoff.
Click to expand...
Click to collapse
nawh im not, im basically trying to help out which way i can for ya
btw, oppo messed up on back key software keys drawable
ayysir said:
nawh im not, im basically trying to help out which way i can for ya
btw, oppo messed up on back key software keys drawable
Click to expand...
Click to collapse
Omni kernel is now usable - at the very least, the kernel/device tree produces a usable TWRP.
It also builds successfully when using blobs from teamgruntled - but I have yet to actually try flashing it. (plan is to whip up an eng build tomorrow, I'm too busy tonight to make any progress.)
Entropy512 said:
Omni kernel is now usable - at the very least, the kernel/device tree produces a usable TWRP.
It also builds successfully when using blobs from teamgruntled - but I have yet to actually try flashing it. (plan is to whip up an eng build tomorrow, I'm too busy tonight to make any progress.)
Click to expand...
Click to collapse
great bro, its omni's repos?
ayysir said:
great bro, its omni's repos?
Click to expand...
Click to collapse
teamgruntled for blobs temporarily since I might forcepush-rebase the blobs once or twice, kernel/device tree are in omni github.
Current state of the device tree is almost guaranteed to result in massive bogosity if flashed. As in if I'm afraid to flash it to my device you should be too!
Entropy512 said:
teamgruntled for blobs temporarily since I might forcepush-rebase the blobs once or twice, kernel/device tree are in omni github.
Current state of the device tree is almost guaranteed to result in massive bogosity if flashed. As in if I'm afraid to flash it to my device you should be too!
Click to expand...
Click to collapse
i know, the main objective is for me being able to compile it then back track from there
atm though i am recieving this issue: http://jenkins.hostingsharedbox.com...l=93.buildbot.hostingsharedbox.com/20/console
dtb related
Related
Hi Dev's
This is not my code, so credits to the owner 'creams'
I happened to stumble on some code yesterday from somebody who have attempted to integrate BLN to his kernel and done it successfully.
I thought the dev's might like to take a look at this one and implement this on their work.
blog : http://creamsnexus.blogspot.com/
git : git://github.com/creams/SGS2-SC02C-BLN-Kernel.git
His kernel was built for the Jap version of GS2.
Cheers!
AdamG has already implemented this into his AOSP ROM and it's working fantasticly, I know another Dev has already implemented it into a ROM just forgot his name. Thanks for pointing us to the source though!
hope that the devs give credit to the fix/implementation.
Ninpo also has putted it into his GIT so maybe they are already aware of it
oh i gave him a pm about it before i posted this.
samaral said:
oh i gave him a pm about it before i posted this.
Click to expand...
Click to collapse
July 31 in his GIT. You're ahead of him maybe.
I hope we will get it on MIUI and CM7 as well
vegetaleb said:
I hope we will get it on MIUI and CM7 as well
Click to expand...
Click to collapse
Don't know about MIUI but for sure on CM7. It's probably low on their to do list but BLN is something they will most definitely support just as they did with the 2X/G2X
mach0boi said:
July 31 in his GIT. You're ahead of him maybe.
Click to expand...
Click to collapse
im from the past
i didnt check his git commit date. thanks for the correction.
Do i also need to install any app from the market to enable it ?
Answer : Yes
Sorry if this is a noob question but what is BLN?
soupiejr said:
Sorry if this is a noob question but what is BLN?
Click to expand...
Click to collapse
Back Light Notification
using the led keys for notification.
Yay, my kernel will have BLN support to in the next version, just need to build all the seperate versions
(time to make a "one-for-all" kernel, that goes onto any (stock) ROM.... )
the only downside to this bln "version" is that it uses a kernel wakelock that will be hard on the battery
ogdobber said:
the only downside to this bln "version" is that it uses a kernel wakelock that will be hard on the battery
Click to expand...
Click to collapse
Yep, people are in for a treat when they realize their battery is being raped. We'll have to wait for CM7 to implement it into the framework like they did with the Optimus 2X/G2X
Nothing can beat the old good trackball lights on N1
It's a pitty all the brands stopped producing trackball,they could just reduce its size
ogdobber said:
the only downside to this bln "version" is that it uses a kernel wakelock that will be hard on the battery
Click to expand...
Click to collapse
jlevy73 said:
Yep, people are in for a treat when they realize their battery is being raped. We'll have to wait for CM7 to implement it into the framework like they did with the Optimus 2X/G2X
Click to expand...
Click to collapse
Yeah.... that is.... so not nice.... but well.... can't have everything.... :-/
// EDIT
Hm, for one, maybe some things can still be tweaked in the involved kernel code and for the other, how about disabling BLN when not needed? Does that release the wakelock? Haven't checked yet.... should check....
And does the drain/wakelock accour all the time while while activated or only when the lights are actually on - as far as I understood it so far the wakelock ist required to keep the powersupply up for the lights, but when no blinking is needed (due to no notification) the wakelock could/should be released....
Maybe that's something to tweak if that isn't already the case.
If the drain only accours when the lights are on, that's kinda OKish IMO, time to answer the damn phone *lol*
so creams put out an update that is supposed to release wakelock after the led cycle (pro app needed)
That would be an acceptable solution, I am testing to see
ps, btw jlevy he wasn't keen to your battery rape comment
HellcatDroid said:
Yeah.... that is.... so not nice.... but well.... can't have everything.... :-/
// EDIT
Hm, for one, maybe some things can still be tweaked in the involved kernel code and for the other, how about disabling BLN when not needed? Does that release the wakelock? Haven't checked yet.... should check....
And does the drain/wakelock accour all the time while while activated or only when the lights are actually on - as far as I understood it so far the wakelock ist required to keep the powersupply up for the lights, but when no blinking is needed (due to no notification) the wakelock could/should be released....
Maybe that's something to tweak if that isn't already the case.
If the drain only accours when the lights are on, that's kinda OKish IMO, time to answer the damn phone *lol*
Click to expand...
Click to collapse
ogdobber said:
so creams put out an update that is supposed to release wakelock after the led cycle (pro app needed)
That would be an acceptable solution, I am testing to see
Click to expand...
Click to collapse
NICE!
Compiler is already running
ogdobber said:
so creams put out an update that is supposed to release wakelock after the led cycle (pro app needed)
That would be an acceptable solution, I am testing to see
ps, btw jlevy he wasn't keen to your battery rape comment
Click to expand...
Click to collapse
It wasn't anything personally directed at him. I'm very grateful for his work in bringing BLN to our devices. I appreciate the update it looks like it will have a helpful impact on battery life.
I have always dreamed of having the double-tap-to-wake function on this phone. As far as I know, the kernel has to be capable of supporting this feature.
So I was wondering... Is it possible for any developer to modify or create a kernel that supports this feature? I feel that this will be very appreciated by the G Pro community. Also, if the is a hardware or any type of restriction, please tell me.
Thank you for your attention
Well Dan its all up to our master @Emmanuel U if he decide to integrate it.
Personally i dont think it's a good idea. I had it on 4.3 roms (back in days) with mserg kernel(i think),
and as a postpaid user dont need it. I had a lot of in pocket unlocks and some nice surprise bills
It would be nice as a possible enable/disable feature but prolly wouldn't use it... cheers :good:
srbin.cobanin. said:
Well Dan its all up to our master @Emmanuel U if he decide to integrate it.
Personally i dont think it's a good idea. I had it on 4.3 roms (back in days) with mserg kernel(i think),
and as a postpaid user dont need it. I had a lot of in pocket unlocks and some nice surprise bills
It would be nice as a possible enable/disable feature but prolly wouldn't use it... cheers :good:
Click to expand...
Click to collapse
You're right with the accedental unlocks, but it would be nice to have it as an option. I use a case that covers back and screen, so there are less probabilities for that to happen in my situation. I know it's not necessary, but again it's nice to have more options available. Best regards
srbin.cobanin. said:
Well Dan its all up to our master @Emmanuel U if he decide to integrate it.
Personally i dont think it's a good idea. I had it on 4.3 roms (back in days) with mserg kernel(i think),
and as a postpaid user dont need it. I had a lot of in pocket unlocks and some nice surprise bills
It would be nice as a possible enable/disable feature but prolly wouldn't use it... cheers :good:
Click to expand...
Click to collapse
I can look into implementing it, but I would never default it enabled or even encourage using it. Those kinda things like to suck up battery plus like you said, can have unintended outcomes.
I agree, I think it would be a cool feature to be able to enable/disable.. --- Anything on this yet??
miui port for e988, already got doubletap to wake/sleep, swipe to wake/sleep for a very long long time
Paleskin said:
miui port for e988, already got doubletap to wake/sleep, swipe to wake/sleep for a very long long time
Click to expand...
Click to collapse
I´ll try it thanks, but I would like to have it on AOSP CM based roms, that´s why I asked for a kernel.
Heads up
Just a reminder that I haven't forgotten about this request, I just haven't had enough time to develop anything recently. I'll try to get something going soon, but no ETA with school back in session
@Emmanuel U by chance could you be able to get knock on/off working for the L.P. rom by bountyman? I know you have CM work just thought I would ask lol
Sent from my LG-E980 using Tapatalk
crashpsycho said:
@Emmanuel U by chance could you be able to get knock on/off working for the L.P. rom by bountyman? I know you have CM work just thought I would ask lol
Sent from my LG-E980 using Tapatalk
Click to expand...
Click to collapse
Well I've already implemented sweep2wake and doubletap2wake, I can look into that soon.
Edit: that seems to be a rom feature, like double tap status bar to sleep
Right we have doubletap2sleep but its th wake function that doesnt work i found an alternate method but it uses the proximity sensor and wakes on its own the pocket
Sent from my LG-E980 using Tapatalk
I've added it to Build #4 of WildKernel...I also added support for it in Tame
Emmanuel U said:
I've added it to Build #4 of WildKernel...I also added support for it in Tame
Click to expand...
Click to collapse
I have flashed the latest build and everything works great, including the 2T2W. Thank you!
I have made a mod for the oneplus one. And since i think these devices have much in common I'm curious if the mod works on the find7 as well.
Is there anyone who wants to try it?
OG Thread: http://forum.xda-developers.com/one...launch-app-screen-off-camera-gesture-t3186507
Thomson2412 said:
I have made a mod for the oneplus one. And since i think these devices have much in common I'm curious if the mod works on the find7 as well.
Is there anyone who wants to try it?
OG Thread: http://forum.xda-developers.com/one...launch-app-screen-off-camera-gesture-t3186507
Click to expand...
Click to collapse
Anyone tried it?
@Thomson2412:
First of all - if anybody with Find 7 is to flash this, he will probably have a custom ROM and it does not have to be CM.
Your zip is obviously for CM ROM. I am using OmniROM with Android 7.1 at the moment.
I flashed it and found out it is not working at all. Altought, it does add the options to settings panel.
Setting any option does not do anything and checking Haptic feedback for any action causes crash.
---
When I flashed the Omni version you have in your original thread (after I removed the OnePlus related checks) the settings options were not there at all - it is in Settings - Device Features.
1. Setting app for Camera gesture works.
2. Clicking on setting vibrator strength causes crash.
And I might be wrong, but it seems that flashing that zip messed up my "menu button one-click".
I do not get any menu popups anymore. Even when I put the original version back..
@Thomson2412 hi I find it's nice feature since I have used this kind of feature when I had oppo f1... Now I am using zuk z1 a msm8974/sd801 device... Can you help me to port it for my device.? Thanks in advanced..
tech mashido said:
@Thomson2412 hi I find it's nice feature since I have used this kind of feature when I had oppo f1... Now I am using zuk z1 a msm8974/sd801 device... Can you help me to port it for my device.? Thanks in advanced..
Click to expand...
Click to collapse
Does it have off screen gestures?
Thomson2412 said:
Does it have off screen gestures?
Click to expand...
Click to collapse
No... I am talking about custom roms to have this mod
tech mashido said:
No... I am talking about custom roms to have this mod
Click to expand...
Click to collapse
I can't add gestures to a rom that doesn't have them by default because that would require a kernel change and I'm not capable (yet) to implement "new" gestures. Currently I don't have the time nor interest in learning how to change a kernel. So if your device doesn't have gestures I'm afraid I cant be of any help. I only alter what gestures do not add them or create custom ones.
I hope this answers your question, if not feel free to ask some more
Thomson2412 said:
I can't add gestures to a rom that doesn't have them by default because that would require a kernel change and I'm not capable (yet) to implement "new" gestures. Currently I don't have the time nor interest in learning how to change a kernel. So if your device doesn't have gestures I'm afraid I cant be of any help. I only alter what gestures do not add them or create custom ones.
I hope this answers your question, if not feel free to ask some more
Click to expand...
Click to collapse
If you are talking those off screen gesture features which comes in OPPO phones mostly (like draw C to open camera or draw M to open music app ) then these kind of features "by default" we dont have in any stock or custom rom But
if Double to tap wake screen (D2W) feature is enough to work your mod on my device then yes we do have this thing in all ROMs by default(kernel enabled )....,,
tech mashido said:
If you are talking those off screen gesture features which comes in OPPO phones mostly (like draw C to open camera or draw M to open music app ) then these kind of features "by default" we dont have in any stock or custom rom But
if Double to tap wake screen (D2W) feature is enough to work your mod on my device then yes we do have this thing in all ROMs by default(kernel enabled )....,,
Click to expand...
Click to collapse
Then there is not much i can do I'm afraid
Thomson2412 said:
Then there is not much i can do I'm afraid
Click to expand...
Click to collapse
haha no problem, mate ....thanks :victory:
Turns your phone into a touchpad mouse for PC! Works with LOS14.1 by bigsupersquid
Changelog:
171116:simulated touchpad support. thx pelya
171127:Now with dt2w support. Goodbye broken power button. thx showp1984
Click to expand...
Click to collapse
Download:
Code:
[URL="https://www.androidfilehost.com/?fid=962021903579495061"]AFH[/URL]
Flash:
Code:
[COLOR=Black]fastboot flash boot <boot_img_here>[/COLOR]
For Keyboard app, always download from Play store/Github
Root required, Magisk recommended.
I'm either trying to port DT2W for this device, but no luck. Done.
Anyway you may give me some feedback, source below.
Source: Github
XDA:DevDB Information
HID-compliant TP/KB kernel, Kernel for the HTC Desire 816
Contributors
Aerotinge, bigsupersquid, pelya, showp1984
Kernel Special Features:
HID-compliant driver,Doubletap2wake
Version Information
Status: Beta
Beta Release Date: 2017-11-16
Created 2017-11-16
Last Updated 2017-11-27
Dammit I finally make dt2w running on this himax touchscreen driver.
No one done this before and I know little about C. That's...awwww
Enjoy!
Hi, Thank you for your work, Do you tell me i can use this for HTC816 DWG or no?
faezehya said:
Hi, Thank you for your work, Do you tell me i can use this for HTC816 DWG or no?
Click to expand...
Click to collapse
As "a5_ul" is there in the title, I'll say no.
But you can have a try. It won't explode (I guess so.)
Aerotinge said:
As "a5_ul" is there in the title, I'll say no.
But you can have a try. It won't explode (I guess so.)
Click to expand...
Click to collapse
The dts might be a little different.
Overall it'll probably work.
I hadn't seen this, nice work!
If you don't mind I'd like to import your changes, both the dt2w and the hid configs.
initial feedback, it works on my DUG
going to test it all day tomorrow
Edit: ok nvm it works for some time then touch screen stops working when the phone goes in deep sleep
bigsupersquid said:
The dts might be a little different.
Overall it'll probably work.
I hadn't seen this, nice work!
If you don't mind I'd like to import your changes, both the dt2w and the hid configs.
Click to expand...
Click to collapse
can this be ported fow dwg/dug?
Roberto Nigel said:
can this be ported fow dwg/dug?
Click to expand...
Click to collapse
If I import the kernel patches and it all works right, it'll be fine when it's built in to LOS.
Roberto Nigel said:
initial feedback, it works on my DUG
going to test it all day tomorrow
Edit: ok nvm it works for some time then touch screen stops working when the phone goes in deep sleep
Click to expand...
Click to collapse
Yes I found that issue recently...
I always connect the phone to charger so I didn't found it at the first time.
It seems to be something about deep doze mechanism, which a noobie like me can't solve alone, sorry.
I would port a fix if someone found a solution on other devices.
Aerotinge said:
Yes I found that issue recently...
I always connect the phone to charger so I didn't found it at the first time.
It seems to be something about deep doze mechanism, which a noobie like me can't solve alone, sorry.
I would port a fix if someone found a solution on other devices.
Click to expand...
Click to collapse
I'll look into it, dt2w is pretty cool and I'd like to incorporate it
No guarantee of fixing anything of course.
bigsupersquid said:
If I import the kernel patches and it all works right, it'll be fine when it's built in to LOS.
Click to expand...
Click to collapse
welp if that helps, after removing android system from battery optimization the touch screen doesnt die but dt2w is not consistant, some times it stops and have to open from the power button for it to work again
Roberto Nigel said:
welp if that helps, after removing android system from battery optimization the touch screen doesnt die but dt2w is not consistant, some times it stops and have to open from the power button for it to work again
Click to expand...
Click to collapse
Excellent observation and a perfect place to post it.
Kudos!
Can we get n overclock kernel...
Hey bro PLEASE make it work for a5 dug/DWG...I f**king love d2tw feature
In exchange can I do something for you ?donations ? Any help? I will do anything XD just please make it work on a5 dug/dwg models
Since there is no way in a GSI (without recompiling stuff) to add proper support for the screen slider, I'm going to see if I can write a shell script to run on update of the value for the sensor that detects the position of the display, however,I don't actually know what sensor this is.
After a bit of testing, I believe there's a magnetic field sensor that detects the change in the field as the screen moves (since moving a magnet over the device can activate the slider detection ) however I am unsure about this.
ambitiousButRubbish said:
Since there is no way in a GSI (without recompiling stuff) to add proper support for the screen slider, I'm going to see if I can write a shell script to run on update of the value for the sensor that detects the position of the display, however,I don't actually know what sensor this is.
After a bit of testing, I believe there's a magnetic field sensor that detects the change in the field as the screen moves (since moving a magnet over the device can activate the slider detection ) however I am unsure about this.
Click to expand...
Click to collapse
I'm not sure how useful it will be to identify the hardware. Somewhere, there must be a driver, and there must also be some way, in the stock rom/kernel, to register an action associated with that driver.
It's a magnetic sensor
and I know this because when i slide it into my magnet dash holder, it activates the slide.
then I tried just sliding a magnet across the back, and yes it activates the slider lol
invisiblewave said:
I'm not sure how useful it will be to identify the hardware. Somewhere, there must be a driver, and there must also be some way, in the stock rom/kernel, to register an action associated with that driver.
Click to expand...
Click to collapse
if i can identify the sensor, i can try to find the file associated with its value in the 'sys' partition, and read this to detect changes, when it changes, this can be used to assign an event etc...
in the same way that i did my flashlight fix for huawei phones with GSIs, this would just be a bash script running accessing the specific files associated with the hardware, as remember android is linux (is unix), so everything is a file, this includes the state of the sensor, so it can be read
ambitiousButRubbish said:
if i can identify the sensor, i can try to find the file associated with its value in the 'sys' partition, and read this to detect changes, when it changes, this can be used to assign an event etc...
in the same way that i did my flashlight fix for huawei phones with GSIs, this would just be a bash script running accessing the specific files associated with the hardware, as remember android is linux (is unix), so everything is a file, this includes the state of the sensor, so it can be read
Click to expand...
Click to collapse
i understand. I'm not an Android developer, but i work in a similar industry
There is also the possibility that the magnetic switch actually pushes some sort of "button" inside the phone, it could even be some sort of magnetic film where a magnet pushes two membranes together to complete a physical circuit like a button.
would "show input touches" or some sort of log viewer be able to see what that input is?
i killed tupac said:
i understand. I'm not an Android developer, but i work in a similar industry
There is also the possibility that the magnetic switch actually pushes some sort of "button" inside the phone, it could even be some sort of magnetic film where a magnet pushes two membranes together to complete a physical circuit like a button.
would "show input touches" or some sort of log viewer be able to see what that input is?
Click to expand...
Click to collapse
judging by the teardown, there's no physical switch.
ive tried aida64, but it doent list all sensors, there is however a hall sensor that does not display a value, that looks somewhat promising, i will investigate this more.
the input is over gpio or similar so show input touches wouldn't work, however, a logcat output might
It's in kernel:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/perseus-p-oss/drivers/halls/halls.c
AndroPlus said:
It's in kernel:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/perseus-p-oss/drivers/halls/halls.c
Click to expand...
Click to collapse
Thanks! As I suspected. All we need now is a kernel programmer who can merge it into the AOSP kernel for the MM3!
I'll still see if I can 'hack' a temporary solution, I'm not a kernel dev (and know very little C) so will try my bash script solution.
Anyways, flashing a GSI doesn't alter the kernel, it's down to the system to communicate with kernel modules, if the system doesn't implement the features, even if it's in the kernel, it won't work.
ambitiousButRubbish said:
I'll still see if I can 'hack' a temporary solution, I'm not a kernel dev (and know very little C) so will try my bash script solution
Click to expand...
Click to collapse
But without the driver in the kernel, there'll be no external notification.
invisiblewave said:
But without the driver in the kernel, there'll be no external notification.
Click to expand...
Click to collapse
True for a custom kernel, but not if you flashed the GSI onto a stock kernel since the driver already exists, it's down to Android to communicate with the kernel, if the communication methods don't exist in the Android system then it doesn't work, conveniently it may however be possible to read the value of the hall sensor through a bash script, and subsequently an app. In the same way that you can turn on an off the flashlight by changing the values in /sys/class/LEDs, regardless of what system (stock kernel though) you are running, will work the same for the hall sensor.
I just need to find what file the system uses as it's interface with the kernel driver, looks like it's over GPIO, which means finding it will be 'fun'
ambitiousButRubbish said:
I just need to find what file the system uses as it's interface with the kernel driver, looks like it's over GPIO, which means finding it will be 'fun'
Click to expand...
Click to collapse
Would the event not be logged in dmesg or kern?
invisiblewave said:
Would the event not be logged in dmesg or kern?
Click to expand...
Click to collapse
i can view events written to logcat, but its simply a log stating the sensor was polled when the screen slides, not what io is being checked, though, looking at the kernel source, gpio 49 and 113 are used, which i cant find in /sys/class/gpio, there is a 'halls' folder under /sys/devices/virtual/misc, which corresponds to the sensor, but it doesn't contain anything of any use, apart from the uevent details, which i cant do nything with anyway
ambitiousButRubbish said:
i can view events written to logcat, but its simply a log stating the sensor was polled when the screen slides, not what io is being checked, though, looking at the kernel source, gpio 49 and 113 are used, which i cant find in /sys/class/gpio, there is a 'halls' folder under /sys/devices/virtual/misc, which corresponds to the sensor, but it doesn't contain anything of any use, apart from the uevent details, which i cant do nything with anyway
Click to expand...
Click to collapse
That's one step further, at least you know the kernel knows about the sensor. I checked dmesg on mine (non-GSI) and I don't see any sign of it. The "everything is a file" mantra is great, but I spend half my life trying to find files in Linux when I have a problem...... I wish IBM would take it and rework it all to make it logical and useable, or better yet, make the IBM i run Linux apps.
invisiblewave said:
That's one step further, at least you know the kernel knows about the sensor. I checked dmesg on mine (non-GSI) and I don't see any sign of it. The "everything is a file" mantra is great, but I spend half my life trying to find files in Linux when I have a problem...... I wish IBM would take it and rework it all to make it logical and useable, or better yet, make the IBM i run Linux apps.
Click to expand...
Click to collapse
im on stock checking all of this, but since im looking in /sys, flashing a GSI or any other system image doesn't affect that, so i know, if i can make it work on stock, chances are, it will work on non stock too, however, should your system flash overwrite /sys, then you may have an issue.
ambitiousButRubbish said:
im on stock checking all of this, but since im looking in /sys, flashing a GSI or any other system image doesn't affect that, so i know, if i can make it work on stock, chances are, it will work on non stock too, however, should your system flash overwrite /sys, then you may have an issue.
Click to expand...
Click to collapse
Yes. Hence my previous comment about merging the driver into the AOSP kernel. It'll be a cold day in hell before I go back to MIUI.
invisiblewave said:
Yes. Hence my previous comment about merging the driver into the AOSP kernel. It'll be a cold day in hell before I go back to MIUI.
Click to expand...
Click to collapse
i understand your point now, theres quite a bit more than just the slider implementation you need though for the device to function correctly with an AOSP kernel. To be fair to MIUI, having come from an honor 9, i only suffered EMUI for a month before i got rid of it, becasue it was so unbearable, MIUI, i dont really mind that much, its actually designed well, and is pretty nice to look at, obviously i still prefer stock android, hence the idea of this, because i could just flash a GSI and still have a somewhat semi functional slider.
ambitiousButRubbish said:
i understand your point now, theres quite a bit more than just the slider implementation you need though for the device to function correctly with an AOSP kernel. To be fair to MIUI, having come from an honor 9, i only suffered EMUI for a month before i got rid of it, becasue it was so unbearable, MIUI, i dont really mind that much, its actually designed well, and is pretty nice to look at, obviously i still prefer stock android, hence the idea of this, because i could just flash a GSI and still have a somewhat semi functional slider.
Click to expand...
Click to collapse
Yes, I know, but the work has already been done on the AOSP kernel, since we have a bunch of non-GSI roms now running (I'm assuming they don't use the OEM kernel, otherwise the driver would be present and the interrupt would work). With the driver merged into the whatever kernel the non-GSI roms are running, we'd then be at the same point with the non-GSI roms as we are with the GSI, at least as far as detecting the slider action goes. Then your app/script would work on either.
invisiblewave said:
Yes, I know, but the work has already been done on the AOSP kernel, since we have a bunch of non-GSI roms now running (I'm assuming they don't use the OEM kernel, otherwise the driver would be present and the interrupt would work). With the driver merged into the whatever kernel the non-GSI roms are running, we'd then be at the same point with the non-GSI roms as we are with the GSI, at least as far as detecting the slider action goes. Then your app/script would work on either.
Click to expand...
Click to collapse
as i said earlier, the GSI (im talking about where you just flash the SYSTEM image, nothing else) ROMs wont detect the event since its handled by the MIUI framework, so whilst the event does take place, the only way of knowing it takes place is having something poll the data the kernel outputs for the event, which would either mean a third party program, or somehow getting the MIUI framework working on AOSP, but you then have the issue of it being MIUI, which you want to get rid of. maybe its worth me looking a the code for the slider implementation in the MIUI framework, if its open source.
ambitiousButRubbish said:
as i said earlier, the GSI (im talking about where you just flash the SYSTEM image, nothing else) ROMs wont detect the event since its handled by the MIUI framework, so whilst the event does take place, the only way of knowing it takes place is having something poll the data the kernel outputs for the event, which would either mean a third party program, or somehow getting the MIUI framework working on AOSP, but you then have the issue of it being MIUI, which you want to get rid of. maybe its worth me looking a the code for the slider implementation in the MIUI framework, if its open source.
Click to expand...
Click to collapse
You've already proved that it's not the ROM detecting the event, it's the kernel. GSI - Xiaomi kernel, slider event detected, no framework in ROM to handle the event. Non-GSI - AOSP kernel, slider event not detected, no framework in ROM to handle the event. If the driver is merged into the AOSP kernel, then GSI & non-GSI roms are in the same boat, needing either an app or your script to handle the event.