51–60 of 89 posts
Earlier quoted context omitted.
He said he needed patches to make the GPUs work. Kernel package auto-updated does not have those patches and overwrites the custom kernel he built every time there was an update available.
You can disable automatic kernel updates on almost every distribution. Most people that use secure boot and Nvidia do it.
Fascinating! I've been running the laptop version-ish of this experiment with the 14M9610, and my major complaint is Device Tree sucks. It's been explained to me why all of ARM can't just enumerate devices like PCs do, but it still sucks. This means every ARM device starts off in custom kernel territory, which makes all sorts of hacks okay to begin with, since you need a custom kernel anyway.
This is not completely true. You can use a generic kernel with a custom device tree. The only problem is that distributions currently tend to package them together, but that shouldn't be obligatory.
Earlier quoted context omitted.
Linux on apple silicon is a thing though: https://asahilinux.org/
True, but they had to implement their own bootloader chain and because of such overhead they need a lot of effort to port to each new apple SoC generation
Earlier quoted context omitted.
> my major complaint is Device Tree sucks Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.
It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)
All this doesn't require any enumeration and was still standard until BIOS/CSM was removed. PCs could use the same IDE driver for 30 years of hardware! All chipsets were compatible, from 386 to today's SATA in compatibility mode.
ARM made the mistake of not standardizing anything beside CPU instructions (and even those aren't always the same - see the mess armv7 created with thumb, thumb-ee, simd, neon, crypto acceleration, etc.). Of course it needs enumeration. But x86 is now catching up with the mess. Just wait...
Enumeration instead of standardized hw is bad, but I prefer the least worse device tree.
Earlier quoted context omitted.
> my major complaint is Device Tree sucks Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.
It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)
Let's take an example. Raspberry Pi doesn't have a RTC, but it has GPIO header. You add a RTC module on that header, one of several models of RTCs.
With the device tree, you load an overlay with some parameters and a kernel driver module. And it works.
How do you do that with ACPI? Ask the manufacturer for a UEFI update that scans for dozens of RTC types on each I2c bus? Good luck with that! What happens 5 years later when the board is long abandoned (not Raspberry's case, but think of an ordinary chinese manufacturer)?
Earlier quoted context omitted.
This is not completely true. You can use a generic kernel with a custom device tree. The only problem is that distributions currently tend to package them together, but that shouldn't be obligatory.
You can't if the firmware provided DTB doesn't follow any upstream Linux approved bindings and instead uses some vendor kernel specific bindings.
Can the ThinkPad T14 ARM Snapdragon variant function without pain as a daily Linux/BSD driver?
Unlikely. I've been daily-driving the predecessor (X13s). While it's usable and technically all drivers are there, it's far from "without pain" due to endless number of small but annoying quirks. Just to give you an idea: boot fails 4 out of 5 times, external displays aren't recognized unless plugged in/out several times, sporadic resets during overnight sleep, etc. On top of that speakers will sound prohibitively ti…
What's that?
I'm not sure why the author didn't attempt to dive deeper into the error message he saw. amd_vcn_dec sounds like it's an issue with the GPU's video decoding logic. If there's a timeout when trying to process a decode request, it may be that power management for the GPU is buggy somehow. Given that this is a server build and idle power consumption is likely not a big deal, I'd suggest pinning the GPU power state to se…
I believe something I call "the window phenomenon" has occurred. Sometimes, life allows you have the time to do these big experiments on your life and then it gets busy again and you can't dive into it with the same capacity, so you have to do what you have to do while surviving what you have at hand. I have gone through many patches like this, and I believe he had to handle life while is experimental workstation had…
Exactly because the window of time I had for fooling with home networking had closed.
> there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64 All he had to do was build some packages from source, right? It's really worth learning how to do this, since it removes a lot of constraints. And the kernel patch should land in the kernel pretty soon, I hope? He won't have to run a patched kernel forever. Should be possible to get that in a release in a year or so?
I don't know if it's your intent, but that reads really condescending. It's obvious the author knows how to build packages from source. They're working professionally for a Linux distro on arch support! But that was several layers deep into yak shaving broken graphics, and at some point you need to actually get your real work done.
Earlier quoted context omitted.
> my major complaint is Device Tree sucks Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.
It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)
Oh, and an even more complex UEFI+ACPI solution won't be broken?