The drivers might be up on LKML, but they're not mainlined yet. And this is just gen5. It would be great if you could fix your gen4 and 4.5 drivers, so that people building products with your chips weren't stuck on an orphaned vendor kernel that doesn't even upstream to your public fork.

Also your boot-chain is still closed and proprietary, and completely different than the one used by all other ARM vendors. Being the special snowflake is not helping your business or your customers.

And don't even get me started on Gunyah and GearVM, or on the proprietary, locked nature of your BSP, or how far behind TI and NXP you are on software quality and ease of use. Maybe also consider releasing some actual documentation on your chips.

I know multiple developers who have sworn off Qualcomm and will never design with your chips again at any price point. Your closed-off support model is 100% the culprit, and it hurts your core business. Any software support revenue that you managage to extract comes at the cost of goodwill and future chip sales.

Your chips are good - best in the industry. If you can up your software game to match, you'll really meet your potential.

Yet 2 days ago, Tuxedo Computers announced they were abandoning Qualcomm due to crap support. (https://www.theregister.com/2025/11/26/tuxedo_axes_arm_lapto...).

  In particular, the long battery runtimes – usually one of the strong arguments for ARM devices – were not achieved under Linux. 
  A viable approach for BIOS updates under Linux is also missing at this stage, as is fan control.
  Virtualization with KVM is not foreseeable on our model, nor are the high USB4 transfer rates.
  Video hardware decoding is technically possible, but most applications lack the necessary support.

- Their Snapdragon X laptop didn't do very well, and they likely realize an ARM Windows laptop will always be a second class citizen: https://www.techpowerup.com/329255/snapdragon-x-failed-qualc... .

- Likewise, Mobile SoCs are completely dependent on Android without proper upstreaming (which they haven't done in the past).

- They are seeing Valve spending time and money on FOSS support paying off, especially with their new hardware releases.

On the other hand, proper upstreaming of the chips give them much more flexibility for different linux-based OSes.

While it would be great for Qualcomm to "do the right thing" in supporting FOSS, I feel much more confident in that support being sustained long-term when it aligns with some profit motive.

IMO the best case is that Qualcomm sees dollar signs when they imagine their Oryon CPUs and Adreno GPUs dominating the consumer linux landscape. There is definitely room to shake up x86 (especially when it comes to perf/W and idle battery drain), and only a finite window for ARM to do so with RISC-V on the horizon.

And to whatever extent Qualcomm et al now view Linux as a relevant personal computing platform, I think a massive amount of credit goes to Valve. I seriously doubt Linux support even enters the conversation at these companies without the Steam Deck's success.

This changes the game. I’d rather use native Linux than Asahi (though the latter is amazing).

That would be great. As far as I know, there currently are no options for lightweight tablets that support Linux.

Not sure how well WSL2 on tablets work. Does anybody here have experiences with WSL2 on tablets like the new Microsoft Surface Pro that uses the Snapdragon X Elite chip?

> Hardware-accelerated video recording into H.264 (AVC) and H.265 (HEVC) formats

no mention of AV1? Surprised since most websites including YT uses it heavily.

also, not to beat a horse that is by now six feet under, but

> No delays, no hurry-up-and-wait, no registration. Just go get the new features.

i'm so tired

Are they already using Turnip / Mesa as their Vulkan implementation or not yet? If not, they should. Valve are using Turnip on their Steam Frame.

That would be another step of working with upstream, besides the kernel driver.

https://www.qualcomm.com/developer/software/qualcomm-linux

Why is any of this needed when the kernel is full of platforms that are forward compatible with the Linux kernel and boot and generally operate on day one, without a huge pile of changes?

What does it benefit the user to have a huge pile of proprietary implementations of devices they frankly don't care about? Ex: just about anything related to power management? Why can't QC adhere to industry standards when they implement standard devices, ex: USB? Why can't these platforms adhere to industry standard firmware interfaces rather than custom mailbox interfaces?

I'm pretty keen to play around with Proton, FEX in a laptop that rivals the MBP

So how about you give me a fucking break, Qualcomm? Call back when Snapdragon has first class support in major distros and you are serious about Linux.

They aren't targeting enthusiasts with this announcement.

let's stop being naive - qcom will not change.