this post was submitted on 12 May 2025
116 points (99.2% liked)
Linux Gaming
18627 readers
464 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME
away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
Resources
WWW:
Discord:
IRC:
Matrix:
Telegram:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So, Don't hate me for this, but I have to ask what is potentially a stupid question.
Why does this have to be done? why does each individual controller need support programmed into the kernal?
Why isnt there just some generic controller library that just lets any and every controller work without anything special?
short answer: There is generic support already in the kernel. It's up to the game controller MFG to use that standard. Also, the generic controller standard probably doesn't support a lot of the new features, so it makes sense to have a driver to support the extra features of the controller.
longer answer is way too long.
But why is it in the kernel?
Because Linux is a monolithic kernel. What that means, essentially, is that it contains all the drivers and everything else, unlike windows which uses a microkernel. The advantages of a monolithic kernel are, for instance, that you don't need to install drivers manually, and you don't have to depend on potentially malicious websites to host those drivers. Additionally, if any kernel ABI changes for one reason or the other, say there is a refactor to fix a vulnerability, whoever does the refactor would also refactor the driver code because that is in the kernel, and the kernel won't compile if there's an error in the drivers. This way, the driver is always updated, and you don't have a situation where you have really old drivers that no longer work.
The disadvantage of a monolithic kernel is that there's a lot more code that you have to take care of, and the kernel has a lot more responsibilities as opposed to a microkernel.
It's not in the kernel. It just comes a long with the kernel. You can compile any of the drivers as modules. Back in the day when you had to fit your kernel and boot loader on a 1.44MB floppy. We would save space by compiling most of the drivers as modules and then they would get loaded into kernel space on boot. Now a days, a 100MB kernel is not a big deal when systems have Gigs of ram and harddrives are in the Terabytes. They keep the driver code with the kernel code mostly for the reasons that @dafta gave. When I was a Windows kernel dev for Intel, Microsoft did the same thing. That's how you get inbox drivers. As a Windows kernel dev for Intel, it was our goal to get our drivers inbox'd with Microsoft so their developers would be responsible for maintaining the driver code, as well as testing, when ever there were changes to the Kernel that affected drivers.