As people may have noticed from my lack of posts, this is sadly quite the hard problem compared to my previous bringups.
I do say that giving up is not part of my dictionary but im genuinly running out of ideas here.
If people have been following along with the LKML this is very relevant:
From Codec pov, its exactly same IP, I have now SDCA drivers working for
both playback and capture, so Am hoping that we could use the same SDCA
driver for both of these modes. I still have to give it a try on a
mobile platform to verify this.
Am hoping to send a version of this driver sometime this week.
–srini
This is a response of Srinivas on my mic patch, if their SDCA complaint driver does work on the FP6, then my driver gets superseded, and maybe i can make my calls work on their SDCA driver, we’ll see.
Honestly it is crazy that some parts like Audioreach calls and NFC-CE are just completely uncharted territory on linux if and i repeat if i get this working i would genuinely be the first.
Getting the DIAG channel open was quite a bit of work, and then it was finally open and i hoped for a breaktrough like with GPS and then its all obsfucated…
Breaking news: after days of smashing my head into a vocoder shaped wall im now going to try to do it fully in userspace instead of the qualcomm kernel path.
I got quite close with this, but no matter what i did it wasn’t coming online.
The issue with this hardware is that it’s not going trough the linux audio system really, its IMO quite janky with graphs going straight to the amps.
My new approach should make the modem just a regular pipewire source/sink, we shall see in the coming days if this new approach works.
It’s not entirely unprecedented, OpenIMSs is doing something similar.
having it as a regular linux audio device is also so much better, that way it’s nice and integrated and there is no separate route that gives trouble.
this should also address erebion’s question for bluetooth calls, as we can then just use the regular bluetooth audio which already works
If I get this working the best way to support would be to test it with different carriers. I can only test it with my own. And that doesn’t guarantee it will work for everyone.
As people may have noticed from my lack of posts, this is sadly quite the hard problem compared to my previous bringups.
I do say that giving up is not part of my dictionary but im genuinly running out of ideas here.
If people have been following along with the LKML this is very relevant:
This is a response of Srinivas on my mic patch, if their SDCA complaint driver does work on the FP6, then my driver gets superseded, and maybe i can make my calls work on their SDCA driver, we’ll see.
Honestly it is crazy that some parts like Audioreach calls and NFC-CE are just completely uncharted territory on linux if and i repeat if i get this working i would genuinely be the first.
I’m also keeping my eyes peeled for this one https://lore.kernel.org/all/20260713121816.2728888-1-ravi.hothi@oss.qualcomm.com, its an FP6 adjacent board and they can actually read the hashed DIAG messages from the modem and get the plaintext (qualcomm really making it hard for me)
Getting the DIAG channel open was quite a bit of work, and then it was finally open and i hoped for a breaktrough like with GPS and then its all obsfucated…
Breaking news: after days of smashing my head into a vocoder shaped wall im now going to try to do it fully in userspace instead of the qualcomm kernel path.
I got quite close with this, but no matter what i did it wasn’t coming online.
The issue with this hardware is that it’s not going trough the linux audio system really, its IMO quite janky with graphs going straight to the amps.
My new approach should make the modem just a regular pipewire source/sink, we shall see in the coming days if this new approach works.
It’s not entirely unprecedented, OpenIMSs is doing something similar.
having it as a regular linux audio device is also so much better, that way it’s nice and integrated and there is no separate route that gives trouble.
this should also address erebion’s question for bluetooth calls, as we can then just use the regular bluetooth audio which already works
Is there any way to support you outside of attempting this in parallel for ideas/breakthroughs?
If I get this working the best way to support would be to test it with different carriers. I can only test it with my own. And that doesn’t guarantee it will work for everyone.