Earlier quoted context omitted.
Not an expert, but porting graphics is the biggest effort. This patch appears to add just the CPU part. Here is one effort to port all of M1 macs to linux: https://www.patreon.com/marcan
It is the very effort that created the linked patchset.
Initial M1 support merged into Linux SoC tree
61–70 of 337 posts
Re: Initial M1 support merged into Linux SoC tree
#62This is very anecdotal but every single laptop I have bought in the last 10 years (4) worked perfectly out-of-the box with either Linux Mint or Ubuntu (which are the same on the inside). I only vaguely remember once I had to change some conf file for my trackpad to work after a dist update but that was it. Not sure why everyone in this thread is so hesitant about Linux on a laptop? It literally just works (tm) for me…
(To be fair, my first Mac+Linux experience was on a PowerBook, which surprisingly worked rather well, though power management was terrible so battery life suffered. Once the Intel train started, it was... not great.)
In 2016 I bought a Razer Blade Stealth, and Linux ran perfectly on it; there was even 3rd-party support for custom things like the tweakable RGB keyboard backlight.
Like a fool, I didn't learn from my mistakes, and in 2018 I installed Linux on an employer-provided 2016 MacBook Pro. At the time, the keyboard and trackpad required an out-of-tree kernel driver (so I needed a USB keyboard and mouse to install), and audio and suspend-to-RAM didn't work (well, suspend was fine, but the disk drive wouldn't wake up on resume). My timing here was actually good, as not long before this, the NVMe drive itself didn't even work.
In 2019 I bought a Dell XPS 13, and aside from the fingerprint sensor, Linux again runs perfectly on it.
So, if you get yourself a laptop that is either specifically made to support Linux, or you've determined via research works well with Linux on it, then you should be fine. Otherwise, you'll probably have issues, unless you're lucky.
(Avoiding laptops with certain things, like Nvidia video and Broadcom WiFi, helps a lot.)
Re: Initial M1 support merged into Linux SoC tree
#63This is very anecdotal but every single laptop I have bought in the last 10 years (4) worked perfectly out-of-the box with either Linux Mint or Ubuntu (which are the same on the inside). I only vaguely remember once I had to change some conf file for my trackpad to work after a dist update but that was it. Not sure why everyone in this thread is so hesitant about Linux on a laptop? It literally just works (tm) for me…
The short answer is that this is a different beast. Much of the hardware in Macs before the M1 was commodity hardware. Now it is all bespoke and undocumented. This is a big undertaking.
But yeah, short-term there's a bit of a barrier to entry. Once it's overcome, though, this might be what pushes me to voluntarily buy any piece of Apple hardware made after 2007.
Re: Initial M1 support merged into Linux SoC tree
#64This is very anecdotal but every single laptop I have bought in the last 10 years (4) worked perfectly out-of-the box with either Linux Mint or Ubuntu (which are the same on the inside). I only vaguely remember once I had to change some conf file for my trackpad to work after a dist update but that was it. Not sure why everyone in this thread is so hesitant about Linux on a laptop? It literally just works (tm) for me…
Re: Initial M1 support merged into Linux SoC tree
#65I sincerely hope that one day, Linux GUI land will receive similar amounts of work as the kernel. While it's great that we can boot it on pretty much every device out there, I would much prefer if it was a viable Windows alternative on a few devices instead. Just yesterday, I plugged an external screen into my Ubuntu laptop. And then I had to duck-duck for like an hour to figure out how to make the fonts large enough…
These businesses have no interest in trying to develop a desktop UI when Mac OS and Windows work fine already and someone else is doing all the work for it already.
Re: Initial M1 support merged into Linux SoC tree
#66I sincerely hope that one day, Linux GUI land will receive similar amounts of work as the kernel. While it's great that we can boot it on pretty much every device out there, I would much prefer if it was a viable Windows alternative on a few devices instead. Just yesterday, I plugged an external screen into my Ubuntu laptop. And then I had to duck-duck for like an hour to figure out how to make the fonts large enough…
After that, cd’ing around my minimal - yet blazing fast - thinkpad w/ void linux felt nearly exhilirating. Didn’t have to touch the mouse for many minutes at a time.
Re: Initial M1 support merged into Linux SoC tree
#67I sincerely hope that one day, Linux GUI land will receive similar amounts of work as the kernel. While it's great that we can boot it on pretty much every device out there, I would much prefer if it was a viable Windows alternative on a few devices instead. Just yesterday, I plugged an external screen into my Ubuntu laptop. And then I had to duck-duck for like an hour to figure out how to make the fonts large enough…
The best way is just to take the plunge. Immerse yourself by removing other OSes from your own PC. In a few weeks you'll be flying.
Re: Initial M1 support merged into Linux SoC tree
#68Somewhat related: I'm super curious if M1's advantages would melt away if Intel simply fabbed their current designs on TSMC's 5nm process, to have a level playing field between Intel and Apple's chip designers.
It's still not a level playing field as they'd be implementing different ISAs. If Intel acquired an ARM architecture license and then designed an ARMv8 CPU with identical constraints then you'd get a valid comparison.
Although you'd likely have different IP in other areas which could skew the results.
If you're looking for a comparison of the ISA's I think the decoding issues / execution width points to a likely ARM win still - only question is by how much.
Re: Initial M1 support merged into Linux SoC tree
#69Earlier quoted context omitted.
Every single laptop my company bought me in the last 10 years (3+) had kernel/driver issues, especially with Ubuntu, since the kernel version was usually lower than that from other distros, like Fedora. This includes mostly graphics driver issues (either simply Nvidia, or hybrids, or some exotic protocols such as DisplayLink), but also touchpad, power/suspend issues (e.g. wake-up failure), lack of fingerprint or smar…
I can live without the fingerprint reader. It’s the lack of hibernate that really sucks. I got my 2013 MBA battery replaced. Leave it unplugged for 10 hours. 1% battery drop. XPS 17 on Pop OS LTS with kernel 5.8. I have to shut down if I want battery left.
It is such a frequent issue I wrote an article 10 years ago that is still extremely relevant with simple instructions to enable a kernel work-around [0].
Specifically the problem is the ACPI DSDT (Differentiated System Description Table) - which is actually byte-code installed by the device manufacturer (but executed by the host OS) that handles device power states and enablement.
The problem is almost always DSDT methods are written to conditionally configure system hardware optimally ONLY when the host OS is a version of Windows as declared by the host OS's ACPI OSI (Operating System Identification).
When Linux boots only a minimal configuration is applied which very often has never been tested and thus devices fail to work reliably, especially for suspend/resume, in interesting ways.
Fortunately, Linux has a WORKAROUND that allows passing a 'fake' OSI on the kernel command-line in the form:
acpi_osi=! "acpi_osi=Windows XXXX"
The first instance (=!) clears all built-in kernel OSIs to avoid confusion. The second string sets the 'best' and only OSI value which has been found in the DSDT of that PC.That can be discovered from a Linux boot using:
sudo strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort
E.g: on my Lenovo E495 (AMD Ryzen 7 3700U) I have: Microsoft Windows NT
Windows 2001
Windows 2001.1
Windows 2001 SP1
Windows 2001 SP2
Windows 2001 SP3
Windows 2006
Windows 2006 SP1
Windows 2009
Windows 2009
Windows 2012
Windows 2013
Windows 2015
Windows 2015
Windows 2016
So, on the basis that "Windows 2016" is the 'latest' and likely the OSI expected to enable all features optimally I use that. On Debian/Ubuntu I therefore have: /etc/default/grub.d/local.cfg
GRUB_CMDLINE_LINUX="acpi_osi=! \"acpi_osi=Windows 2016\" "
Notice the escaped quote-marks inside the shell string since the argument contains a space.(some folks might prefer to edit the package-shipped /etc/default/grub but I prefer to leave that virgin to avoid package-upgrade prompts when that file is replaced.)
After:
sudo update-grub
/boot/grub/grub.cfg
will have the acpi_osi= entries added to all the "linux ..." command linesE.g:
$ grep acpi_osi= /boot/grub/grub.cfg
linux /vmlinuz-5.12.0-rc5+ root=/dev/mapper/ELLOE000-rootfs ro acpi_osi=! "acpi_osi=Windows 2016" systemd.unified_cgroup_hierarchy=1 nosplash
[0] https://iam.tj/prototype/enhancements/Windows-acpi_osi.html