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.
WWW:
Discord:
IRC:
Matrix:
Telegram:
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?
It is all generic layers, the base USB stuff is called a "Human Interface Device", controllers/keyboards/mice/etc. all show up as a HID to the OS. But you need some way to standardise the input and map the device side events to the host side, so the OS will have a mapping layer above the base USB layer that turns a generic HID into a "controller device" that an app can use.
As you can see from the patch, that's all they're doing. They're adding the USB IDs of these controllers to the mapping layer so instead of being shown as a "Generic HID", they're shown as "Generic Xbox Controller". Doing so also means the controller layer can drive the devices specifically, e.g. xbox controllers need a special handshake to enable the xbox button, the base generic input layer doesn't need to know that stuff.
Ah, that clears it up. Thank you for taking the time out to educate a random idiot.
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?
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.
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.
Thank you for helping to clear that up.
HORI Drum controller
- PowerA Fusion Pro 4
- 8BitDo Ultimate 3-mode Controller
- Hyperkin DuchesS Xbox One controller
- PowerA MOGA XP-Ultra controller