Dmitry: On Fri, Dec 3, 2010 at 1:50 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > Right. The indication that application wants the data is open() call. If > userspace does not want data, it should close() the interface. It *does* want the data, just at a specified rate. And right now, we have no consistent way of having applications express that rate to the input device. A read callback is one, very flexible way of correcting that. > Drivers have no idea what users want to do with the data so they can't > decide whether to ignore the hardware or query it and queue events up. > Some applications might be interested in "sample on demand", while > others would prefer events to be queued and consumed at once. Yep. We've already covered that. > [... cut long argument for an inconsistent and incompatible change to > the interface ...] I object. My proposed change is carefully considered to be neither inconsistent nor incompatible with the current interface. Existing drivers will continue to work exactly as they do now. Future drivers that don't utilize the read callback will work exactly as conventional drivers do now. Certain hardware drivers will want to take advantage of the read callback, and those drivers will perform differently in ways that some applications won't care about, and others won't even notice. And those drivers will perform usefully for applications that *do* care about the differences. I predicted (and welcomed) a lot of constructive challenges to making a change to such a widely used API. But your outright hostility isn't a productive use of anyone's time. > BTW, if application reads (supplies space for) just one event should we > disacard the rest of hardware state that we read from the device? You > know, just asking... Ridiculously hypothetical, distracting and unrelated question, but I'll answer it anyway. If the application wants more than one event, it had better make room for them. As for the events that remain in the queue, if any: that depends on how the driver works. Just like it does today. b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx -- 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
