My impression from the emulation folks is that the proprietary drivers are chock full of problems. I suspect it was open source drivers or nothing (i.e., back to an AMD x86 solution like the Steam Deck).

(And I don't think Qualcomm has seen the light - my understanding is that the Turnip drivers are purely reverse engineered.)

Qualcomm has several full time employees working on Mesa (Freedreno/Turnip). They probably must have access to some documentation now..

They've been working on better mainline Linux support for a while now, but their last generation is still catching up on the driver side of things.

I hope they succeed but the last generation has only recently become mostly usable for specific distros. General support may take a while.

I just checked: Frame is Gen 3 and the article is Gen 5.

I am really hoping Valve will release a Frame Pro with Elite Gen 5 later :(

Maybe eventually, but Valve don't tend to update their hardware very often so it'll probably be a while. They went over 6 years between their last VR headsets, and the Deck is over 3 years old now with no hint of a successor coming (the OLED version is more recent but that was a minor iteration with mostly the same specs).

I care a lot more about the screen resolution than the chip. The Steam Frame would make a really cool Linux workstation if the pixels per degree on the display matched typical monitors. Unfortunately, the resolution would have to be much higher than it is.

The frame uses X Elite, their SoC designed or Laptops. These drivers are for mobile Line. Yeah the naming can be quite confusing.

the frame is using a standard mobile snapdragon 8 gen 3 with ARM designed cortex cores.

The 8 Gen 3 also still uses the previous tile-based A7x GPU architecture, while newer chips use the "A8x family of GPUs based on the new Slice architecture".

It wouldn't surprise me if they're full of binary blobs

They are, but that's hardly unique to Qualcomm. Tons of hardware with "proper" upstream Linux drivers still requires closed-source firmware blobs, and in particular with anything wireless that's probably an unwinnable battle due to regulatory constraints.

Closed source firmware is one thing that actually runs outside the Linux system... but there's also the user space libraries that are needed to interact with the drivers (eg libgl etc... or the vendor partition in most Android phones)

I don't think anyone expects non specialized os images to run on this hardware. That would require a standardized userspace abstraction layer like the one Android has been building out. The kernel is just a tiny piece of what's necessary because drivers have effectively moved into userspace. Graphics is the only area that has embraced this properly in "desktop Linux"

>That would require a standardized userspace abstraction layer like the one Android has been building out Can you expound on this? And can desktop linux take advantage of it or do something similar?

The android hal situation is tied to binder and a lot of androidisms. It would be a pretty big shift in culture to adopt that stuff into desktop linux. ChromeOS is likely rebasing on top of android in part to take advantage of the bsp layer abstractions android provides. A proper organization needs to be formed to take on this challenge and I'm not sure any of the existing players are well equipped to lead the charge. Valve and other os distributors who want to ship arm products should be sufficiently motivated though. Most just end up choosing to build on top of Android though because it's easier.

The stability layer also doesn't actually let you seemlessly update the kernel. Those userspace binaries are coupled to specific kernel releases, and it requires work on the vendors part to facilitate new kernel version upgrades. Maybe being upstream will force them to actually take backwards comparability with older userspace binaries more seriously though.

They had to hire Igalia to have decent GPU drivers.