Let’s start with my mistakes:

  • I haven’t followed LKML.
  • I assumed: Every ThinkPad has - overall - perfect Linux support, so this will as well.
  • I did look up support when purchasing but I was still not verifying on the LKML.
  • Edit: I trusted Qualcomm’s marketing

So, I wanted a ARM-Linux laptop so bad. I heared about the Lenovo ThinkPad X13s in 2023 and I looked at marketing promises and (rare!) takes on it. Then there was the opportunity to buy this laptop fir a good price with the entire stats I would require for my next 10+ years. So I bought it.

In order to bake Linux on it I had to read up upon many things - I run it daily but have to accept some downsizes.

Anyhow, I thought this title would be interessting regarding Lenovo’s and Qualcomm’s “success” on ARM so that others may be aware that I am looking daily for the LKML and my model SC8280XP.

There is ONE SINGLE CONTRIBUTOR (there were two; The other joined Lenovo) allowed to have “elected and requested” documents in order to aid support. Despite their intentions (QUALCOMM) to support Linux. And I furthermore assume it hasn’t have changed with the new Snapdragon X processors.

So, thanks to John Hovold and Linaro for doing an awesome job. I wish I could support you.

  • 7dev7random7@suppo.fiOP
    link
    fedilink
    arrow-up
    7
    arrow-down
    2
    ·
    2 days ago

    More insights I gained using this laptop (intended for the curious Linux enthusiast):

    • Kernel support for Audio and Screens is heavily dependend on user space: X.org and Wayland experience differs immensely. Even some udev-rules only work with certain compositors (and X11 feels like it is out of scope).
    • Debian lacks people contributing to the linux and linux-firmware package. The onboarding is quite steep due to a lack of alignment between code and documentation.
    • Developers if userspace programs react very fast to new requirements but they rely on upstreamed (to Debian’s kernel-team) kernel-config’s.
    • Prompting bugs to the kernel appears to be done through kernel contributors only: Users will prompt hindrances on IRC (via OTFC, #aarch64-laptops) prompting the contributor and they will verify and support before addressing issues.
    • There are archived advancements to the support which can’t be merged due to citation reasons and alignment with upstream can’t be done by the individual (there is a pareto-capable kernel for virtualization but within one week hunderts of commits need to get reviewed). This is impressive imo.