@blakeyrat said:
Because it's a gaming mouse.
BZZT -- the only protocol difference I'd expect between a fancy gaming mouse and a normal mouse is the request used to set up the DPI presets; things like macro buttons aren't an issue to handle in userland.
This really is a case like I mentioned where the secret sauce is in hardware -- read the USB HID class spec sometime, and think for a minute how much of the functionality of your RAT7, or my SideWinder X8, or any other gaming mouse you can think of requires commands above and beyond what HID defines.
@blakeyrat said:
It's also possible the "secret sauce" is just a fix for something in firmware.
Bugs suck, yes; but I don't get why a hack to workaround a firmware bug or chip erratum would be top secret stuff -- it's something that someone who
wants to make a driver for your device will deal with in any case.
@blakeyrat said:
Is it worth the money of crafting the driver? Is it worth the headaches? Is it worth the expensive salary for someone who knows the Linux environment well enough? Does it add-up?
If you can't tell there, I was speaking of hardware in general, not gaming mice.
@blakeyrat said:
they'd change the equation by making driver development and distribution super-easy.
I'd say it's easier to write
and distribute an out-of-tree Linux driver than it is a Windows driver -- it's certainly no harder than writing Windows drivers.
@blakeyrat said:
They'd remove the requirements for drivers to be part of the kernel project
Did you even read what I said about out-of-tree drivers? Nobody will shoot at you for distributing your driver out of tree!
@blakeyrat said:
They'd fix the driver ABI so once written, the driver doesn't have to be rewritten for a decade or longer.
If you aren't shipping a blob, this isn't a big deal: setting up your out-of-tree module to use
DKMS means you can just push a source package out to users and it'll get recompiled against the kernel whenever needed.
On the Windows side: there have been plenty of major driver-framework changes there too -- driver API/ABI stability in Windows isn't something I'd bet my company on, either!
And to top it off -- for the original topic (gaming mice), you don't need a kernel mode driver at all if all it does is send extra commands to the mouse to turn on/off specific stuff. This thing called libusb exists for a reason, you know...