Re: How to properly extend uinput API

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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