From: Peter Hutterer <peter.hutterer@who-t.net>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: Chris Bagwell <chris@cnpbagwell.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Henrik Rydberg <rydberg@euromail.se>,
Nikolai Kondrashov <spbnick@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] Documentation: Add evdev type and code definitions
Date: Fri, 25 Mar 2011 10:36:02 +1000 [thread overview]
Message-ID: <20110325003602.GA14035@barra.bne.redhat.com> (raw)
In-Reply-To: <4D8B9F6F.5010705@canonical.com>
On Thu, Mar 24, 2011 at 03:45:51PM -0400, Chase Douglas wrote:
> On 03/24/2011 02:44 PM, Chris Bagwell wrote:
> > Looking good. Minor comments at end.
> >
> > On Thu, Mar 24, 2011 at 12:44 PM, Chase Douglas
> > <chase.douglas@canonical.com> wrote:
> >> +Touchscreens:
> >> +----------
> >> +ABS_{X,Y} must be reported with the location of the touch. BTN_TOUCH must be
> >> +used to report when a touch is active on the screen.
> >> +BTN_{MOUSE,LEFT,MIDDLE,RIGHT} must not be reported. BTN_TOOL_<name> events
> >> +should be reported where possible.
> >
> > Does the real button event restriction solve something? I know
> > majority of touchscreens are not sending a button today but usually
> > there is a button on the touchscreen frame that I'd image at least
> > some devices hooking it up to touchscreen interface.
> >
> > stylus+touchscreen combo devices are surely going to want to do this.
>
> Perhaps this should be more clearly for touchscreen-only devices (not
> tablets or a mix). The problem we end up seeing is drivers who use
> BTN_LEFT because they want a touch to generate a primary button press in
> X. I want to prevent people from doing this.
suggest that they use BTN_0 instead then?
Cheers,
Peter
> I believe mixed devices are hard to detect between tablets and
> stylus+touchscreen right now, as evidenced by the X evdev driver not
> handling the former by default while wacom is often used for the latter.
> However, with the device properties a userspace driver should be able to
> tell the two apart.
>
> I'll rename this guideline: Touchscreens without stylus tools. Any issues?
>
> >> +
> >> +Trackpads:
> >> +----------
> >> +Legacy trackpads that only provide relative position information must report
> >> +events like mice described above.
> >> +
> >> +Trackpads that provide absolute touch position must report ABS_{X,Y} for the
> >> +location of the touch. BTN_TOUCH should be used to report when a touch is active
> >> +on the trackpad. Where multi-finger support is available, BTN_TOOL_<name> should
> >> +be used to report the number of touches active on the trackpad.
> >
> > How about a Tablet?
> >
> > Something like:
> >
> > Tablets:
> > --------
> >
> > BTN_TOOL_<name> events must be reported when a stylus or other tool is
> > active on tablet. ABS_{X,Y} must be reported with the location of the
> > tool. BTN_TOUCH should be used to report when the tool is in contact
> > with the tablet. BTN_{STYLUS,STLUS2} should be used to report buttons
> > on tool itself and BTN_{LEFT,MIDDLE,RIGHT,1,2,etc} should be used to
> > report buttons on tablet.
>
> Thanks for the addition! I'll add it in and add you on a SOB line if
> that's alright with you.
>
> > Some tablets send ABS_PRESSURE with no BTN_TOUCH (why I said should
> > instead of must). Probably this is not worth mentioning here?
>
> Yeah, I'd leave that off as I think we want to set the guidelines to use
> BTN_TOUCH.
>
> Thanks,
>
> -- Chase
next prev parent reply other threads:[~2011-03-25 0:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 17:44 [PATCH v3] Documentation: Add evdev type and code definitions Chase Douglas
2011-03-24 18:44 ` Chris Bagwell
2011-03-24 18:44 ` Chris Bagwell
2011-03-24 19:45 ` Chase Douglas
2011-03-24 20:28 ` Chris Bagwell
2011-03-24 20:28 ` Chris Bagwell
2011-03-25 0:36 ` Peter Hutterer [this message]
2011-03-25 5:50 ` Dmitry Torokhov
2011-03-25 6:04 ` Peter Hutterer
2011-03-25 6:16 ` Dmitry Torokhov
2011-03-25 0:42 ` Peter Hutterer
2011-03-25 5:53 ` Dmitry Torokhov
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=20110325003602.GA14035@barra.bne.redhat.com \
--to=peter.hutterer@who-t.net \
--cc=chase.douglas@canonical.com \
--cc=chris@cnpbagwell.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rydberg@euromail.se \
--cc=spbnick@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.