From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Hutterer Subject: Re: [RFC RESEND 5/5] Input: evdev - add new EVIOCGABSRANGE ioctl Date: Mon, 11 Aug 2014 12:13:16 +1000 Message-ID: <20140811021316.GA26242@jelly.redhat.com> References: <1405775445-4454-1-git-send-email-dh.herrmann@gmail.com> <1405775445-4454-6-git-send-email-dh.herrmann@gmail.com> <20140806013519.GA11429@jelly.redhat.com> <20140808174742.GG26820@core.coreip.homeip.net> <20140810231759.GA10731@jelly.redhat.com> <20140811000134.GA12650@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from leo.clearchain.com ([199.73.29.74]:46234 "EHLO mail.clearchain.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751711AbaHKCNR (ORCPT ); Sun, 10 Aug 2014 22:13:17 -0400 Content-Disposition: inline In-Reply-To: <20140811000134.GA12650@core.coreip.homeip.net> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Dmitry Torokhov Cc: David Herrmann , Benjamin Tissoires , "open list:HID CORE LAYER" , Dmitry Torokhov 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