Comment by zb3

17 hours ago

Why only for these "desktop" socs? Why couldn't Qualcomm partner with Debian/Ubuntu to bring support to their mobile chipsets? Why can't Qualcomm partner with PostmarketOS to help recycle old devices and avoid e-waste?

Well, in case anyone else is wondering, I have the answer. That's because Google is maintaining a cartel, the "GMS" cartel in short. Due to intense lobbying and incredibly weak antitrust enforcement, this cartel still continues to operate globally, keeping soc makers like Qualcomm, Mediatek and Unisoc in chokehold. We won't see any real competition in the smartphone space unless it's destroyed, but market forces alone can't do that.

Tell us more about how it's Google who is preventing Qualcomm and Mediatek from upstreaming all their drivers?

  • Google controls the Android ecosystem (restricts what OEMs can do) and employs various practices to ensure there's no alternative besides Apple (this duopoly suits both of them). Chipmakers essentially focus on ensuring they can sell access to BSPs which meet Google requirements, as there's no real alternative for smartphones. If you're not Apple, these chips are meant to be used with GMS Android, that's the expectation.

    If there were alternatives (like on the desktop and for some parts of IoT) it would be more cost-efficient to upstream everything, but with the current situation it's fully up to Google.

    When Google wanted them to move all their chip-specific code to modules (GKI), they had to do that. And if someone at Google randomly decided "hey, now you'll upstream this stuff", then guess what? They'd have to follow, it's how this monopoly works.

    • I think the GKI initiative is great, personally. I've worked with chip companies that are super-resistant to upstreaming their code, and just give me a fork-of-a-fork of the kernel and kind of say "welp, good luck maintaining that unless you pay us".

      I don't love how much control Google is exerting over Android, and I don't love having to use their signed kernel. But I do prefer that vs. being stuck on an abandoned vendor kernel. If I have to accept low-quality proprietary kernel code, I'd rather keep it in small module-shaped boxes.

      Companies like Qualcomm complain about this, but their historical practices are what drove Google to mandate it in the first place.