Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758639Ab2EJMl3 (ORCPT ); Thu, 10 May 2012 08:41:29 -0400 Received: from smtprelay-b22.telenor.se ([195.54.99.213]:59657 "EHLO smtprelay-b22.telenor.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755913Ab2EJMl0 (ORCPT ); Thu, 10 May 2012 08:41:26 -0400 X-SENDER-IP: [85.230.168.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsKfAH62q09V5qg+PGdsb2JhbABEijioLwMBgR0ZAQEBAR4ZDSeCFQEBBAEnExwjEAgDRhQlChqIHAm7PROLQoF5gwpjBJV8hgWDVIlT X-IronPort-AV: E=Sophos;i="4.75,565,1330902000"; d="scan'208";a="330881713" From: "Henrik Rydberg" Date: Thu, 10 May 2012 14:46:42 +0200 To: Benjamin Tissoires Cc: Dmitry Torokhov , Jiri Kosina , Stephane Chatty , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/5] HID: hid-multitouch: get maxcontacts also from logical_max value Message-ID: <20120510124642.GA9254@polaris.bitmath.org> References: <1336136030-18503-1-git-send-email-benjamin.tissoires@gmail.com> <1336136030-18503-3-git-send-email-benjamin.tissoires@gmail.com> <20120506190322.GB12571@polaris.bitmath.org> <20120509194623.GA12381@polaris.bitmath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1187 Lines: 28 > > As long as all existing devices are unaffected, it's fine, hence the question. > > I checked all the reports descriptors that I have. > 2 devices (one Stantum and one Irtouch) present an unrealistic > logical_max value (255). The thing is that if this logical_max is > false, and if the value is not provided, then I don't know how could I > retrieve the right value beside introducing a MT_CLS... > > Henrik, do you think that 255 is two much for the slots? It is large enough for us to start worrying about how we manage memory, not to mention throughput. Since we do not really have devices of that type yet, how about adding a MT_MAX_MAXCONTACT next to MT_DEFAULT_MAXCONTACT, and use it as a sanity check, like so: if (!td->maxcontacts && field->logical_maximum <= MT_MAX_MAXCONTACT) td->maxcontacts = field->logical_maximum; Then the default (10) would be picked for the suspect devices, just as it is today. Thanks, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/