Hi On Mon, Aug 11, 2014 at 4:13 AM, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > 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. Yepp, fully agree on both points you make (I summarized them way worse than you did!). Thanks David -- 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
