Originally posted by tjwhaynes
View Post
This is already the situation in other fields :
- scanners in SANE (for every stupid USB scanner manufacturer that isn't capable of making a standard class-compliant device. You used to need a separate reverse engineered kernel driver - which is something hard to keep maintained in mainline due to the obscurity of such hardware. At some more or less recent point of time, SANE switched to using libusb and maintain their own set of drivers in user-land. Given the obscurity of all the concerned scanners, it's really making sense.)
- other types of sound devices in pulse audio : if it's not a standard ISA, PCI/PCIe, or USB Audio-class device, it's not handled by ALSA kernel drivers. So instead pulse-audio handles it directly (example: talking with A2DP Speakers over bluetooth using standard BT channels/sockets, talking with dedicated studio audio equipement over FireWire using libieee, etc.)
(there are even a few HID diveces handled this way: the Logitech forcefeed-back mouse, and eMagine's 3D Visor VR googles have libusb drivers. No way to put such one-of-a-kind old junk into mainline).
But I am afraid that game developers are going to go the "roll-your-own" route, on the reasoning that they can share code with their similar "roll-your-own" support on Windows. So you'll end-up with tons of buggy unmaintainable closed-source code spread across games, each employing their own single use "Bongo"-controller or Toy-robot controller (winks to Nintendo).
Leave a comment: