Back

@vwbusguy They don't run linux very well though do they?

@jorge @vwbusguy I mean, I don’t own the hardware, so I can’t speak to it firsthand, but I know one of the Fedora KDE maintainers has one, and his Linux experience with it has been subpar, at best.

@sfalken @jorge That's some useful feedback. I keep debating getting one but always end up getting cold feet. Apple really found the right niche with Silicon and it's wild to me that Linux (and Fedora!) were first the aarch64 support but doesn't have really any midrange hardware options besides Asahi + Silicon and I was hopeful Snapdragon X could be that.

@sfalken @jorge Meanwhile, I have a stack of Mac Minis on my desk that are absolutely incredible workhorses for doing aarch64 builds/tests on Jenkins running on Fedora Asahi. They sit alongside some AlmaLinux 9 raspberry pis, but the Asahi stuff is just incomparably better. The m1 Asahi boxes were doing some more complex container builds faster than some baremetal EPYC build boxes in that stack! Snapdragon X has a lot of unrealized potential.

@vwbusguy @sfalken @jorge There is no potential for Snapdragon X as long as it has broken UEFI and you are locked out of CPU features because you're not Windows (like hardware accelerated virtualization).

@Conan_Kudo @sfalken @jorge

According to Qualcomm, UEFI on Linux should be supported. Is this OEM vendor shenanigans again?

EDIT: Ah, yes. "Working closely with open source community to get support"

https://www.qualcomm.com/developer/blog/2024/05/upstreaming-linux-kernel-support-for-the-snapdragon-x-elite

@vwbusguy @sfalken @jorge It is not *not* supported. It is UEFI, but the ACPI is broken. You still need to do DeviceTree trickery, which makes scaling up to more devices really difficult.

@Conan_Kudo @vwbusguy @sfalken @jorge devicetree and uefi are entirely orthogonal.

there is active work underway to improve DT support across distros and find ways to scale, ofc all have their downsides.

im still half tempted to lean into U-Boot porting and using LVFS to provide DT updates, but dont have the resources or time to make that viable.

we also need a good mechanism to get firmware, since on many laptops it can only (legally) be pulled from the windows partition- this is a bigger issue imho than DT

probably having a windows tool to "prep" your laptop by installing U-Boot and putting the firmware somewhere accessible would be the most viable option for scaling up but yeah its a bunch of work.

on the distro side at least im working on some "integrator guide" to hopefully clarify things there and encourage more distro adoption in the ways that are viable today (even if only for a subset of supported laptops) - that will get published soon i hope

@cas @vwbusguy @sfalken @jorge There are two problems with DeviceTree:

- The DT format is not standardized. It's dependent on the Linux kernel and if it changes in-kernel, you're kind of screwed.
- DTs need to be made per-board. Fundamentally, this is not maintainable if it has to be managed by us instead of the board maker.

ACPI exists to avoid these issues, because they used to exist for x86 too. Unless the DT is burned into the board and Linux doesn't break it, it doesn't scale.

@Conan_Kudo @vwbusguy @sfalken @jorge yeah dude you're talking to a kernel developer - one who has been in many meetings about getting linux distros to run on these specific laptops. dont tell me how to suck eggs.

theres DT churn now - and will be for as long as we implicitly acknowledge the toe between DT and kernel. if we start embedding DT into firmware then upstream will have to contend with the fact that folks might be using older DT. This is the preferred approach

the ACPI qualcomm ship is for now and for the foreseeable future not acceptable for Linux, add to that the work required to get all the existing drivers to support it and it just doesnt make sense.

chainloading u-boot would allow us to simulate the DT being embedded in the firmware, with the added bonus of us controlling the firmware upgrades so we aren't relying on vendors to actually ship updates

@cas @vwbusguy @sfalken @jorge Yeah, and I'm a distro developer. I'm saying *we* cannot handle the way ARM people want things to work.

I *want* vendors properly owning the DTs including updates, we should *not* be in that business, because then it means we as Linux developers need to have the devices to make those.

@Conan_Kudo @vwbusguy @sfalken @jorge

ARM people? what ARM people?

ive talked to folks from fedora, ubuntu, and debian about this stuff, and of course i also play both sides (though postmarketOS has a lot more flexibility than most distros). Your name isnt one that comes up, and frankly the authority with which you speak on a topic you have demonstrated you know very little about is worrying.