On Wed, Mar 02, 2011 at 06:13:57PM +0100, Henrik Rydberg wrote: > > > 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. > Umm, before we do that could we get an idea what kind of device is that that our current hints are not sufficient? Is the rate is so high because the device is too noisy? Thanks. -- 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
