Hi Manuel, On Sat, Apr 30, 2016 at 11:36:24AM +0200, Manuel Reimer wrote: > Hello, > > I'm currently trying to somehow get uinput connected with ff-memless. I am not sure that exposing ff-memless to userspace is a good idea. Right now what we have is a supporting library for several kernel modules and there were considerations to change it to work differently. I'd rather userspace took care of handling dumb devices if t decided to handle device communication instead of leaving it to the kernel. Thanks. > > My first try (which is some kind of hack which prevents API changes > and doesn't work at all) failed. Now my idea is to add some more > simple (and probably working) API for this. All, I need in the > "memless case", is some way to get two motor speeds sent to > usermode, which doesn't require all this callback stuff. > > There is a new API which, as far as I understand, is meant to be > easier extendable: > https://github.com/torvalds/linux/commit/052876f8e5 > > What I need is some way to pass an additional boolean to tell the > kernel module that usermode wants to use ff-memless. Device setup is > done with an struct "uinput_setup". As far as I know it isn't easily > possible to extend this without breaking existing stuff. > > It would be possible to write some hack which passes this > information via magic-value through ff_effects_max but I think there > has to be some nicer way. > > So how to pass one more piece of information from usermode to kernel > module while setup without breaking existing (probably > closed-source) stuff? Keep a definition of the old struct version > and decide which one to use based on size? > > Thank you very much in advance for any help. > > Manuel -- Dmitry -- 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