> > 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. Sure, we may need a hint, but if the better hint turns out to be events_per_millisecond rather than events_per_packet, we are still in a bad situation. Let's see what Dmitry thinks about this. I don't mind making the accompanying changes right away, if that helps you. Thanks, Henrik -- 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
