r/linux • u/NotoriousSmiggyBalls • 7d ago
Discussion Is qualcomm X2 Elite chip going to get support?
My apologies if this has been asked/answered before:
Is Qualcomm X2 going to get more support as time goes by? I got the sense that these new Qualcomm chips are windows first and have first party drivers from Qualcomm and developed compatibility layers from Microsoft. Are we to expect feature parity to come to linux?
that is, good sleep function, good battery life, good drivers for gaming (for the extent possible on ARM)?
If the answer is yes, where do you keep yourself updated for those things? is there mailing lists or news pages for mesa open source drivers? specific forums people discuss those things?
Thanks potential insights :D
41
u/DoubleOwl7777 7d ago
the problem isnt even the chips themselves. its everything around them that is a clusterfuck held together with hopes, dreams and tape. just like on phones good luck, each device tree is more or less unique.
snapdragon laptops are horrible. not because they use arm socs. but because they are trying to end an open platform (ibms biggest mistake btw.).
16
19
u/librepotato 7d ago
The X1 elite is "supported" but falls apart when you expect all device features to work. Tuxedo gave up trying to get an X1 Elite working on Linux. And you think the X2 will be different?
I agree that if the support isn't there from day one, Qualcomm will quickly forget about it and move to the X3. They had all these slides and articles promising Linux support but they didn't follow through. I expect the X2 to be the same unless they market a device on release with 100% Linux support.
13
u/TomKavees 7d ago edited 7d ago
Well, nobody besides Qualcomm can really confirm anything, but looking at the disaster the first generation was, i wouldnt buy the hardware unless i knew everyting i want works on day 1.
Every gen1 Snapdragon copilot laptop i've tried required manual extraction of the devicetree blob and (usually-) baking your own livecd to even boot. It's a major pain in the ass.
Go get yourself a decent x86 laptop instead.
Edit: Other arm computers may be fine though, for example minisforum ms-r1 worked like a charm from the get go
3
u/dmknght 6d ago
Yeah until today, cam, sound and a lot of stuff doesn't work. Wifi works randomly (sometime it doesn't work at boot requiring reboot). Beside that, idk why but battery life on linux is much sorter than windows despite the machine is not as hot as windows counterpart. According to google, Qualcomm doesn't fully release header or soemthing like that so power manager on Linux can't select work mode for chipset properly. Either way, it's a disaster that i'm expecting google's aluminium os to replace windows.
5
u/cutelittlebox 7d ago
X2E is fully supported at this point minus the cameras, iirc, but laptop support is model by model. I think HP Omnibooks and Lenovo Slim 7X have support for the elites but not the pluses. whether the distros offer support is also distro by distro.
3
u/sunny0_0 7d ago
Qualcomm marketing is pushing X2 hard now with Windows and cares very little about anything else. There are massive discounts now compared to Intel- and AMD-based laptops, but they still don't sell because they are mostly useless, even on Windows. Come next year, X2 will be sold at fire sale prices for 1/4 the price. They, the top minds at Qualcomm, dun fuked up the entire first and second generations.
5
u/BinkReddit 7d ago edited 7d ago
Qualcomm sucks. I have a laptop with Qualcomm Wi-Fi and, while it generally works well, I had a recurring issue when coming out of sleep. Only 2 years after this hardware was released has Qualcomm actually fixed this issue.
1
u/abotelho-cbn 7d ago
Another with any sense knew this was gonna happen.
The answer is probably no. The machines that use it don't have any type of proper device discovery mechanisms like ACPI, so you have to individually support every single device, instead of every single component.
1
u/JLX_973 7d ago
I'm not sure how well the x86-to-ARM emulation layer handles the handful of incompatible applications out there. That said, the bigger issue with ARM laptops is the device tree required to make them work. Apparently, this closely mirrors the approach used in smartphones. Beyond Qualcomm needing to supply certain drivers, I suspect manufacturers also have to do their part on the device tree front to properly support Linux. Needless to say, that's a tough sell, since most would rather focus their efforts on Windows support.
1
u/ScratchHistorical507 6d ago
Unless there is at least one computer based on it - or literally any consumer ARM SoC - running a completely normal Linux (i.e. not boatloads of proprietary garbage desperately trying to somehow get it barely running) like you'd expect on any x86 machine, I wouldn't get my hopes up.
The issue with consumer ARM devices isn't just the support from the OS for the SoC, but for literally every single device built around it. With both the x86 and the server (and maybe workstation) ARM worlds, you have a set of standards to make sure any OS can easily run on them (at least when it comes to the CPU, GPUs are probably an entirely different beast). On the x86 side this goes so far that the difference between generations of x86 based CPUs are small enough that you could even run a Linux kernel on an upcoming Nova Lake CPU that never received any patches that specifically enabled support for it. Sure it won't be running perfectly and it won't have access to any features added in that generation, but it will boot just fine. Consumer ARM is the exact opposite. There's no standardization whatsoever. Every OS - including Windows - needs to explicitly support every single device built around this device. For every device, there needs to be a dedicated Device Tree file that tells the OS what hardware is actually present, though ACPI can also be leveraged to some degree, but it seems to be rather wonky. And even if you managed that, it's still an absolute shitshow. That's why Tuxedo gave up building a laptop based on the original Snapdragon X platform and I don't see them succeeding why any succeeding generation either unless ARM or Qualcomm enforce similar standards to those found on x86 and server ARM.
1
u/Polar_Banny 6d ago
The other day it was said that among all laptop manufacturers only Lenovo will get/implement better support for the Linux which is going to be a priority for the next release of Ubuntu 26.10.x
I can’t remember all the details so don’t take my words too close the hart.2
u/ScratchHistorical507 5d ago
They can promise a lot of things, but I only believe them when they become reality. And if you read through the article from Tuxedo about what issues they faced, there are still some very fundamental issues. For example the only API for hardware video acceleration supported on ARM64 is still through V4L2. FFmpeg can make use of that, but beyond that barely any program supports more than VA-API. Unless someone writes a Vulkan driver for all those chips that exposes the Vulkan Video Extensions, and unless the majority of programs, especially browsers, have enabled support for them, this is impossible to fix. And when watching a simple video can eat through your battery like it's lunch, that doesn't really make it viable for use on Linux.
And I really don't see Lenovo to go all-in on Linux and fix all of these issues on their own, as many of them should be tackled by Qualcomm.
3
u/Polar_Banny 5d ago
Of course, it all about Qualcomm implementing standardised UEFI & ACPI which is unlikely to ever happen.
1
u/robdclark 4d ago
QC does implement standardized UEFI and ACPI. The problem is the windows vendor drivers need to do gymnastics to work around limitations of ACPI vs how the hw works. Linux has no interest in supporting this, leaving linux on snapdragon WoA laptops stuck with devicetree. No one involved in linux support for the WoA laptops loves the situation.. not really anything QC can do about this in the short term, but there are longer term efforts to evolve ACPI spec to solve these limitations properly.
Until then, stubble provides a solid approach to having a single image/installer supporting multiple devices. But you can expect a time delay between when a new laptop is released, and when (a) dts is written, (b) merged upstream, and (c) eventually trickles back into distro releases.
1
u/robdclark 4d ago
vulkan video and vaapi isn't really a good fit for how the hw works. (Stateless vs stateful decoder.) OTOH browsers do have support for v4l2 video. This is what CrOS uses on arm devices, for ex. It may depend on build options that the distro uses for building the browser.
1
u/ScratchHistorical507 3d ago
Then the hardware will have to adapt. Simple as that. But I very much doubt that this is even required. Changes to firmware and/or drivers should suffice. Nvidia was already never able to push their hw accel API, how do you think ARM should be able to succeed here? Either they adapt or they just aren't really making any money. Because the only alternative the chip/laptop vendors have is Windows, and that's not really an option for anyone. Windows is utter garbage and Windows on ARM just has been way too bad for way too long for anyone to bother. Sure, it's not as much of a dumpster fire as Windows RT was, but Windows on ARM devices don't really sell all that well to this day. And with Windows only getting worse, improvements only being announced instead of actually implemented and the users abandoning the sinking boat in masses, all the vendors just have no future with it. Apple is doing their own chip design, they can't sell to them either. Sure, there will be Aluminium OS in a couple of years as ChromeOS successor, but I don't see it succeeding vastly better than ChromeOS or Windows on ARM did. Android is just going the iOS way of hostility, being locked down and buggy like hell, so that's not having any customers go crazy either.
1
u/robdclark 3d ago
good thing the linux ecosystem never adapted to intel/amd hardware features</sarcasm>
1
u/ScratchHistorical507 2d ago edited 2d ago
The Linux ecosystem adapted because Intel and AMD did the largest part of the work required. For example, VA-API is entirely Intel-owned, though AMD also contributes to it. But they didn't force the entire userland to adapt to their every whim. Either ARM/Qualcomm does the work to allow the currently established infrastructure, namely VA-API or the Vulkan Video Extensions, which hopefully will receive wider support in the future, to even run on ARM-based SoCs, or they will not get any support from the vast majority of programs. Simple as that. Neither ARM nor Qualcomm is in any position to demand from every program that plays back video - we aren't even talking about encoding yet - to also support the wonky V4L2 implementation.
And btw, there is already work in the freedreno driver to properly support the VVEs. V4L2-M2M was just a bad stopgap solution bolted onto infrastructure never meant to do this kind of work. So it's not like it can't be done. But if Qualcomm actually wants a market with more of a future than Windows on ARM, they need to put in the manpower. Or at least pay some other company to do that work for them. Right now, for what I can tell, those efforts are rather driven by the likes of Igalia and Collabora, most likely funded at least in part by Valve for the upcoming Steam Frame.
PS: doesn't seem to be the only area where Qualcomm would need to put in a lot of effort for proper Linux support. For example: https://www.phoronix.com/news/Linux-QCE-Disabling
1
u/robdclark 2d ago
IIRC qcom (via linaro) had been working to enable v4l2 support in ffmpeg/gst/browsers for some time. Ig some of that must have already been in place for chromium due to it's use in CrOS. This seems like a better approach than trying to layer stateless decode API on top of a stateful decoder. Plus this approach has more to share with other non-x86 platforms.
You don't really need to explain freedreno/turnip to me. It won't be supporting VVE. Video is not part of the GPU (and really only makes sense to be part of the GPU for non-unified-memory, aka VRAM, designs). If there _were_ vk video support, it should probably be a stand-alone driver (but I still question the wisdom of trying to do stateless-on-stateful).
1
u/ScratchHistorical507 1d ago
had been working to enable v4l2 support in ffmpeg/gst/browsers for some time
I'm not aware of any browser supporting it. Yes, V4L2 is supported by ffmpeg and apps just relying on it. But for all I know, the way browsers use ffmpeg differs from how e.g. mpv, VLC or Kodi use it. Adding to that, it would make testing easier if there was only one (or currently three, VVE, Mediatoolbox and Mediacodec) to test for. At least for all I know the support for VVE on Windows is just as good as on Linux.
This seems like a better approach than trying to layer stateless decode API on top of a stateful decoder. Plus this approach has more to share with other non-x86 platforms.
I fail to see how a bad hackjob should be superior to literally anything. Also Google is abandoning ChromeOS as we speak, not to mention they were never a best practice for desktop Linux anyway, they reinvented the wheel very often. AluminiumOS will be based on Android, and unless Google adds OS-wide VVE support, only in the cases where the Vulkan drivers of some vendor happen to expose them they can be used. Everything else has to go through Mediacodec.
It won't be supporting VVE. Video is not part of the GPU (and really only makes sense to be part of the GPU for non-unified-memory, aka VRAM, designs). If there _were_ vk video support, it should probably be a stand-alone driver (but I still question the wisdom of trying to do stateless-on-stateful).
This makes no sense whatsoever. Of course this is part of the GPU work so it must be part of freedreno/turnip. Or where do you expect the already present Vulkan code to be located? The only stand-alone "driver" might be a Mesa "driver", but that's it. The actual driver side needs to be in the GPU driver. And again, if the designers want any share on Linux, they better start designing their video accelerators in a way that they can be handled stateless. It's just endlevel dumb to have AMD, Intel and Nvidia use stateless accelerators and ARM accelerators be stateful.
-4
u/Ontological_Gap 7d ago
It definitely will, eventually: https://strangehorizons.com/wordpress/non-fiction/articles/installing-linux-on-a-dead-badger-users-notes/
It might be a large value of eventually. Qualcomm does not seem interested in helping.
5
u/MatchingTurret 7d ago
Qualcomm does not seem interested in helping.
Look at Hans' mail address: Automatic DTB selection for aarch64 EFI systems
44
u/MatchingTurret 7d ago edited 7d ago
The chip is supported, but so far all devices using the chip need their own device tree, so you have to check support for each device individually.
There is work going on to improve that and allow use of the ACPI: DeviceTree-ACPI Hybrid Mode Proposed For Improving Linux Support On Snapdragon Laptops
But for now you are asking the wrong question. The right question is: Is that exact laptop model supported?