On Wed, Oct 27, 2010 at 05:11:28PM -0700, Bill Gatliff wrote: > On Wed, Oct 27, 2010 at 4:57 PM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > On Wed, Oct 27, 2010 at 12:09:58PM -0500, Bill Gatliff wrote: > >> This patch moves the tail pointer up one event on a buffer > >> overflow, which "consumes" the oldest event in the buffer > >> to make room for the incoming event. Thus, although data > >> is lost due to the overflow (which is unavoidable), the > >> data that remains is both recent and still time-ordered. > >> > > > > It does not really matter... You are losing part of the hardware state > > regardless so the packet is invalid anyway. What would probably make > > more sense is to ignore all events up until next packet boundary > > (EV_SYN/SYN_REPORT) so userspace would get most up-to-date _full_ packet > > (when it catches up). > > That's an interesting idea, actually. Maybe the subject of a future patch. :) > > I still think my patch is a genuine improvement as-is, however. Sorry, I am unconvinced that it is an improvement. > But > perhaps not the final word on the issue. > > For example, how do you recall the events that userspace has already > digested from the current packet? One alternative is to not queue a > packet until the whole packet is ready, but that will introduce > latency. I don't like that approach, either. Hmmm... Userspace is not supposed to act on a packet until it receives SYN_REPORT. Userspace should also be prepared to handle events overriding older ones. So there is no "recall" needed. Consider finger moving on a high-speed/high-resolution touchpad (only coordinates, no exteneded attributes for simplicity sake): 1 2 3 4 5 6 7 8 9 10 11 12 ABS_X1 ABS_Y1 SYN ABS_X2 ABS_Y2 SYN ABS_X3 ABS_Y3 SYN ABS_X4 ABS_Y4 SYN Imagine you overflow and lose events 5 through 9 - no big deal. Userspace will get ABS_X2 ABS_X4 ABS_Y4 SYN which will tranlate into (X4, Y4) - the most recent coordinates (and ones we are interested in most of all). It is not that important where finger was a second ago as it is important where it is _now_. Of course you may still lose some data (key/button releases, etc) but input devices should size buffers properly and overflows should be rare events. > > I suppose another possibility is to always reserve enough room for an > EV_SYN/SYN_REPORT event, and never discard those events. Then > userspace will always see a properly-terminated packet, but in a > collision it would receive a partial-but-properly-terminated packet. > And what is the benefit of properly terminated but incomplete packet? Let's say you are doing a pinch gesture with 2 fingers. Would you rather lose one finger data (and then your pinch is not pinch anymore but a single touch) or discard one packet completely so that the next (complete one) allows you to continue gesture as is? -- 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
