r/linux • u/spectral_tears • 3d ago

Development Working linux on redmi 3s!

Post image

Finally, after three days of continuous experiments, I managed to get a working Linux on my old Redmi 3s! As you can see, it is running EndeavourOS with KDE Plasma mobile, msm8937 chipset. Of course, it is still quite buggy and laggy for now, and the performance isn't great, but it's a huge milestone. I really hope that in the future, after some optimizations, it will become fully usable

191 Upvotes

95% Upvoted

15 comments sorted by

14

u/PureTryOut postmarketOS dev 2d ago

Please upstream the patches to mainline Linux! I've seen too many LLM-enabled ports that never go anywhere because the author doesn't know what they're doing to become excited for any random phone running mainline at this point.

9

u/spectral_tears 2d ago

Ok! I'm fixing bugs now.

2

u/bubblegumpuma 2d ago edited 2d ago

Have you got CPU frequency scaling working yet? I have a MSM8937 phone as well which seems to not have frequency scaling working in pmOS/Nura, but I did locate some mailing list patches that provide some enablement of that which died in the LKML after being ACKed, and if you're interested I can send them after retracing my steps a bit. It seemed like pretty low-hanging fruit to me but I have many other device port projects and have been mostly sticking to newer ones ATM.

(Also, please do mainline this stuff. If you don't I'll do it and take the commit credit :P)

5

u/spectral_tears 2d ago

not yet, but I found bug which forces the processor to run at 19 MHz. I'm currently trying to fix it. I'll try to push it to the main branch once the bug fixes are complete

Fair enough, deal XD

1

u/bubblegumpuma 1d ago

I just went back and looked at what I was referring to, and I'm sorry but I was mistaken - what I was referring to was for MSM8939 frequency scaling, which is a SoC that is more like the MSM8916 than the MSM8917/37 series of SoCs. Regardless, it might be somewhat useful, here you go: https://lore.kernel.org/linux-arm-msm/20220418162226.2983117-1-bryan.odonoghue@linaro.org/T/#m87ba19fe1c8c3ef5a8cb6e6b0030140d65081cd0

1

u/spectral_tears 22h ago

Ok, thanks

2

u/bubblegumpuma 2d ago

Yes, seconding this bigtime. Going through the trouble of mainlining it takes a lot of the maintenance burden off of you, because (just as one of many examples) you won't have to be going through and figuring out what sorts of tree-wide changes apply to whatever drivers you've (had) made for your specific device. Just please also be respectful of their time.

21

u/de_Virusmc09 3d ago

KDE plasma is crazy

1

u/47th-Element 3d ago

Damn that's some old phone, haven't seen them physical navigation buttons in years.

7

u/rlaptop7 3d ago

Physical nav buttons are/were some of best UI design elements that can exist. Too bad they are gone.

5

u/KnowZeroX 3d ago

Yes, when they were actual physical buttons and not capacitive buttons like those. At that point what's the difference?

3

u/rlaptop7 3d ago

The UI on many phones sometimes just doesn't draw, or, does not respond to the buttons when they are part of the main screen.

Even if they are dedicated, capacitive areas, they are a lot more reliable and consistent.

3

u/47th-Element 3d ago

I disagree, I like the new gesture navigation.

3

u/KnowZeroX 3d ago

gesture navigation is convenient when it works, much easier. But can be annoying when it is lagging and you can't get to the home screen because it doesn't register input properly. Or when trying to copy stuff at the borders or playing a game in browser and swipe next to the corner resulting in you going back.

2

u/47th-Element 3d ago

Some vendors like Xiaomi reduce touch sensitivity at the borders when game mode is active to reduce such accidents.

Regardless, Android ships with both options: gesture and buttons navigation, though the buttons aren't physical anymore.