From: "Denilson Figueiredo de Sá" <denilsonsa@gmail.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Christoph Fritz <chf.fritz@googlemail.com>,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
Date: Wed, 02 Nov 2011 21:39:50 -0200 [thread overview]
Message-ID: <op.v4ceooygdsdv5o@localhost> (raw)
In-Reply-To: <alpine.LNX.2.00.1110311349180.3541@pobox.suse.cz>
On Mon, 31 Oct 2011 13:24:09 -0200, Jiri Kosina <jkosina@suse.cz> 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 range 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 range
repreented using Report_size bits is larger than the Logical
minimum/maximum,
For me, that paragraph is not foggy. Maybe other pieces of the spec are,
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
seems to work.
(another test below)
I've also tested the behavior when one axis is valid, while the other one
as an invalid (and thus discarded) value.
This was based on a question from Chris Friesen:
https://lkml.org/lkml/2011/10/24/290
Running "evtest /dev/input/event9" only shows the valid axis. That's good,
it seems invalid values don't generate events.
But Xorg moves the pointer in both axes at once, instead of just one of
them.
IMHO, that's not perfect, but it seems good enough, specially considering
this is a somewhat unlikely edge-case (remember I'm talking about one axis
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
because I need some sleep - but I wanted to give you feedback as soon as I
could)
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
next prev parent reply other threads:[~2011-11-02 23:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-22 11:42 Linux USB HID should ignore values outside Logical Minimum/Maximum range Denilson Figueiredo de Sá
2011-10-24 16:24 ` Chris Friesen
2011-10-24 16:39 ` Denilson Figueiredo de Sá
2011-10-24 20:35 ` Dmitry Torokhov
2011-10-25 4:03 ` Denilson Figueiredo de Sá
2011-10-24 17:09 ` Christoph Fritz
2011-10-24 17:04 ` Denilson Figueiredo de Sá
2011-10-24 20:32 ` Dmitry Torokhov
2011-10-28 16:23 ` Jiri Kosina
2011-10-28 19:27 ` Christoph Fritz
2011-10-28 20:40 ` Denilson Figueiredo de Sá
2011-10-31 15:24 ` Jiri Kosina
2011-11-02 23:39 ` Denilson Figueiredo de Sá [this message]
2011-11-16 14:01 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.v4ceooygdsdv5o@localhost \
--to=denilsonsa@gmail.com \
--cc=chf.fritz@googlemail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).