@sthalik:
How’s your ioctl API? Do you bound-check userland-passed pointers correctly? Is there a need for locking, and if so, do you follow kernel API?
As for xboxdrv, you missed the evdev interface. It’s confusingly both an XBox gamepad driver and a mapper for evdev, well, events. Try the latter to see how to do it in userspace.
I assume you can hide access through exclusivity level in xboxdrv. It’s possible to deny usage of the original device. If the game has hardcoded js0 input (doubtful!), try playing with udev for specifying which device should be named js0.
It’s not limited to usb, everything with evdev-compatible works.
Another problem is kernel ABI breakage, unless you want your code merged, you’ll struggle a lot, experience crashes, etc, as whoever’s in charge of the kernel’s subsystem breaks the API/ABI. Only userland API is stable.
Hi,
Yes, I do check parameter boundaries, and yes, I do use spinlocks / mutexes wherever is necessary, of course. I used joydev implementation (which I assume rock-solid) as a base for my module. I’m not saying I’m absolutely sure there is no bugs, but obviously if there are they will be fixed. If you are interested, check jsmapper_api.h file in src/linux/drivers/input folder.
With regards to API/ABI breakage…, well, shit happens. I’ve been developing software for more than 20 years now, in multiple platforms (including Windows, Linux and embedded devices), and I’ve had to deal with that multiple times. Sooner or later, a library or a framework or something you rely on decides to make a fundamental change, and you need to deal with it and adapt your code. Again, shit happens. As for Linux kernel, it’s a known fact that 3rd party drivers must deal with kernel modifications, and that kernel modules needs to be compiled against every specific kernel for it to load the module. Distros provide mechanisms to deal with that (akmod, etc…) so again, no big deal here.
Merge the code into the kernel will be fine, but I’m not sure this projects fits into the general kernel. A possibility would be to merge it with existing _joydev _module, thus adding device programming to standard Linux joystick API. Anyway, this is something to discuss
in the future, not now probably.
As a side note, quite recently I had to deal with an API change in the kernel, specifically the way in which char devices are registered, which got change in 3.8 version. I did have to adapt the code so it would compile against new kernels, while maintaining compatibility with old code but, again, it was no big deal.
And regarding xboxdrv: yes, I did read about the evdev interface, which I guess helps providing compatibility over any input device connected, but this doesn’t solve the (to me) fundamental problem of how to avoid the target game receiving original events from the device. Yes, you can mess with udev and so, but that renders things a little complicated.
The advantage of JSMapper is that the regular ‘js0’ joystick device will still be there, and the game will use it in a transparent way (JSMapper creates a different device the controlling API). It just won’t get the events that get filtered by JSMapper, instead it will receive keyboard events just as if it had been entered on the real keyboard.
Kind regards,
Eduard Huguet__