On 05/02/2016 08:35 PM, Dmitry Torokhov wrote:
I am not sure that exposing ff-memless to userspace is a good idea.
It would prevent code-duplication, as something, that already exists, would be usable for user mode drivers.
Right now what we have is a supporting library for several kernel modules and there were considerations to change it to work differently.
But even then there would still be a need for support for input devices with just two rumble motors. I guess this is the most common case.
While developing my own uinput driver, I had a look at some different projects and all of them at least try to somehow limit the complexity of the existing API. Many of them doing it wrong as simulating all the events, ff-memless can do, on two motors isn't an easy task.
I'd rather userspace took care of handling dumb devices if t decided to handle device communication instead of leaving it to the kernel.
I considered that and I don't have any clue on how to port the ff-memless code to work in usermode. It uses too much kernel specific features.
The easiest way to extend the uinput API could be to introduce a new ioctl call to initialize a "memless" device. This way the uinput-module knows it has to use ff-memless for this device.
And to get the events back to usermode, the simplest way is to just pass the two motor values (both 16 bits) in the value field of an input event (32 bits). This doesn't need all the callback stuff and probably even is more robust (current API tends to create non-killable processes if the uinput daemon exits before the last application, using the device, exits).
I already have some test code running. So far I didn't try with real hardware, but my current results look promising.
Does your response mean, that there is no chance to get a patch for this accepted? If so, my only choice would be to ship this as patch with my own code, requiring the user to compile his own kernel.
Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
