From: Ping Cheng <pinglinux@gmail.com>
To: Michal Suchanek <hramrach@centrum.cz>
Cc: "X.Org Devel List" <xorg-devel@lists.freedesktop.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Daniel Stone <daniel@fooishbar.org>,
linux-input <linux-input@vger.kernel.org>
Subject: Re: [RFC] Multi-Touch (MT) support - arbitration or not
Date: Sun, 7 Nov 2010 15:32:09 -0800 [thread overview]
Message-ID: <AANLkTimHmFhAden9SvJMOFWtdodzyYWK+ePi2sqKuWsa@mail.gmail.com> (raw)
In-Reply-To: <AANLkTin+S_jJAdw6gLH1RnbyD1EB6ChHCo9yNheLb_sg@mail.gmail.com>
On Sat, Nov 6, 2010 at 8:53 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
>
> As a tablet user, not X developer I don't think it is desirable and
> expected to register pen touch and finger touch together as a
> multitouch. That is, if I wanted to trigger a multitouch feature I
> would use fingers, not pen and finger. While it would be technically
> possible to use the pen touch and finger touch together to trigger
> multitouch I don't think it makes much sense.
>
> Also it is a good idea to turn off (single) touch when pen is in
> proximity because it is quite easy to accidentally touch the surface
> while moving the pen.
>
> This means that the protocol that sends abs events from pen when in
> proximity and from finger otherwise would work well.
>
> However, there is one feature that makes sort of sense and does not
> work when touch is completely off. It might be possible to use touch
> for button and pen for moving the cursor. I tried to use the pad
> button on my Bamboo together with pen motion for right drags and it
> seems somewhat easier than using the pen button.
Thank you for sharing your thoughts. This is the kind of "third party"
feedback that I wished for. So, you do see the value of reporting and
using both MT and pen data simultaneously.
> So I would say that protocol that allows events from both pen and
> touch at the same time is desirable in the long run but with some
> options to filter the events when both pen and touch are used
> together.
>
> This gives basically three options
>
> 1) leave as is, turn off touch when pen is in proximity
>
> 2) report everything by kernel, put some filter on the touch events in
> the X driver (which defaults to killing most touch stuff when pen is
> in proximity)
>
> 3) the same as above but put the filter in the kernel driver
>
>
> 2 or 3 is more flexible as people with some special uses can just turn
> off the filter and get all events.
Then, which option, 2 or 3, do you prefer? To share where I am with
you: I am 60% with option 2 and 40% with 3 (I was 100% with 3 before)
> WRT X ease of development I would suggest that the same device should
> never report different events based on pen proximity. Either the
> device is in some "compatibility mode" and reports only one pointer as
> per 1 or there are two separate pointers and they are just reported
> out of proximity when the pointer positioning is not desirable (ie
> when pen is out or when touch is off due to pen being in).
>
> If somebody wants to have multitouch combining two different pointers
> there is nothing stopping them, either with P&T pen and touch pointers
> or completely unrelated devices.
We'll take care of this step once we know how to report the data.
Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-11-07 23:32 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 18:47 [RFC] Multi-Touch (MT) support - arbitration or not Ping Cheng
2010-11-06 15:16 ` Chris Bagwell
2010-11-06 15:53 ` Michal Suchanek
2010-11-06 20:38 ` Rafi Rubin
2010-11-08 3:39 ` Peter Hutterer
2010-11-07 23:32 ` Ping Cheng [this message]
[not found] ` <AANLkTin1svszp87Pysi5OCt5=JTSB-yVaAWF-42gfn9T-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-11-07 16:30 ` Daniel Stone
2010-11-07 21:07 ` Michal Suchanek
2010-11-07 23:38 ` Ping Cheng
2010-11-07 23:49 ` Ping Cheng
2010-11-08 0:53 ` Mohamed Ikbel Boulabiar
2010-11-08 3:51 ` Peter Hutterer
2010-11-08 8:08 ` Benjamin Tissoires
2010-11-08 21:54 ` Chris Bagwell
2010-11-08 23:33 ` Ping Cheng
2010-11-09 3:42 ` Chris Bagwell
2010-11-09 3:31 ` Peter Hutterer
2010-11-09 4:14 ` Chris Bagwell
2010-11-10 4:46 ` Peter Hutterer
2010-11-11 3:57 ` Chris Bagwell
2010-11-11 18:23 ` Ping Cheng
2010-11-09 6:59 ` Dmitry Torokhov
2010-11-09 16:28 ` Chris Bagwell
2010-11-09 20:10 ` Ping Cheng
2010-11-10 5:02 ` Peter Hutterer
2010-11-10 10:00 ` Henrik Rydberg
2010-11-10 23:53 ` Peter Hutterer
2010-11-11 0:48 ` Henrik Rydberg
2010-11-11 1:22 ` Dmitry Torokhov
2010-11-11 8:06 ` Michal Suchanek
2010-11-11 8:26 ` Dmitry Torokhov
2010-11-11 9:35 ` Michal Suchanek
2010-11-11 19:01 ` Ping Cheng
2010-11-11 19:24 ` Dmitry Torokhov
2010-11-11 19:41 ` Henrik Rydberg
2010-11-11 19:55 ` Dmitry Torokhov
2010-11-11 21:25 ` Ping Cheng
2010-11-11 21:38 ` Henrik Rydberg
2010-11-11 22:10 ` Ping Cheng
2010-11-11 23:21 ` Michal Suchanek
2010-11-12 8:21 ` Henrik Rydberg
2010-11-14 20:40 ` Ping Cheng
2010-11-09 18:10 ` Ping Cheng
2010-11-09 20:36 ` Michal Suchanek
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=AANLkTimHmFhAden9SvJMOFWtdodzyYWK+ePi2sqKuWsa@mail.gmail.com \
--to=pinglinux@gmail.com \
--cc=daniel@fooishbar.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hramrach@centrum.cz \
--cc=linux-input@vger.kernel.org \
--cc=xorg-devel@lists.freedesktop.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).