On Wed, Oct 27, 2010 at 5:30 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Wed, Oct 27, 2010 at 05:11:28PM -0700, Bill Gatliff wrote: >> I still think my patch is a genuine improvement as-is, however. > > Sorry, I am unconvinced that it is an improvement. The current code clobbers the queue suddenly and entirely on overflow, and replaces all the events therein with the current one. My version simply discards the oldest event to make room for the newest one. I'll agree that my patch doesn't utterly and completely fix the problem, but I have verified that at least with a flood of incoming multitouch packets, the system still generally behaves itself--- which is far more than it was able to do with the code that I replaced. How else would you be convinced? You can't possibly believe that the current code needs to stay in place, can you? The thing with touch events specifically is that they contain tons of redundant information, so losing a few old ones here and there generally doesn't cause problems--- but losing a whole bunch of them at the moment of overflow DOES seem to cause problems. And touch events tend to be bursty, making them more likely to trigger such overflows in the first place. With keycodes, on the other hand, you don't want to lose any of them. Ever. But such devices don't tend to generate events as fast, and the recent versions of the evdev queue did such a poor job on overflow that it's pretty clear that overflows must not have happened that often. Never, perhaps. That's why even in its imperfect state, my patch seems to improve things--- because it makes a difference under conditions where dropping portions of a packet don't seem to matter as much. It doesn't get triggered in cases where dropping an event will almost certainly lead to problems. The alternative, of course, is to smarten-up the evdev queues so that they work at the level of entire packets, rather than individual events. In the meantime, I'll proffer my patch as a small step in the right direction. Especially considering where we are coming from. 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
