FEX-emu – Run x86 applications on ARM64 Linux devices
fex-emu.com> FEX allows you to run x86 applications on ARM64 Linux devices, similar to qemu-user and box64. It offers broad compatibility with both 32-bit and 64-bit binaries, and it can be used alongside Wine/Proton to play Windows games.
> It supports forwarding API calls to host system libraries like OpenGL or Vulkan to reduce emulation overhead. An experimental code cache helps minimize in-game stuttering as much as possible. Furthermore, a per-app configuration system allows tweaking performance per game, e.g. by skipping costly memory model emulation. We also provide a user-friendly FEXConfig GUI to explore and change these settings.
> On the technical side, FEX features an advanced binary recompiler that supports all modern extensions of the x86(-64) instruction set, including AVX/AVX2. The heart of this recompiler is a custom IR that allows us to generate more optimized code than a traditional splatter JIT. A comprehensive system call translation layer takes care of differences between the emulated and host operating systems and implements even niche features like seccomp. A modular core enables FEX to be used as a WoW64/ARM64EC backend in Wine.
Used by the new Steam Frame (https://store.steampowered.com/sale/steamframe) which is an ARM64 Snapdragon 8 Gen 3 that will run PC and PCVR gaming titles.
CodeWeavers' Crossover just released a Preview version for Arm that incorporates Fex and allows games like Cyberpunk 2077 to run: https://www.codeweavers.com/blog/mjohnson/2025/11/6/twist-ou...
I've tested it on an Ampere workstation, and was trying it on a Pi, but it seems with Trixie, there may be some bugs with both that and box64 right now, I was having trouble with both of them.
Hey, it's that YouTube guy with cursed Raspberry Pi setups!
What motivates CodeWeavers specifically to work on this?
They make CrossOver, which is a productized version of Wine that lets you run Windows software on MacOS. They also work closely with Valve, who have just announced Steam Frame (a device that runs SteamOS on ARM).
> The main corporate sponsor of Wine is CodeWeavers, which employs Julliard and many other Wine developers to work on Wine and on CrossOver, CodeWeavers' supported version of Wine.
It is quite likely that Valve is paying for this work. It benefits the Steam Frame.
Not just used by, Valve is sponsoring FEX.
https://news.ycombinator.com/item?id=45903610#:~:text=Valve%...
I wouldn't call this random comment reliable testimony that they are sponsoring FEX.
They took their sweet time but both the project lead Ryan Houdek as well as Valve developer Pierre-Loup Griffais (username Plagman here in the comments) have now come out saying that FEX-Emu was not just sponsored by Valve but is actually their project and that they approached suitable developers with the idea who they have been paying for the development: https://www.gamingonlinux.com/2025/12/valve-have-been-fundin...
https://gamersnexus.net/pc-builds-news/valve-steam-machine-d... "Valve has devoted significant resources to the development of FEX emulation."
Man, Fex is Valve, Valve is Fex! The steam logo is right there in the logo!
https://files.mastodon.social/accounts/headers/110/652/595/6...
Center of left side, it is a Valve product. All main devs are employed by Valve.
As the random commenter I agree. By "support" I meant that they have a line of product and a strategy that relies on FEX to work and work as seamlessly as possible.
If they contribute to FEX at even a fraction of what they did to wine and Proton it is indeed huge.
Does that mean I can run windows games on my rpi? (In theory at least)
Yes (just possibly at ~2 fps)
Into the Breach is back on the menu.
There's probably a mountain of x86 games that would not need to hit above 15-30fps to be fun.
Into the Breach can even run on a Pi 4: https://youtu.be/jF6xGlmKVUQ
Put a GPU on it, and you can get 30+ fps in some newer(ish) games, 60+ fps in older games.
A binary recompiler for running x86 on a different architecture? Where have I heard this story before?
The example that most people think of these days is Rosetta. But I also always think of FX32 as I think it was the first.
The Alpha was such a great platform. It is too bad it’s reign was so brief.
I'n incredibly impressed by valve's commitment to playing the long game. It makes sense to have the frame by arm since the system is lighter and its clear this is just the trojan horse to get arm linux into every gamer's house. I wouldn't be surprised if we end up with an arm steamdeck 1-2 version from now when the tech is ready.
Too bad Arm doesn't allow architectural licenses, because this is exactly the kind of thing Valve and the FEX developers would want to extend the ISA to support. I bet we see a RISC-V backend to FEX in the next 6 months, it probably already exists in a private repo.
FEX is the shootstring, extra special discount budget (not maligning) version of Rosetta. Apple should sell Rosetta to Valve.
My understanding is that Rosetta sidesteps a bunch of tricky memory model issues by using non-standard hardware extensions only present in Apple Silicon, so even if Apple did share Rosetta, which they certainly won't, it wouldn't work properly on Valves hardware anyway.
It's not only present in Apple Silicon, it's just not required by the ARM standard. Fujitsu also has an ARM64 CPU with TSO.
Nice article on this topic: https://lwn.net/Articles/970907/
There are a bunch of undocumented flags and instructions beyond TSO.
Trust me on this one?
https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
> Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.
Perhaps another interesting aspect of this is that it’ll be Apple with their vertical stack that will decide when to physically remove this logic from the chips.
macOS 26 is the last OS with an Intel build. Presumably this means that in all likelihood, M6 chips will remove this functionality.
Why do you assume that dropping support for Intel hardware from the OS will coincide with dropping hardware features that help support for x86 applications? Have you not seen Apple's documentation that states they plan to retain some Rosetta functionality beyond macOS 27 for the sake of x86 games?
I think that documentation essentially demonstrates how Apple wants to put as little resources into it as possible without making users of popular applications mad.
They might even decide that they will be moving that functionality to software and decide to also leverage FEX.
I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.
> They might even decide that they will be moving that functionality to software and decide to also leverage FEX.
That's crazy. Modifying an already-working CPU design to remove hardware features, and modifying Rosetta to implement that capability in software instead, or wholly replacing Rosetta with FEX, would all require investing more resources and effort than continuing to ship what's already done and working.
> I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.
Fair enough, but we don't actually have to make projections based on past patterns of behavior when Apple has explicitly shared their plans. They do plan to maintain support for unmaintained games.
I think the only reasonable way to interpret what Apple has said about their plans for Rosetta is to assume they're not likely to muck about with the low-level details of how they handle running x86 machine code, but they are likely to start dropping some x86 libraries from the OS, breaking applications that depend on them. We can reasonably expect that they're retain all the pieces necessary for running x86 Windows software (especially games) under Wine. (Keep in mind that Apple's approach is to not mix x86 and Arm code in the same process; they didn't do anything like Microsoft's Arm64EC.)
The motivation is that die space on the chip is precious.
If carrying around a little bit of x86 compatibility baggage had enough die size cost to matter for Apple, then Intel and AMD would be pushing much harder to reduce their comparative mountain of x86 compatibility baggage.
In reality, the costs of design changes and validation and updating software to not rely on a newly-deprecated hardware feature can easily outweigh the potential per-chip cost savings of eliminating an instruction or two from a CPU core.
I don’t think that’s a very good comparison.
Intel and AMD have to maintain compatibility in a much different way. They don’t control what is done on the OS, they don’t control what is done with the physical product sold in stores. They have gigantic customers like Dell and HP and Microsoft that make specific technical demands out of their architecture.
Apple controls the whole stack. They decide exactly what features are in software and are in hardware. There are zero Apple machines in data centers running BigCorp’s legacy CashCow software. There are zero laptop or desktop OEMs that use Apple’s chips besides Apple. Apple won’t piss off their core consumer or creative professional customers by changing some technical behind-the-scenes feature.
I think Apple would gladly cut a very small and specific architecture feature from their chips if they feel it’s obsolete, better accomplished in software or not at all.
And this isn’t just for cost savings, it could be for performance and/or battery life optimization, or to make room for something else in the package.
I am not sure I consider it that likely.
First, these features are a big draw for developers (a key macOS audience).
Second, the ability to run Windows games is not getting less valuable.
I don’t think Apple is catering to developers at all. If that were the case they wouldn’t be charging them $100 a year just to exist. They have the marketshare especially in iOS to force developers on to their platform.
I believe that running Windows games is something that Apple does not care about at all. Their efforts to create the game porting tool kit are 100% about getting more Windows games ported to the macOS App Store.
Oh yeah, maybe that one was too obscure for me. I don't think I've ever seen something use PF/AF…
You do want FEAT_AFP though, so you do want ARMv8.6+.
SETP is used rarely to compute parity, though it doesn't really save anything if you can use POPCNT. PF is also used by floating point comparisons with a different meaning though that is not useful for the Arm extension from Apple.
AF indeed is basically unused. The problem for both is that you need them for accurate emulation "just in case".
You can eliminate flag generation almost all the time with a little optimization (slash deoptimizing if you hit an unexpected use) but it certainly is less convenient to have to implement an optimizer.
The unexpectedly hard bit is switch statements, which are the main case in which compiled code has two back to back jumps... therefore the input flags come from a different basic block and you don't know which instruction generated it.
There are also RISC-V designs with TSO. If you are targeting x86 workloads, it makes sense to have a per thread TSO mode.
yeah that is correct. The m series chips can turn on total store ordering memory model solely for Rosetta. There's also some hardware extensions to arm to support x86 condition codes in the hardware because it's way more instruction efficient that way.
The latter is now an optional feature in the mainstream Arm ISA now (FEAT_FlagM and FEAT_FlagM2). Similarly the “alternate floating point mode” that Apple uses to match nuances of x86 FP semantics is a standard architectural feature as well. The TSO option though is Apples own thing.
If you mean FEAT_FlagM, that's standard in ARMv8.4. (There's also FlagM2 and AFP that are optional.)
The JavaScript instruction is cooler though.
https://developer.arm.com/documentation/dui0801/g/A64-Floati...
RISC is dead; long live RISC
Box64 already runs on RISC-V. Just, the available processors are so slow it's hard to even play 5-10 year old games.
This means that, when the much faster chips implementing RVA23 arrive next year, they'll be immediately able to run Box64.
ARM already has most stuff required for this on board. Two proprietary extensions are used by Rosetta: one emulates the parity (rarely used) and half-carry (obsolete) flags, which can also be emulated conventionally. The other implementa TSO memory ordering, which can either be ignored or implemented with explicit barriers; some other chips apparently have a similar setting.
The other stuff is all present in ARMv8.5 I think.
You are looking for Felix86
> Too bad Arm doesn't allow architectural licenses
QEMU exists. I doubt they want the bad press of suing an Open Source project everyone is using.
ARM were perfectly fine getting the bad press for suing Qualcomm for releasing the Snapdragon that was finally performing enough despite these companies paying them a lot of money.
They seemed quite happy to destroy their eco system if they won.
https://www.rcrwireless.com/20251001/business/qualcomm-arm-2
And GBA emulators. And before that, BBC Accorn ones with Risc OS.
better yet, Apple should make it open-source on github.
> Apple should sell Rosetta to Valve.
Isn't Rosetta kinda bad though? And won't get much better because it's not open source?
Rosetta performance is best in class to my knowledge, although they had the benefit of being able to add custom instructions and modes to the cpu to make some parts easier. Meaning Rosetta would not have helped valve unless they built the frame on apple silicon.
As for not improving, it is likely that Apple no longer feels the need to invest in Rosetta improvements now that Apple silicon is so dominant and software support is already very strong, but nothing is stopping them from investing in it if they need it for example for gaming
Rosetta is abandonware: https://developer.apple.com/documentation/apple-silicon/abou...
Why would a company on its way to the moon, entrust such an important project as translation layer between two major architectures to a single rinky-dinky corp that got rich selling common electronics marketed as luxury fluff, that's on the decline and has head so far stuck up its butt that it thinks it can do whatever it wants, instead of just write it themselves with support of the global developer community?
Apple could never do games because there are no luxury games. That's completely out of their zone of comprehensibility.
> got rich selling common electronics marketed as luxury fluff
Apple products have pretty good build quality and perf per watt that more than justifies the premium. AS far as I can tell, the only payer in the market thats even trying to compete with apple on quality in the laptop space is framework. But Framework can't make their own chips.
I don’t know if the two companies have such different futures.
The games industry as a whole is in potentially terminal decline, have you seen all of the redundancies lately?
The AAA games industry with their multi-million budgets and "being too big to fail" mentality is on decline. It seems that anything that is not a new Call of Duty is considered not worth by the industry.
But smaller games and indie studios are thriving. We got lots of very interesting indie games this year.
Games take years to make, as a consumer you’re seeing results from the past. Most indie studios are doing poorly, I know several that have closed and many friends looking for work.
Last I heard, they don't even have bosses there, a flat hierarchy. They vote on things and pick each other to work on teams and appraise performance. Perhaps that radical culture has merit to it?
How much did Gabe own Valve, 50%?
Gabe Ownership/co-founder:
- Valve - Yacht Companies - Starfish Neuroscience (Neuralink) - Submarine Companies
I've heard that to ship hl2 (or anything really) they had to stip some of that flatness somewhat.
Anything works when you have infinite money and the company is privately owned by a chill dude.
It’s amazing what you can do when you have a business that prints money hand over first and you have no obligations to shareholders.
Helps that they are in dominant position and basically just need to not fuck up
I would appreciate more if they also would take devs into SteamOS water, instead of relying on Microsoft kindness.
I tried out FEX on a modern ARM board with a discrete GPU. Really impressed with the performance.
https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-th...
FEX is a CPU JIT, so your GPU settings are irrelevant to it, it is translated but not by FEX, and there is no real perf hit for the GPU
The old games don't really matter with regards to FEX perf, so the only relevant bit is the semi newer games at 30/40 fps, which seems very slow to me, given that you are only running at 1080p/Medium, so you likely have a CPU bottleneck there.
Wow decent results.. impressed.
I would keep in mind that the results reported there are likely quite a bit lower (in terms of CPU-side performance) than what you could achieve in practice, because it's running all of x86 Steam+Proton in the emulator. In a pre-configured environment (like SteamOS for ARM), the Steam client and Proton itself would be native ARM code, and emulation would stop at the win32 API boundary (or at certain critical libraries' APIs if you're using Linux apps).
Fancy seeing the Plagman here. Last time I saw you was on Freenode (R.I.P.). So you are still working for Valve? ;-)
How does fex deal with the fact that the memory model on arm is weak and x86 is total store ordering. It seems like would need to hammer performance by putting memory barriers everywhere to handle all cases. Perhaps fex only works when there are well defined mutexes it can gain visibility into? anyone know?
Looks like they do expensive conservative TSO emulation by default, but they're able to piggyback on compiler work that Microsoft did to make newer Windows x86 binaries easier to emulate. Since MSVC 2019 they annotate the executable with metadata that informs an emulator of when TSO is or isn't needed for correctness.
FEX also has settings which weaken or disable TSO altogether, favoring performance over correctness. You wouldn't want to rely on those for anything important but a game possibly crashing isn't the end of the world.
So that optimization only works on executables produced by MSVC? Are those annotations documented and/or produced by other compilers?
No.
It would be nice to see more Arm chips adopt Apple's approach (which fixes this problem) for Rosetta 2. Basically, Apple's chips can be switched into a TSO mode and a few other minor tweaks that make x86 code run much, much faster.
I think that's right, there is no better way than just adding barriers. On Apple hardware it can probably make use of the special memory ordering mode, but on normal ARM64 there's probably nothing it can do.
There’s one trick: run those threads on one cpu. But that may be slower than barriers on multiple CPU’s, unless the code uses a lot of library code that can be emulated directly, separately on other cpus.
I believe a lot of the folks working on FEX are also core contributors to Dolphin, the Wii/GC emulator.
Nope, Dolphin emulates PowerPC not ARM or ARM64. Totally different architecture.
I was saying some of the top contributors of Dolphin are also top contributors of this project based on GitHub data.
That's really cool! I didn't know, thx for your comment :)
Some companies like to stress the efficiency or performance of Arm SoCs, but really this is a hedge against more expensive x86 hardware. AMD has increased prices of mobile SoCs radically recently. I'm looking forward to having more affordable SoC options for laptops, handhelds and desktops, perhaps from Mediatek or other lower-cost vendors.
The history of the PC is one of commoditization. A fractured multi-polar landscape is detrimental to the ecosystem/productivity and should ultimately fail.
x86 emulation is an important puzzle piece, and I'm happy Valve recognizes this and sponsors it.
This is for the Steam Frame
One problem I see is that (e.g.) Qualcomm Adreno GPUs don't even run most Windows games well when executed natively under Windows, due to games only being optimized for GeForce and Radeon. I assume this problem only gets worse when trying to run DirectX games through some sort of translation layer with FEX/DXVK.
See the corresponding Igalia article for more details: https://www.igalia.com/2025/11/helpingvalve.html
The GPU is not run through a translation layer. The GPU is not an x86-64 CPU.
Only the CPU code has to be emulated. The GPU runs natively.
That does not help with poorly supported GPUs of course.
Pretty sure the GPU doesn't understand DirectX, which is used for Windows games, so it must be run through a translation layer.
Wrapping graphics APIs adds effectively zero overhead if the featureset of the hardware and drivers are a close enough match.
Sure, you are translating DirectX to Vulkan and that work is done on the CPU. So it may need emulation. But the Vulkan instructions passed to the GPU are effectively native. The amount of work the GPU has to do to execute against those calls is the same regardless of CPU architecture.
Presentation at FOSDEM2022: https://archive.fosdem.org/2022/schedule/event/fex/
A little old but still interesting.
How is it different to box64? I couldn't really find much online comparing these two except a brench by box64 themselves.
No different. Box64 only drm free game first, later they support drm games.
Fex straight drm games.
Are you referring to Linux's Direct Rendering Manager or to Digital Rights Management in this context?
Digital Rights Management
Curious how this will impact the major games that are incompatible due to denuvo type stuff
IIUC that DRM involves kernel level tricks and attestation, which means it'll basically never happen. Online gaming looks similarly doomed.
Denuvo anti-tamper DRM doesn't use kernel level tricks, it's all userspace and works just fine on Linux/Proton. It's the kernel level anti-cheats that don't work on Linux. And some user level anti cheats (like AntiCheat Expert) that only work on the Steam Deck as they check the CPU/GPU of the system and refuse to work if it's not the one in the Steam Deck (which also means those don't work on platforms like the ROG Ally).
Plenty of online games work fine. Rocket League, Squad, Arc Raiders etc. are just the ones that I play.
In the case of those which use EAC/EOS they need to be explicitly approved to run under Wine/Proton by the developer. There are some cases (eg. iRacing) where the developer refuses to enable support for whatever reason, and on those we’re still stuck.
It's not just 'running under Wine', it's a different anti-cheat with different capabilities and the same name.
It's like comparing Office 2024 Excel on Windows to Excel for iPad. They're both called Excel, and share basic features, but once you start using features like VBA, it will not run on iPad Excel.
Also does it even work in Wine? Last I checked EAC only worked in Proton with the env variable to enable it being PROTON_EAC_RUNTIME
That doesn't even work properly on x86 Wine, so ARM is pretty much hopeless right now.
That is false. Denuvo DRM works on Linux and has for many years.
I didn't say it doesn't work at all, but it's been problematic. An example:
https://www.gamingonlinux.com/2025/05/denuvo-will-lock-you-o...
That issue only happens if there are other issue with the game unrelated to denuvo on wine which requires trying different prefixes resulting in the DRM locking you out. Its the fault of the horrible DRM.
Denuvo DRM works on Linux and has for many years.
So, can you run Steam and games on a Raspberry Pi 500?
Yup
Like, already, or in theory?
Now we just need a decent ARM Linux laptop.
Anyone can recommend something viable for simple tasks? I don't need 32GB of VRAM, just a reliable machine for everyday tasks that's decent, lightweight, has a good battery.
(I know I'm describing an M2 Air, but I'd like to explore alternatives.)
Lenovo Chromebook Plus 12 or Acer - Chromebook Plus Spin 514. Both have an M2 equivalent MediaTek Kompanio ARM CPU/GPU, and comes with native Debian VM built in (Crostini) that runs standard Linux desktop apps. Battery life and performance are great. You can even get it pretty loaded up with RAM to run smaller LLMs if that's your jam.
As you can tell from my past comments about Chromebooks as Linux workstations here, I'm a daily user and very happy with them.
I have the azus ZenBook a14 with X Elite, 32GB ram, 1TB SSD. Overall it works great on Ubuntu concept. Only speakers and camera do not work (I heard speakers can work with some risk). I just use usb headphones instead and my webcam. The laptop itself is very light with long battery life. I expect it to be better supported at some point hopefully, but it's getting there.
I would wait for X2 Elite laptops at this point.
Qualcomm is already upstreaming support into Linux.
I would wait for X2 Elite laptops at this point.
Qualcomm is already upstreaming support into Linux.
Take this with a grain of salt but since we are one the topic of games….
https://www.techpowerup.com/343081/qualcomm-says-90-of-games...
Get a MacBook with Asahi Linux
Asahi Linux doesn't support M3/M4/M5
And? Get an M1/M2 off of ebay or craigslist.
Alternatively: we need fex-emu to run on macos.
Snapdragon Elite X laptops are plenty decent.
Not for Linux they're not. IIRC Audio and camera don't work, and firmware is non-redistributable and so you need to mooch it off a Windows partition. On top of that the performance on Linux hasn't been great either.
Highly depends on which laptop
Qualcomm's linux support is not.
That's true Qualcomm in general, but is fortunately outdated for the Snapdragon Elite X (and only the X). Qualcomm has been upstreaming patches to Linus' tree[1] - but only for the Elite X - the Elite P processors get the classic Qualcomm treatment.
1. https://www.qualcomm.com/developer/blog/2024/05/upstreaming-...
You're mangling Qualcomm's branding to the point that it's impossible to be sure what you're trying to say. Qualcomm's current laptop SoCs are called "Snapdragon X Elite" or "Snapdragon X Plus" or "Snapdragon X", all derived from various bins of two SoC designs, and all pretty much in the same boat for driver support purposes. "Snapdragon X2 Elite" and lesser siblings are due in the first half of next year, so a respectable degree of Linux support would mean having driver support for those chips in an upstream kernel release now so that there might be a mainstream distro supporting the hardware at some point in the quarter after the hardware ships.
My apologies to you and the entire Qualcomm marketing team for my brand-guideline violations - I was going off the top of my head. What I meant in my inscrutable comment was: "Elite X" => "X Elite", "Elite P" => "X Plus", I really should not have mangled the products using such an elegant and intuitive naming convention.
Ok, so having clarified the naming, it still looks like you're wrong about which chips are getting driver support upstreamed, because the Snapdragon X Plus parts are (with maybe one exception, IIRC) literally the same chip as the Snapdragon X Elite parts. Do you really believe that the upstream Linux kernel would accept patches that are specifically crafted to only work on certain bins of the chip, or to fail to enable a peripheral if not enough of the CPU cores are enabled?
Don't take my word for it - go to the Ubuntu Concept Snapdragon thread[1] and search for "plus" or "x1p".
> Do you really believe that the upstream Linux kernel would accept patches that are specifically crafted to only work on certain bins of the chip, or to fail to enable a peripheral if not enough of the CPU cores are enabled?
It takes more than a kernel patch to boot a laptop. Qualcomm has been neglecting to release the dtbs for Plus laptops. If you want good peripheral support, don't buy a "plus" variant. Getting back to your question, the answer is "Yes, Linux has always accepted patches that only work on some configurations" with no requirement to support all h/w configuration variants. Infact, some configurations are so obscure only the submitter can test - the maintainer/subsystem chief/Linus may not even know what the potential variants are.
1. https://discourse.ubuntu.com/t/ubuntu-concept-snapdragon-x-e...
I don't think your link contains the evidence you think it does. I'm not seeing anything that looks like Qualcomm contributing device trees on behalf of system OEMs, for any of the Snapdragon X products, so I don't see how you can claim that they're being selective. It looks like the device trees are mostly being reverse-engineered by the community, adding new system support derived from device trees for systems that already have some support.
Do you have any clear instances of Qualcomm contributing something that's specific to Snapdragon X Elite parts and does not work for Snapdragon X Plus bins of the same silicon?
Or even for the more general issue: have you ever seen a Linux driver include arbitrary restrictions that make it refuse to work on identical hardware just because the marketing name for that bin of the same silicon was different?
> Do you have any clear instances of Qualcomm contributing something that's specific to Snapdragon X Elite parts and does not work for Snapdragon X Plus bins of the same silicon?
You're getting caught up by inconsistencies in an argument you brought up. Which suggests the argument itself is flawed.
My unchanged position is Snapdragon X Elite laptops have better Linux support than the Plus variants. You thought I was wrong on that count - but I wasn't (see the thread).
Qualcomm only ever pledged to support Elite processors, and perhaps not coincidentally all of the Plus laptops require reversing- this is enough for me to draw conclusions. If you need the technical root cause, feel free to delve into why the originally supported models with devicetres had Elite chips.
> Qualcomm only ever pledged to support Elite processors
Link, please.
> and perhaps not coincidentally all of the Plus laptops require reversing
You're still acting as though Qualcomm has made meaningful contributions to Linux support for Snapdragon X Elite in a way that has not also helped Snapdragon X Plus support. But you haven't specifically pointed to any Qualcomm contributions of any nature, let alone ones that were as narrow as you claim. All you've done is point to weak evidence that machines with Snapdragon X Elite bins reached a reasonable threshold of "supported" earlier than models with lesser parts, while ignoring that your evidence also points to the lower-tier processors coming to market later.
Can you point to any laptop device tree that was contributed by Qualcomm, and not merely reverse-engineered from the device tree for the reference design that was not offered for sale to consumers? Can you point to any driver contributed by Qualcomm that works for Snapdragon X Elite SoCs but requires further modification to work for Snapdragon X Plus SoCs?
You made a claim about a pattern in Qualcomm's public behavior, and have identified zero instances of that pattern.
> Link, please.
Try the first Qualcomm link I sent upthread. I have trouble accepting you're arguing in good faith because you could have checked this for yourself. All the articles I can find pivlished by, or quoting Qualcomm concerning Snapdragon X and Linux consistently refer to the Elite version: I challenge you to find a single counterexample that mentions Plus.
You call my evidence weak, and yet you have provided no evidence to support your evolving argument thus far, so I hereby invoke Hitchen's razor, and will not engage with you beyond this comment. I refuse to spend any more of my time and energy trawling a 1200+ page Discord thread, Gthub, or the kernel mailing list searching for empirical evidence to counter your 10-second thought experiments, when you can't be bothered to open links I've already shared unprompted.
I bid you good day.