4 ms·

100% agree with you. Qualcomm historically wrote awful OSS code that couldn't be upstreamed because it barely worked on a subset of their own SoCs, and broke b

100% agree with you. Qualcomm historically wrote awful OSS code that couldn't be upstreamed because it barely worked on a subset of their own SoCs, and broke basic function for everything else. Typically featuring incredibly invasive architectural changes that patched far too many layers of the OS with unmaintainable code. QC then converted bad code into a business model, nickel and diming OEMs who needed bugs fixed to ship their products. The idea that QC SoCs now have good upstream support is bizarre to me. At best, it means a few high volume SoCs can boot to console on reference designs. Forget about peripheral support for things anyone would take for granted, like audio and GPU.

zozbot234 3y ago
Every mainline-supported device starts out as "booting to console". GPU support on ARM SoC's is currently achieved through a variety of community-developed drivers, such as lima and panfrost. That part at least is comparatively well-understood. The manufacturer does not directly support these community drivers, so it's not very clear how much Qualcomm could help there.
- protastus 3y ago
  There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries. A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL. There's a similar story here for every subsystem driver, where they insist on a brittle proprietary solutions (one branch for every chip!) that can't be upstreamed.
  - zozbot234 3y ago
    But Qualcomm does not currently support freedreno, it's purely a community effort. It's not Qualcomm's job to bring it to feature parity with their proprietary drivers, so the proposal to have their libraries talk to it by default is just not very sensible.
    - seba_dos1 3y ago
      > It's not Qualcomm's job It should be if they're really serious about software support.
    - protastus 3y ago
      You claimed it wasn't clear how Qualcomm could help. I pointed out how they could help. There's precedent too, with ARM supporting panfrost. QC is not a low level employee lacking agency over their job description. They're a business that is free to set their strategy in response to risk and competition. The less that QC upstreams, the more risk they incur, especially with tightening security scrutiny (e.g. 2021 Cyber EO requirements). QC can also get disrupted by Mediatek doing a better job with Linux.

zozbot234 3y ago

Every mainline-supported device starts out as "booting to console". GPU support on ARM SoC's is currently achieved through a variety of community-developed drivers, such as lima and panfrost. That part at least is comparatively well-understood. The manufacturer does not directly support these community drivers, so it's not very clear how much Qualcomm could help there.

protastus 3y ago
There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries. A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL. There's a similar story here for every subsystem driver, where they insist on a brittle proprietary solutions (one branch for every chip!) that can't be upstreamed.
- zozbot234 3y ago
  But Qualcomm does not currently support freedreno, it's purely a community effort. It's not Qualcomm's job to bring it to feature parity with their proprietary drivers, so the proposal to have their libraries talk to it by default is just not very sensible.
  - seba_dos1 3y ago
    > It's not Qualcomm's job It should be if they're really serious about software support.
  - protastus 3y ago
    You claimed it wasn't clear how Qualcomm could help. I pointed out how they could help. There's precedent too, with ARM supporting panfrost. QC is not a low level employee lacking agency over their job description. They're a business that is free to set their strategy in response to risk and competition. The less that QC upstreams, the more risk they incur, especially with tightening security scrutiny (e.g. 2021 Cyber EO requirements). QC can also get disrupted by Mediatek doing a better job with Linux.