I really want to turn this phone into my daily driver, so i started working on one of the features i would want in a daily driver, working GPS.
This is the current component support table of postmarketos:
i think audio is too complex for me, so i decided to tackle GPS, as you can see its currently listed as broken, but not anymore!
It really helped i have another FP6 running android, i could directly inspect how it was talking to the modem to get it working.
So i started pulling threads and here we are. I want to upstream this and i’m making an account so i can submit patches for modemmanager and libqmi, but i have never upstreamed something before, so advice is appreciated!
If you have a linux phone and want to use it as a daily driver, see if you can contribute it! this is how we build up the linux ecosystem.
You must log in or register to comment.
I wish I had knowledge in coding and programming. I find it fascinating how someone could grab code from something and add whatever they want for the greater good. No matter how hard I try, it doesn’t click. All my brain power goes towards musical knowledge.
Well it’s funny you say that cause i tried music once and found it very hard.
I’m making a game with a few friends and i’m really in awe of what the artists do, maybe it’s just human to be in awe of things you struggle with and downplay things you are good at.
I want to post a low tech guide soon on how to do Linux mobile development, so maybe you find that useful.
Fixing audio would be really beneficial(im not saying you should do it tho, i can understand that its a big task) because it would fix calls not working(duh) and the fp5 also uses the same chip so it would be like 4 birds with one stone.
Yeah i really would want that too, but i’m also like if experienced developers couldn’t do it in all this time how can i do it? Maybe i am underestimating myself here so maybe later i’ll look into it. Sticking with the easy stuff for now.
Tbf you did just implement the gps so id say you sre underestimating yourself but of course take everything at your own pace. I shouldnt be the one talking cause all i can do is some really bad c code and some semi-decent bash scripting but yeah.
Nobody’s born cool, but you, you got cool somewhere along the way
Amazing work!
Absolutely incredible :)
Awesome contribution!
Can you link the patch here?
This is VERY exciting. One day I’ll be able to grab any unlocked handset and add my favorite Linux mobile OS in a flash
Thank you for your service! 🫡
How does postmarketOS handle for you on your Fairphone? I’ve got a Fairphone 4 running e/OS and have been debating the best options for when I finally need a new phone.
It runs pretty well for me, the things listed on the wiki as works do in fact work.
When swithichg tabs you get a flickering glitch, so please don’t get it if you are photosensitive.
I wrote an full review here: https://ani.social/post/33469765
TYVM! I unfortunately actually am photosensitive, so that’s a dealbreaker sort of out the gate. I’ll have to wait for that to be patched. I appreciate the info, though!
The flicker might not be there with other DEs so it might be fine with another one but i can’t confirm it, all i can say is that for plasma mobile the flicker is present.
huzzah!
(☝︎ ՞ਊ ՞)☝︎
Good job matey. Thank you for your service.
I have no experience with mobile audio, but on the desktop it can be surprisingly simple (often just a matter of an ALSA quirk or two), so don’t discount it without looking into it.
Yeah, it’s likely just a buffer needs to be filled with amplitude samples, and sample frequency plus bit depth needs to be programmed (and volume). Then from there it’s just a matter of adding codecs to decode/decompress various audio formats from media (which would be the same code as on desktops, though complied for ARM or whatever instruction set the phone’s CPU uses).
Oh also, there’ll be determining the method it handles multiple channels (separate buffers or some sort of interleaving in a single buffer?).
And then adding virtual buffers can help with output device management, as each output might use a different buffer, so having apps writing their audio to a virtual buffer means your code can manage things like the user switching from phone speaker to aux cable or bluetooth (which is a whole other beast and involves encoding the audio to specific codecs to make up for the relatively low bandwidth available).
Though whatever is already there could add complexity, but my guess is it’s just a matter of matching memory mapped addresses up and then the existing linux audio code will handle the rest.
Hell yeah!
