From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Denilson_Figueiredo_de_S=C3=A1?= Subject: Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range Date: Wed, 02 Nov 2011 21:39:50 -0200 Message-ID: References: <1319476183.3210.12.camel@lovely> <20111024203204.GA31721@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed delsp=yes Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Jiri Kosina Cc: Dmitry Torokhov , Christoph Fritz , linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, linux-usb@vger.kernel.org List-Id: linux-input@vger.kernel.org On Mon, 31 Oct 2011 13:24:09 -0200, Jiri Kosina wrote= : > I personally find the wording of the spec here a bit unfortunate (the > 'declaring bit field in a report that is capable of containing a rang= e of > values largen than those actually generated by the control' seems to = be a > bit too foggy and vague). I don't think it is vague. "declaring bit field in a report" -> Input() "that is capable of containing a range of values" -> Report_size() "larger than those actually generated by the control" -> The entire ran= ge =20 repreented using Report_size bits is larger than the Logical =20 minimum/maximum, =46or me, that paragraph is not foggy. Maybe other pieces of the spec a= re, =20 but that one seemed clear for me. >> > + if (value < field->logical_minimum || >> > + value > field->logical_maximum) { > > After thinking about it a little bit more, I think I agree. [...] > So please let me know the result of your testing. Seems to work on my device, thanks! I haven't done more than a couple of minutes of testing, though. But it= =20 seems to work. (another test below) I've also tested the behavior when one axis is valid, while the other o= ne =20 as an invalid (and thus discarded) value. This was based on a question from Chris Friesen: =20 https://lkml.org/lkml/2011/10/24/290 Running "evtest /dev/input/event9" only shows the valid axis. That's go= od, =20 it seems invalid values don't generate events. But Xorg moves the pointer in both axes at once, instead of just one of= =20 them. IMHO, that's not perfect, but it seems good enough, specially consideri= ng =20 this is a somewhat unlikely edge-case (remember I'm talking about one a= xis =20 valid and another discarded). It might also be a bug in Xorg. (if anything in this message doesn't make much sense, that's probably =20 because I need some sleep - but I wanted to give you feedback as soon a= s I =20 could) --=20 Denilson Figueiredo de S=C3=A1 Rio de Janeiro - Brasil