Open source Mali GPU drivers merged(lkml.org)
lkml.org
Open source Mali GPU drivers merged
https://lkml.org/lkml/2019/5/8/1122
14 comments
Lots of SoCs on low cost hobbyist SBCs use Mali GPUs, including those made by Allwinner and Rockchip. In particular the RK3399, which IMO is the best value SoC at the moment with a really decent SBC selection (and the upcoming pinebook pro!). Panfrost is icing on the cake and extremely welcomed.
RockPro64 and the Pinebook Pro will benefit from the Panfost drivers. Not sure if anyone has Wayland working on them, but I am optimistic based on the existing progress.
I believe lots of things based on allwinner are potentially affected here. Orangepi and bananapi for example.
It may be relevant for stuff like LineageOS.
From the top of my head, there's the ones based on Allwinner SoCs, which by now have decent mainline support[0], such as the cubieboard line and the pine64.
[0] https://linux-sunxi.org/Linux_mainlining_effort
[0] https://linux-sunxi.org/Linux_mainlining_effort
Handy for a lot of the Rockchip boards which are now pretty much completely sorted with mainline kernels. RK3399 boards in particular are capable and interesting.
Asus TinkerBoard is based on this SoC: https://en.wikipedia.org/wiki/Rockchip_RK3288
There's a Chromebook, the Asus C201 that will benefit from this. I'm currently running PrawnOS (Debian-based) on it. Wrote a bit about that on reddit: https://old.reddit.com/r/linux/comments/bebm93/linux_on_asus...
Basically this DRM driver plus the companion Panfrost Gallium3D driver merged into mesa 19.1 will enable blob-free 3D graphics on the C201 and other devices that use this chipset.
Right now the DRM kernel driver does not support X11, so it'll be a few more releases before I can really take advantage of it. I have successfully installed it along with and run the kmscube demo outside of X. Pretty exciting development.
With Panfrost, every component of the C201 except the BCM4354 WiFi chip becomes libre. Cypress bought out a division of Broadcom and started releasing datasheets on a bunch of WiFi chips including the BCM4354, which they now tag as CYW4354. (PDF: https://www.cypress.com/file/298141/download)
Not sure if that makes it easier or any more realistic to get blob-free firmware for this chip. I can only hope.
Basically this DRM driver plus the companion Panfrost Gallium3D driver merged into mesa 19.1 will enable blob-free 3D graphics on the C201 and other devices that use this chipset.
Right now the DRM kernel driver does not support X11, so it'll be a few more releases before I can really take advantage of it. I have successfully installed it along with and run the kmscube demo outside of X. Pretty exciting development.
With Panfrost, every component of the C201 except the BCM4354 WiFi chip becomes libre. Cypress bought out a division of Broadcom and started releasing datasheets on a bunch of WiFi chips including the BCM4354, which they now tag as CYW4354. (PDF: https://www.cypress.com/file/298141/download)
Not sure if that makes it easier or any more realistic to get blob-free firmware for this chip. I can only hope.
Indeed. This machine is truly unique in the sense that it can be run with no binary blobs. To achieve this one had to disable GPU and WiFi (and use e.g. an Atheros adapter).
Now GPU acceleration will be achievable via open source.
Now GPU acceleration will be achievable via open source.
Does the new DRM driver currently work with Wayland compositors? I know Alyssa has demonstrated Weston on Panfrost, but that might've been with ARM's kernel driver or something
Yup, it supports Weston. Possibly more as it does say it supports some Wayland compositors, but only mentions Weston in the example:
https://panfrost.freedesktop.org/building-panfrost-mesa.html
It's broken at present, due to exposing BUFFER_AGE which isn't properly implemented. Should be fixed in mesa 19.2.
Oh, good to know. Thanks for sharing that info!
Zynq Ultrascale+, a family of hybrid CPU+FPGA SOC's uses Mali 400 in some models.
I was just experimenting with the lima driver on a pinebook last week, it works pretty well!
Search for Orange Pi, Banana Pi, Pine64 and FriendlyElec. These companies offer a wide range of $10-$30 dollar single board computers based on Allwinner or Rockchip SOCs (most of which include a Mali GPU).
You can run ARM based Linux distros on them (such as Armbian). Up to now, most people use the ARM proprietary blobs to get OpenGL ES acceleration working on those things.
You can run ARM based Linux distros on them (such as Armbian). Up to now, most people use the ARM proprietary blobs to get OpenGL ES acceleration working on those things.
The fact that ARM has not made their Mali drivers open source is a joke. There's no excuse, same for Nvidia.
It's arguable in the case of ARM/Mali but sadly, there is for NVidia.
Their driver are not merely to "communicate" with the hardware. The driver include a lot of hotfix and optimization, sometimes specific to one game/application. The driver give them a competitive advantage over their competitor. They will probably never released it for free.
Their driver are not merely to "communicate" with the hardware. The driver include a lot of hotfix and optimization, sometimes specific to one game/application. The driver give them a competitive advantage over their competitor. They will probably never released it for free.
They could do the same thing AMD did, which is keep their game/application API optimizations secret within a proprietary userspace stack, but also make it work with the open source Mesa/Gallium3d stack. Leave the OpenGL/Vulkan software development part to software developers (or keep doing it yourself if you think it's that important), but at least tell us how to drive your hardware.
Interestingly, amdgpu/Mesa performance seems to be higher for typical game rendering than AMD's proprietary stack. I suspect at some point in the future AMD will abandon their 'pro' proprietary stack entirely after realizing they should stick to being a hardware business.
Interestingly, amdgpu/Mesa performance seems to be higher for typical game rendering than AMD's proprietary stack. I suspect at some point in the future AMD will abandon their 'pro' proprietary stack entirely after realizing they should stick to being a hardware business.
> I suspect at some point in the future AMD will abandon their 'pro' proprietary stack entirely after realizing they should stick to being a hardware business.
John Bridgman of AMD confirmed it's their plan like 5+ years ago. The only reason they ever maintained proprietary stack on Linux is workstation users who need certified OpenGL implementation for various proprietary software.
By now the only proprietary parts of "pro" stack are OpenGL implementation and shader compiler for Vulkan / OpenCL. Everything else in "pro" package is open source already. There is still legacy OpenCL implementation, but I guess ROCm will be used for everything soon.
John Bridgman of AMD confirmed it's their plan like 5+ years ago. The only reason they ever maintained proprietary stack on Linux is workstation users who need certified OpenGL implementation for various proprietary software.
By now the only proprietary parts of "pro" stack are OpenGL implementation and shader compiler for Vulkan / OpenCL. Everything else in "pro" package is open source already. There is still legacy OpenCL implementation, but I guess ROCm will be used for everything soon.
I whish they would go the same way that AMD did, but I doubt we will see it any time soon. The thing is, AMD/ATI lost the software war against NVidia for quite a while now. AMD didn't have much to lose by open-sourcing their driver. And the AMD proprietary driver on Linux where always a mess, whereas NVidia at least "work" (even though they just refuse to play well with the linux env...).
Now, with NVidia diving more and more into the ML / GPGPU market (which is less windows-focused), they might have more pressure to actually open-source their driver (or at least, finally make them actually integrated properly with Linux), at least for their server focused hardware. But I wouldn't bet on it any time soon.
Let's be honest, they have a dominant position on the market. And their driver, as awful as they are, work. I think a lot of things would have to change for them to have the incentive to open-source them. My only hope at this point is that, with the growing GPGPU market, they might finally start to see Linux not as a second-class citizen.
Now, with NVidia diving more and more into the ML / GPGPU market (which is less windows-focused), they might have more pressure to actually open-source their driver (or at least, finally make them actually integrated properly with Linux), at least for their server focused hardware. But I wouldn't bet on it any time soon.
Let's be honest, they have a dominant position on the market. And their driver, as awful as they are, work. I think a lot of things would have to change for them to have the incentive to open-source them. My only hope at this point is that, with the growing GPGPU market, they might finally start to see Linux not as a second-class citizen.
This is most likely due to ARMs IP-licensing scheme relying on charging customers for the hardware IP and then again charging them for the drivers that they are going to need. As far as the rumors go, they used to charge customers a 3rd time if they wanted OpenCL support.
Strictly speaking the kernel drivers for the ARM Malis are all open-source and GPL licensed (they need to be, since their customers want to ship Linux to consumers).
They are also entirely useless without the userland software that is doing all the actual work. The kernel drivers are just glorified task and memory managers.
They are also entirely useless without the userland software that is doing all the actual work. The kernel drivers are just glorified task and memory managers.
It would be nice if they had been dual-licenced like the radeon, intel and nouveau kernel drivers.
I thought that the Lima and Panfrost projects included an open-source userland component too.
I thought that the Lima and Panfrost projects included an open-source userland component too.
They do, the userland part is in Mesa:
https://gitlab.freedesktop.org/mesa/mesa
https://gitlab.freedesktop.org/mesa/mesa
While the kernel driver is Open Source, they have decided to implement a driver that can _never_ be submitted upstream for Kernel inclusion.
Could you expand on this? I don't follow kernel development closely. Why can't it be upstreamed? Is there something the community can do to modify their code for inclusion?
The DRM subsystem where the graphics drivers live in Linux has a strict open source userland policy - every new kernel interface needs a corresponding real userland implementation that exercises it. So a graphics driver that is only used by a closed source userland blob has no chance of being upstreamed.
And of course just generally vendor kernel code tends to have superfluous middle layers or abuse kernel interfaces in unintended ways.
And of course just generally vendor kernel code tends to have superfluous middle layers or abuse kernel interfaces in unintended ways.
There's basically no chance that the current proprietary drivers will ever end up upstream, so if ARM / nvidia drivers were open source they would be out of tree.
Given that the most frequently cited reason that these drivers should be open source is improved user experience (less breakage when the kernel changes, easier install), what would be the advantage of an out of tree open source driver?
Given that the most frequently cited reason that these drivers should be open source is improved user experience (less breakage when the kernel changes, easier install), what would be the advantage of an out of tree open source driver?
What is their reasoning?
I don't work for ARM Holdings, so I don't know.
However, my experience in the hardware industry leads me to believe it's something about an 'intellectual property' fetish and pearl-clutching when confronted with the idea of 'giving away code for free'.
However, my experience in the hardware industry leads me to believe it's something about an 'intellectual property' fetish and pearl-clutching when confronted with the idea of 'giving away code for free'.
As someone who has worked on a chip design team and had to deal with this stuff... one of the biggest reasons is patents -- software patents. They can't sue you if they can't see what you're doing. There are lots of dumb software patents out there. AMD did get hit with a couple of those, but we were able to beat them because the order of operation didn't exactly match the claims in the patent.
Often it's a mess of third party proprietary dependencies, code owned by subcontractors, etc.
e.g. when AMD open sourced AMDVLK, they had to replace the proprietary compiler it was depending on with LLVM. That was an easy one. Many projects are much more deeply intertwined with proprietary crap.
e.g. when AMD open sourced AMDVLK, they had to replace the proprietary compiler it was depending on with LLVM. That was an easy one. Many projects are much more deeply intertwined with proprietary crap.
Usually the code is not important, just the specification. Data sheets and explanations of how the hardware acts will do, they can keep their secret code.
I forget where I read this, but I recall that due to patent situation it's practically impossible to build a GPU without infringing on some patent or another. By keeping drivers closed source it's possible to maintain deniability- if ARM released open source GPU drivers it would be trivial for rights-holders to look at the implementation and see what they can sue for. It's not impossible to do this with blob drivers, but harder.
Nvidia's closed source kernel driver (and others) might be found illegal in court if a Linux rights holder bothered to sue. But unfortunately there is no one interested and rich enough to do it.
I don't buy this. See: AMD and Intel both have open source drivers.
I'm not sure what there is to buy. Just because AMD or Intel managed to do this doesn't mean it's any easier or cheaper for nVidia or Arm. AMD actually has been sued before over this kind of thing. Why not just save yourself the trouble and effort of making an entirely legal and safe open source implementation when you can just keep trucking with closed source?
Maybe they are the aforementioned rights-holders :)
[deleted]
I'm not sure these exact GPUs are supported yet, but this sounds like good news for mainline Linux on Samsung smartphone hardware:
https://wiki.postmarketos.org/index.php?search=mali&title=Sp...
Note that most flagship Samsung phones have US variants based on a Qualcomm Snapdragon SoC (Adreno GPU) instead of an Exynos. This seems to be for US-specific reasons related to a legal battle between Samsung and Qualcomm rather than being driven by technology requirements.
Thank you, this confusion between very different International and US/NA versions with the same marketing name has been a headache for open source projects. You wouldn't believe how much trouble I had sourcing a few International version S3, from US eBay (claims of an item being the GT-i9300 model number for the International version were usually wrong).
Does this support hardware video encoding (h264)? There are a lot of SBCs with Mali GPUs that could use video encoding support.
H.264 and H.265 decoding is handled by the VPU, and there was already a successful kickstarter to add mainline support for that: https://www.kickstarter.com/projects/bootlin/allwinner-vpu-s...
Ditto for the HDMI PHY, you can spin up Xorg with a fully libre stack on nearly any of the Allwinner boards from OrangePi, FriendlyARM, etc. The Mali GPU is really only useful for OpenGL ES (aka video games).
Ditto for the HDMI PHY, you can spin up Xorg with a fully libre stack on nearly any of the Allwinner boards from OrangePi, FriendlyARM, etc. The Mali GPU is really only useful for OpenGL ES (aka video games).
Generally the SoCs used will have a separate video encoder IP-block that's not part of the Mali GPU. For example the "Cedar" video engine on Allwinner SoCs, Rockchip's VPU, Samsung's Multi-Function Codec, Qualcomm's Venus.
What license? Are they, like the intel and radeon gpu drivers, importable into OpenBSD/FreeBSD?
FreeBSD does not import GPU drivers into base, they're now packaged and under the GPL (they depend on some GPL code imported from Linux).
The "fun" part with these drivers is FDT attachment, but work is ongoing in FreeBSD on this.
The "fun" part with these drivers is FDT attachment, but work is ongoing in FreeBSD on this.
That's the current situation - but the drivers themselves are mostly free of GPL; the GPL-derived parts in linuxkpi can be (and eventually will) be rewritten to make them BSD-licensed, and that would make it possible to go back to importing GPU drivers into base, if the DRM developers wish so.
This should help a bit with the wave of new Pi-based emulation boards that are being used.
Won't affect any raspberry pi based systems. the Broadcom chip there isn't Mali based. For that you need a VC4/V3D chip driver, but that's also being developed. https://anholt.github.io/twivc4/2018/10/30/twiv/
Well, the VC4/V3D was maintained until recently. Broadcom is no longer employing anyone to develop it.
There are many more '* Pi' boards than just Raspberry Pi. A lot (most) of them have ARM GPU.
Yeah and they were useless because they didn't have GPU drivers. Now the situation has reversed and the Raspberry Pi is now the board that is most dependent on proprietary software.
Actually not true, even without GPU support all the ones I have (4 different SoCs - H3,H5,H6,A83T) are noticeably faster than Rpi 2 for things like browsing the web. (H5/H6 a bit unfair, since it's A53 CPU)
And desktop use is not the only thing you can do with these boards, and pretty much any of them is better than Rpi on connectivity, which is what matters for other use cases.
And desktop use is not the only thing you can do with these boards, and pretty much any of them is better than Rpi on connectivity, which is what matters for other use cases.
Frankly I am surprised they have not been hit with a trademark dispute.
On what basis? Raspberry Pi is a trademark only in combination of these words, no?
https://www.raspberrypi.org/trademark-rules/
And competition is good.
https://www.raspberrypi.org/trademark-rules/
And competition is good.
Competition is definitely good. But the trademark issue is much more complicated than just the exact words/phrasing. It could be argued that they're using $FRUIT Pi to appear to be associated with the original Raspberry Pi (and I'd say that argument is correct, there's very little other reason to pick that same naming scheme). That doesn't mean that it's certainly a trademark infringement issue either though. In the US at least (no idea about the UK where the RPi is from), there's also a requirement that they're trying to confuse the market at the same time, which isn't so obvious.
Trademarks are complicated things mostly created by lawyers who have spent centuries building through loopholes and attempting to fix them. I'd say they serve a real useful purpose and are relatively well balanced against the interests of the populous (once you stop using one, you usually lose it). But they're by no means simple.
Trademarks are complicated things mostly created by lawyers who have spent centuries building through loopholes and attempting to fix them. I'd say they serve a real useful purpose and are relatively well balanced against the interests of the populous (once you stop using one, you usually lose it). But they're by no means simple.
Do any of the Mali GPUs support GPGPU (e.g. OpenCL), and are those drivers being open sourced? In fact, if I wanted to do GPGPU on something like a Raspberry Pi, what are the best options currently (open source drivers or not)?
The ARM Mali T-series and G-series of GPUs do support compute (OpenCL), the drivers are a different story.
Let's just start out by saying that the GPU designer, ARM, does not support the Open Source driver. Most likely due to their IP-licensing scheme relying on charging customers for the hardware IP and then again charging them for the drivers that they are going to need. Previously the rumors went that they charged customers a 3rd time if they wanted OpenCL support. This is part of the reason why OpenCL on mobile is dead.
As for actual OpenCL support for Mali GPUs using the Open Source stack, work is progressing, but we (the Mesa & Clover) project aren't there yet.
Regarding the RPi, I don't think it has ever had OpenCL support. Proprietary or otherwise. About the RPi, Broadcom (the SOC designer) recently lost their very talented GPU driver engineer, due to not being serious enough about pushing the Open Source driver forward.
To answer your question about OpenCL on the RPi in practical terms, it's not possible to use the GPU. But you can use POCL for CPU-backed OpenCL support.
Let's just start out by saying that the GPU designer, ARM, does not support the Open Source driver. Most likely due to their IP-licensing scheme relying on charging customers for the hardware IP and then again charging them for the drivers that they are going to need. Previously the rumors went that they charged customers a 3rd time if they wanted OpenCL support. This is part of the reason why OpenCL on mobile is dead.
As for actual OpenCL support for Mali GPUs using the Open Source stack, work is progressing, but we (the Mesa & Clover) project aren't there yet.
Regarding the RPi, I don't think it has ever had OpenCL support. Proprietary or otherwise. About the RPi, Broadcom (the SOC designer) recently lost their very talented GPU driver engineer, due to not being serious enough about pushing the Open Source driver forward.
To answer your question about OpenCL on the RPi in practical terms, it's not possible to use the GPU. But you can use POCL for CPU-backed OpenCL support.
Thanks for the detailed comment! Regarding OpenCL on RPi, what about something like this: https://hackaday.com/2019/01/24/running-opencl-on-a-raspberr...
Do you think it could support ML training/inference on a Pi GPU (albeit very slowly obviously), or even OpenCV?
Sorry, I'm not familiar enough with ML/OpenCV but I would think that GPU acceleration of it on the RPi is a tall ask.
i hear the armbian team cheering from all the way over here.
I don't know much about ARM SoC ecosystems for Linux, but am I correct if I take this as a direct ARM Mali version of Nouveau, or it's slightly different?
I'm very surprised that ARM, the company that should provide proper software references for its ecosystem, is not open source friendly.
I'm very surprised that ARM, the company that should provide proper software references for its ecosystem, is not open source friendly.
There is no actual ARM platform, like in the case of a PC. (Intel x86/64 is not a platform. You can find an x86 compatible chip in a PS4, but it's missing all of the critical components that let it boot like a PC. See the Fail0ver video on PS4 kernel hacking for more info).
ARM chips are just System-on-Chips with random pins soldered to random shit and broken, non-upstreamable kernels that are only released after a phone has been out for like 6 months.
It's a shit system for any type of truly open development:
https://penguindreams.org/blog/android-fragmentation/
ARM chips are just System-on-Chips with random pins soldered to random shit and broken, non-upstreamable kernels that are only released after a phone has been out for like 6 months.
It's a shit system for any type of truly open development:
https://penguindreams.org/blog/android-fragmentation/
This is actually useful though - it's not a full equivalent of Noveau because it doesn't include video output support of any kind and that tends to be vendor-specific hardware, but people have already got the necessary video out support for a bunch of cheap hardware with ARM Mali GPUs into mainline Linux and this was the missing link for full accelerated graphics support.
Will this improve performance on the Pinebook?
Hopefully this gets us closer to better-than-OpenGL-ES support on the Gemini PDA which has an 8xx.
Are any odroid SBCs affected?
I would say C1/C2 (Mali-450) and maybe XU4 (Mali-t628).
⠀
You got it wrong. It isn't ARM's module that was merged into the kernel, it is a complete reverse engineered Gallium based driver made by third party volunteers.
This driver offers full OpenGL acceleration and does not depend on the ARM's propriety blobs. They re-created all the, as you call it, "interesting stuff" from the user space library.
Edit: I take back what I said, I misunderstood the comment. Indeed, the interesting stuff is in the userspace counter part of this kernel code.
This driver offers full OpenGL acceleration and does not depend on the ARM's propriety blobs. They re-created all the, as you call it, "interesting stuff" from the user space library.
Edit: I take back what I said, I misunderstood the comment. Indeed, the interesting stuff is in the userspace counter part of this kernel code.
⠀
I believe this is where the PP and GP compiler code lies:
https://gitlab.freedesktop.org/mesa/mesa/tree/master/src/gal...
Sorry, I had misunderstood you.
Interesting stuff in userspace? I thought drivers worked in kernel for performance reasons (part of why wireguard performs well). Any where I can learn more about what is in userspace and why?
I'm also curious, how does performance compare to the binary blob?
I'm also curious, how does performance compare to the binary blob?
Buffer management is in kernel space, but that's about all that happens in kernel space GPU-wise. Indeed, most interesting things happen in user space.
Most hardware doesn't have it's own MMU like most GPUs have had for over a decade. That lets GPUs run most of the data plane in user mode right next to the code calling into OpenGL/CUDA/Vulkan/etc.
[deleted]
It is much safer to put complex software into userspace. If there is an error, you won't get kernel panic.
Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software.
The same problem is with drivers. Maybe there is a way to allow drivers with closed source code and get better hardware support? For example, what about copying or supporting Android's driver model?
The same problem is with drivers. Maybe there is a way to allow drivers with closed source code and get better hardware support? For example, what about copying or supporting Android's driver model?
Linux is much more than general distros and closed source drivers are pain in the ass for everybody. Vendors should just mainline the support for their HW, especially if they benefit from Linux overall.
Maybe there is a way to run them safely. For example, have an open source part running in kernel, and closed source part that is properly isolated in userspace.
That's AMD's current model. There's both community open drivers and closed vendor drivers sharing an open and upstreamed kernel module.
There are a number of things that could be done to improve the experience with proprietary drivers, but all of them undermine the Linux driver philosophy. For the kernel community, any driver that is not mainlined is doing it wrong (and there are a number of compelling arguments behind this position), so the out of tree / proprietary driver experience is intentionally not improved.
Is this trolling or are you serious?
Proprietary drivers are shipped with many distributions. For example nvidia drivers are shipped with Ubuntu. If the repo drivers don't suit you, you can (just like on all other platforms) download drivers from the vendors website.
Proprietary drivers are allowed and are shipped in many distros (just like in Android), but they cannot be included in the kernel upstream (then they wouldn't be proprietary).
Every vendor is welcome and encouraged to submit their driver to the upstream linux kernel project. Some vendors do however chose not to do so, for a variety of terrible-to-mediocre reasons.
Proprietary drivers are shipped with many distributions. For example nvidia drivers are shipped with Ubuntu. If the repo drivers don't suit you, you can (just like on all other platforms) download drivers from the vendors website.
Proprietary drivers are allowed and are shipped in many distros (just like in Android), but they cannot be included in the kernel upstream (then they wouldn't be proprietary).
Every vendor is welcome and encouraged to submit their driver to the upstream linux kernel project. Some vendors do however chose not to do so, for a variety of terrible-to-mediocre reasons.
Welcomed and encouraged to submit their driver for consideration. I would guess that the vast majority of vendor-proprietary drivers would get rejected from upstream, so for most cases the viable options for vendors wishing have an driver in mainline are to improve an existing reverse-engineered driver or rewrite the driver to fit the kernel standards.
If they accounted for mainlining from the start and not just as an afterthought, they would not have this issue.
Getting your driver accepted upstream is a conversation with the maintainers of that kernel part.
You can't just throw a pile of code over the fence and assume it will be accepted.
When adding support for your device keep in mind that this is something everyone wants, maintainers/users/vendors alike.
You can't just throw a pile of code over the fence and assume it will be accepted.
When adding support for your device keep in mind that this is something everyone wants, maintainers/users/vendors alike.
> Before flatpack and snapcraft there was no sane way to install third-party software.
This is simply false, because AppDirs and AppImage existed long before those. And of course static binaries existed since the beginning. Sadly, Linux user space is such a horrific mess that none of those much simpler and saner solutions took off, so now we have to put up with non-portable garbage like Snap and Flatpak that are still tied to a repo model.
This is simply false, because AppDirs and AppImage existed long before those. And of course static binaries existed since the beginning. Sadly, Linux user space is such a horrific mess that none of those much simpler and saner solutions took off, so now we have to put up with non-portable garbage like Snap and Flatpak that are still tied to a repo model.
You can compile a static binary or distribute a private copy of libraries, but it doesn't get you integrated into the system. For example, your app will not be upgraded using a package manager.
And main reason for this is because package managers were not designed for third-party software. They were designed only to install software from a distribution and maybe from your private repositories.
That makes proprietary software "not welcome" in Linux distributions.
And main reason for this is because package managers were not designed for third-party software. They were designed only to install software from a distribution and maybe from your private repositories.
That makes proprietary software "not welcome" in Linux distributions.
> For example, your app will not be upgraded using a package manager.
Good. That means it won't break because someone arbitrarily changed an ABI.
> That makes proprietary software "not welcome" in Linux distributions.
No disagreement there.
Good. That means it won't break because someone arbitrarily changed an ABI.
> That makes proprietary software "not welcome" in Linux distributions.
No disagreement there.
Linux isn't supposed to be friendly to developers wanting to rob people of their rights.
But as a user, I want to be able to use proprietary applications in a safe way, so that they cannot steal my browser cookies or read my MAC address, or patch my kernel. So I would prefer that Linux distributions support proprietary apps like Android Open Source Project does, rather than tell me what I should use and what I shouldn't.
> Installing proprietary code requires adding proprietary repositories
How is this unexpected?
How is this unexpected?
This is not a sane way to install third-party software because by adding their repository, you allow them to "upgrade" and package in your system, including Linux kernel, bash, sshd. Is your system secure if companies like Microsoft, Sublime Text, Slack Inc have root access to it?
So you either give them root access or install and update software manually. Because package managers like apt do not have a sane method to install third-party proprietary software.
And even with open source software, it is a bad method. For example, a developer that provides a Debian repository with different versions of PHP, has overwriten openssl library for users of his repository despite it can break something else.
So there should be a safer way to install third-party software.
So you either give them root access or install and update software manually. Because package managers like apt do not have a sane method to install third-party proprietary software.
And even with open source software, it is a bad method. For example, a developer that provides a Debian repository with different versions of PHP, has overwriten openssl library for users of his repository despite it can break something else.
So there should be a safer way to install third-party software.
The message says there's two drivers:
"Lima covers the older t4xx and panfrost the newer 6xx/7xx series"
My perception is that Mali GPUs were just in Android phones where running where it's generally not possible to run a vanilla kernel or the bootloader is locked.
Any dev boards?