A Set Of Obscure Drivers Out-Of-Tree Since Linux 2.x Will See Mainline For Linux 5.2

[wizard69]

Cool! Now we can keep score when it comes to the us (Linux) vs them wars!

[Gymnasiast]

Why can't drivers like these be flatpaked instead? It would eliminate bloat

Because Flatpak is for user-space applications. Since drivers need direct hardware access by definition, they have to live in the kernel. It should also be noted that stuff that lives in the kernel tree does not always end up in the kernel that your favourite Linux distribution provides, and that the kernel has a module system, which allows for loading/unloading drivers (and other kernel bits) on the fly. Both of these reduce the amount of needed resources to run the Linux kernel s lot.

(I figured I would answer this question properly, rather than just ridicule the user.)

[StandaSK]

(I figured I would answer this question properly, rather than just ridicule the user.)

I wish more people did the same :/
Thanks for your comment, I too didn't know there was such a module system in place

[schmidtbag]

If you think embedded devices run kernels even close to mainline I have news for you.

I never said or implied that... I'm well aware embedded devices don't run mainline kernels. But seeing as these drivers are being mainlined, that most likely suggests these drivers aren't specific to the embedded devices (at least not the software running directly on them).
That being said, my point is in a lot of such cases, companies are likely use Windows instead. I already know for a fact that many of these displays are, to some degree, controlled by Windows. So, maybe these drivers are offer Linux the same control that Windows does, and now they're mainlined. If that isn't the case, I really don't understand why mainline these ancient obscure drivers for embedded systems where nobody has the tools (or really, incentive) to flash a new disk image.

[starshipeleven]

But seeing as these drivers are being mainlined, that most likely suggests these drivers aren't specific to the embedded devices (at least not the software running directly on them).

Correct, they are drivers for the Daktronics PCI cards used to control these screens.

But even if they were specific, as long as the embedded device is still manufactured you can update the SDK to make firmware for it, so new products can have a better firmware.

maybe these drivers are offer Linux the same control that Windows does, and now they're mainlined.

It's a code drop from Daktronics themselves. Greg said he received this tarball from Matt which is a Daktronics employee, and that this is the initial stage of a bigger code drop. see the commit.

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=7dc7967fc39af81191558f63eeaf3d2b83899b1c

It seems Daktronics is stepping up their Linux game, which means their customers (system integrator companies that buy billboards and other stuff to make a bigger integrated system for their own customer) have started whining loudly about the crappy Linux drivers or ancient kernel versions supported.

[skeevy420]

I wish more people did the same :/
Thanks for your comment, I too didn't know there was such a module system in place

modprobe

Those live kernel patching systems from the other article basically diff one kernel's sources from the other and creates modules for what has changed. If it wasn't for a system like that a lot of things wouldn't be possible...we'd have needed to recompile the kernel to switch from radeon to amdgpu but modules allow both drivers to exist and be loaded when necessary for another example.

EDIT: If you're on Arch/Antergos/Manjaro and want to go down the rabbit hole...kernel modules & modprobed-db.

[bill_mcgonigle]

It's funny - I would have been a "Daktronics who?" until last week, when I drove under one on the Garden State Parkway. I had been meaning to look them up!