Request: Enable MiUS Proximity sensor driver

[chemusqui1]

Hello, i was looking at your work, incredible tinkering you made before anything... I saw CONFIG_US_PROXIMITY isn't enabled on tucana defconfig, and that's needed for having ultrasonic proximity sensor on fully working state (elliptic only isn't enough). Thanks in advance, Chema

[b100dian]

Thanks @chemusqui1 for your message.

I've added in the Readme the link to the kernel, https://github.com/b100dian/Xiaomi_Kernel_OpenSource/tree/tucana-hybris-17.1

The work building this kernel started before a lineage OSS one was available on XDA. I did notice that that one uses MIUS and mine (forked from Xiaomi) uses ELUS, but that is NOT why the proximity doesn't work on Sailfish unfortunately.. (The configs for ELUS are added in this Kbuild file fixed to work with lineage_tucana product)

The problem with the proximity sensor is that it requires "audioserver" and "vendor.audio-hal-2-0" android services to work (that's why it's a "virtual" proximity sensor, as they call it today). Before this commit https://github.com/sailfishos-on-tucana/droid-config-tucana/commit/4c1bc837a1744bd2678a8ab18b816bce498a48f0 the proximity hardware WAS working, but there were two side effects:

• there were two audio services enabled in call => terrible echo for the other person. The Sailfish one is a plugin for pulseaudio which also binds to the android HAL called https://github.com/mer-hybris/pulseaudio-modules-droid-jb2q
• there were races between systemd starting pulseaudio and android init starting audioserver and vendor.audio-hal-2-0. You can see the commit drops a tentative to 'serialize' these in the proper order. To add insult to the injury, if vendor.audio-hal-2-0 is started and audioserver does not start within 60 seconds you get a kernel OOPS. So basically it is an initialization race with a deadline.. so in some boots there is no sound in calls. (See the frustration in #9)

My understanding is that I need to invest some time to make out how the pulseaudio droid plugin works and make the ultrasound devices work from it (rather than starting the android services).

Or conversely, make the android services manage only the ultrasound devices and not the voicecall, and keep running them.

Or maybe there is something trickier I need to understand ;) That's why I appreciate your comment, thanks!

[chemusqui1]

Hi... Well, so this is more or less the thing i have on vili (vili uses ELUS proximity too)... And yeah, requires audioserver and vendor hals for working properly, that sensor has even it's own audio paths, as you can see here on a example: https://github.com/chemusqui1/android_device_xiaomi_vili/blob/5261c6354867b7053baefbcc84fb8792940a7a4e/audio/mixer_paths.xml#L2830 I'm putting vili cause it's now the phone i'm working on and has something similar... Also, kernel entries have that ELUS special paths added on techpack/audio...

More or less, the sensor works as this (i have a sensor-multihal HIDL on LOS for it).

• Sensor is enabled when this requirements are met: 1) Phone is on call, or any social media app that has proximity sensor calling 2) The gesture for enabling it is triggered, briefly, with a raise up to ear gesture, you can notice it doesn't work when put on flat surface, like a table.

Then, sensor polls data (in this case, elus has it's XML config on /vendor/etc), validates and triggers audio service if correct for enabling ELUS, then the paths for turning it on, and finally listening from sensor (using ultrasound rx and tx paths)...

So, maybe i think the best approach is to make android services manage only ultrasound device, and letting pulseaudio do the rest, knowing how Xiaomi likes to derp stuff here and make it a puzzle.

It's a bit tricky, yeah... I also appreciate how different things are around there. Hopefully that explain on how does US sensor work here would give you a clue. Thanks for your time btw!! :)