On Sun, Aug 10, 2014 at 05:01:35PM -0700, Dmitry Torokhov wrote: [...] > > > > > > is about handling corner-cases. If we make SYN_DROPPED > > > handling cause SYN_DROPPED, we can just ignore it. > > > > yep, that too was my first thought. with a plain resync ioctl you're pretty > > much guaranteed to get SYN_DROPPED before the client manages to handle the > > resync. Even if you reduce the number of events as above because the most > > common occurance for SYN_DROPPED is in the ABS_MT range which we cannot > > meaningfully reduce. > > Hmm, that's a problem... But is it? We need to make sure that buffer is large > enough for the MT device to transmit all it's contacts properly. We can not > expect that we'll always be able to reduce number of events if a user actively > uses 10 contacts. IOW we need to solve this issue regardless of this proposed > sync ioctl. > > Maybe we need to review drivers and see if they need to supply their own hints > or update hinting logic in core? The buffer is already large enough for at least one full report from the device plus a few extra events [1]. for the devices we see SYN_REPORT most frequently dumping the state means filling up the buffer to the almost maximum. To give some room for movement, we need to increase the queue by at least a factor 2. That gives us with room for one whole sync report and at least one full extra event. Anything smaller we get the side-effect that a client that is too slow and gets a SYN_DROPPED is actually worse off because now the buffer is so full from the sync that a SYN_DROPPED is even more likely to occur than before. We also need to define the behaviour for the queue filling up while the client is in the middle of a sync. That means the client must be able to handle SYN_DROPPED as well as SYN_SYNC_DONE during a sync or the kernel protects the events up to SYN_SYNC_DONE in the queue in the case of a SYN_DROPPED. Either way it's IMO more complicated than having a separate buffer for the sync state. Cheers, Peter [1] almost, it doesn't account for EV_SW for example -- 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
