On Wed, 2 Mar 2011 15:13:05 +0100 "Henrik Rydberg" <rydberg@xxxxxxxxxxx> wrote: > Hi Alan, > > > Implement an events per packet interface configuration. We do this by > > adding a new ioctl that must be called before creation and follows the > > pattern of the existing API. > > > > The behaviour is: > > Not set: input default or value computed by the uinput driver > > Set: value used in preference if larger than computed > > value > > > > Signed-off-by: Alan Cox <alan@xxxxxxxxxxxxxxx> > > --- > > I agree that adding this ioctl is symmetrical from the a device > emulation standpoint, but I was imagining eventually replacing the eep > with an automatic scheme, or at least with a more realtime-oriented > parameter. Fixating the interface as you propose will make such a > transition much harder. This is something we actually need rather than are having future visions about, so imaginings for the future don't really help here unfortunately. I'd obviously rather have a standard API than get into the situation where more and more devices and distros simply won't run an upstream kernel. If the long term theoretical transition is a concern then we could simply make the "set" behaviour Set: value is used as a hint to the uinput driver and input layer that a given amount of buffering may be required. It may be ignored by the input layer. and if the long term imagining ever happens the interface cannot be an implediment. It won't cause any problems because if the automatic interfaces work then the hint isn't needed, and if they never get implemented or it turns out they never to work for all cases (most likely I suspect) then you'll still need the hint. Does that work ? Alan -- 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
