5 ms·

Nice project! Initial thought: apart from ease of development, is there any reason to do it in user space? I looked into uinput before to get a Bluetooth mfi co

Nice project! Initial thought: apart from ease of development, is there any reason to do it in user space? I looked into uinput before to get a Bluetooth mfi controller working, but couldn't figure out which modules of the kernel did what.

chewzerita 7y ago
Not OP, but there is a history of writing game controller drivers for linux: https://github.com/chrippa/ds4drv https://github.com/chrippa/ds4drv https://xboxdrv.gitlab.io/ https://xboxdrv.gitlab.io/ https://github.com/kozec/sc-controller https://github.com/kozec/sc-controller I recently bought myself a dualshock4 for use with Kodi and RetroArch. No driver was needed, even for bluetooth! Edit: formatting
fulafel 7y ago
It's this is the major factor limiting driver development on Linux, so it hardly needs another reason. But security is another thing that userspace implementation can do better on, no idea about this case specifically.
loeg 7y ago
Until performance is an obstacle, writing drivers in user space first is all benefit. Quick prototyping, crashes don't bring down the system, choice of programming language, etc, etc.
Medusalix 7y ago
One of the major points for me was how cumbersome the installation process for kernel modules is. Now I can just do make install which works on most Linux distributions.
- chupasaurus 7y ago
  DKMS is the only way to do it without losing sanity.
  - rubicks 7y ago
    Tell that to a friend that runs secure boot enabled.
    - chupasaurus 7y ago
      You can add a step to DKMS build scripts for signing the modules.
- MayeulC 7y ago
  Eeh, I never do a make install from the projects I download TBH, as the resulting files aren't tracked by the package manager. A kernel module is just a matter of compiling and running `insmod` (or placing it in the correct path). You have to recompile it each time you upgrade your kernel, though. But seriously, the proper way to do it is a kernel module which you then mainline. I wouldn't be surprised if Valve was to pick it up, since they mainlined some xpad improvements (and the wired version of those controllers)
Const-me 7y ago
Ease of development is underestimation. I’ve built a few user space Linux drivers for SPI and USB devices. Was easy, I have consumed stable APIs exposed by usbdevfs, libudev, and a few others. No need to recompile OS kernel. Because Linux kernel API is stable, not only OS kernel upgrades don’t break my stuff, they don’t even require me to recompile my code. Creating a kernel mode Linux driver is much harder in comparison. Merging a driver into the mainline Linux is borderline impossible. Even Google with all their corporate resources and platinum membership of Linux foundation was unable to do so, instead they are supporting many thousands lines of patches: https://source.android.com/devices/architecture/kernel/android-common https://source.android.com/devices/architecture/kernel/andro... It’s safe to assume you won’t be able to push your custom driver either. You’ll have to do it the same way as everyone else — patch locally. This is not trivial either, but this time the challenge is technical, not political, as Linux kernel doesn’t have stable API nor ABI: https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst https://github.com/torvalds/linux/blob/master/Documentation/...
- baruch 7y ago
  It's quite the opposite actually, a large company usually expected others to bend to its will and is not that interested in hearing opposed views and change their approach and that's what makes getting coffee into the kernel harder. I've got code in the kernel and it wasn't easy but that code lives on well beyond my contribution so it has to be in a design and implementation that can and will be maintained by others.

chewzerita 7y ago

Not OP, but there is a history of writing game controller drivers for linux: https://github.com/chrippa/ds4drv https://github.com/chrippa/ds4drv https://xboxdrv.gitlab.io/ https://xboxdrv.gitlab.io/ https://github.com/kozec/sc-controller https://github.com/kozec/sc-controller I recently bought myself a dualshock4 for use with Kodi and RetroArch. No driver was needed, even for bluetooth! Edit: formatting

fulafel 7y ago

It's this is the major factor limiting driver development on Linux, so it hardly needs another reason. But security is another thing that userspace implementation can do better on, no idea about this case specifically.

loeg 7y ago

Until performance is an obstacle, writing drivers in user space first is all benefit. Quick prototyping, crashes don't bring down the system, choice of programming language, etc, etc.

Medusalix 7y ago

One of the major points for me was how cumbersome the installation process for kernel modules is. Now I can just do make install which works on most Linux distributions.

chupasaurus 7y ago
DKMS is the only way to do it without losing sanity.
- rubicks 7y ago
  Tell that to a friend that runs secure boot enabled.
  - chupasaurus 7y ago
    You can add a step to DKMS build scripts for signing the modules.
MayeulC 7y ago
Eeh, I never do a make install from the projects I download TBH, as the resulting files aren't tracked by the package manager. A kernel module is just a matter of compiling and running `insmod` (or placing it in the correct path). You have to recompile it each time you upgrade your kernel, though. But seriously, the proper way to do it is a kernel module which you then mainline. I wouldn't be surprised if Valve was to pick it up, since they mainlined some xpad improvements (and the wired version of those controllers)

Const-me 7y ago

Ease of development is underestimation. I’ve built a few user space Linux drivers for SPI and USB devices. Was easy, I have consumed stable APIs exposed by usbdevfs, libudev, and a few others. No need to recompile OS kernel. Because Linux kernel API is stable, not only OS kernel upgrades don’t break my stuff, they don’t even require me to recompile my code. Creating a kernel mode Linux driver is much harder in comparison. Merging a driver into the mainline Linux is borderline impossible. Even Google with all their corporate resources and platinum membership of Linux foundation was unable to do so, instead they are supporting many thousands lines of patches: https://source.android.com/devices/architecture/kernel/android-common https://source.android.com/devices/architecture/kernel/andro... It’s safe to assume you won’t be able to push your custom driver either. You’ll have to do it the same way as everyone else — patch locally. This is not trivial either, but this time the challenge is technical, not political, as Linux kernel doesn’t have stable API nor ABI: https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst https://github.com/torvalds/linux/blob/master/Documentation/...

baruch 7y ago
It's quite the opposite actually, a large company usually expected others to bend to its will and is not that interested in hearing opposed views and change their approach and that's what makes getting coffee into the kernel harder. I've got code in the kernel and it wasn't easy but that code lives on well beyond my contribution so it has to be in a design and implementation that can and will be maintained by others.