Surprising to see this taking so long to evolve. One would think that Qualcomm would benefit from dedicating a few heads to proper Linux support of the Snapdragon, or offer bounties for community development of features. Asahi is doing much better with Apple hardware even though it is comparatively much more exotic and closed up than PC architecture. I wonder how much Microsoft / Windows 11 ties are interfering (on purpose or accidentally) with the progress of native ARM PC Linux.
If you take a moment to research you'll see that Qualcomm absolutely does not give two craps about software support for their SoC/SoMs. Like, none. They throw out a binary turd and that's that. Androids history of (lacking) updates is littered with them refusing to do anything but release a binary blob that works on a few kernels.
There's no need to make up some wild conspiracy theories with Windows here, spend a single Google search before going into this direction next time.
Qualcomm employee here - I agree that we have fallen short of expectations but I don't think it's fair to say "none". I know several folks whose job is kernel development and upstreaming is part of that. It would be great if we could shift from a focus on Android to a focus on Linux instead, though.
I have seen significant changes in the policies established only just weeks ago that should enable Qualcomm to better participate in developer communities. There's a clear message from the CEO and several VPs that these changes are necessary.
> I have seen significant changes in the policies established only just weeks ago that should enable Qualcomm to better participate in developer communities. There's a clear message from the CEO and several VPs that these changes are necessary.
Forgive me the snark, but I'll believe it when I see it. The last years didn't inspire me with confidence.
The problem is, at the core, that this sort of behavior used to be the norm in the industry. Working with embedded systems is pure and utter hell. The open documentation and standardized interfaces one got with Intel/AMD is the complete exception.
> Forgive me the snark, but I'll believe it when I see it. The last years didn't inspire me with confidence.
Indeed, it will be hard to change the minds of all the folks at Qualcomm who have operated here for years under the status quo. I see new leverage for those who have lobbied for change in the past.
AFAIK Android updates are not as fast as they could be due to need for mobile operators to re-certify every update as the OS blob contains modem firmware. Apple is able to update iOS faster because modem firmware is separate from the rest of iOS. Hence having open source drivers in the kernel will not improve the situation much.
Or maybe, I'm just creating opportunities so you can come and shit on Qualcomm like they deserve. I think it's funnier than if we're both taking that dump at the same time.
> Surprising to see this taking so long to evolve.
Qualcomm's competition isn't Apple. It's Intel and AMD. Intel and AMD offer chips that run Windows much better than whatever Qualcomm can make. Apple managed to do that because they control the whole stack - they made macOS run well on ARM, something Microsoft has little incentive to do because chicken and egg.
For Windows, binary compatibility with 3rd party apps is extremely important, at least for the apps that aren't browsers running JavaScript, so, what Qualcomm could aim to do is to optimize the heck of their ARM offerings for x86 emulation/JITing, and efficient JavaScript execution, more or less what Apple did.
> For Windows, binary compatibility with 3rd party apps is extremely important, at least for the apps that aren't browsers running JavaScript, so, what Qualcomm could aim to do is to optimize the heck of their ARM offerings for x86 emulation/JITing, and efficient JavaScript execution, more or less what Apple did.
TL;DR emulated x86-32 performance on ARM is poor, and is going to stay poor because of the memory model. Whether this strategy is going to be successful largely depends on how important/prevalent legacy 32bit apps are.
