From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Ping Cheng <pinglinux@gmail.com>,
Michal Suchanek <hramrach@centrum.cz>,
"X.Org Devel List" <xorg-devel@lists.freedesktop.org>,
Chris Bagwell <chris@cnpbagwell.com>,
linux-input <linux-input@vger.kernel.org>
Subject: Re: [RFC] Multi-Touch (MT) support - arbitration or not
Date: Thu, 11 Nov 2010 11:55:40 -0800 [thread overview]
Message-ID: <20101111195540.GA14508@core.coreip.homeip.net> (raw)
In-Reply-To: <4CDC46E5.8040703@euromail.se>
On Thu, Nov 11, 2010 at 08:41:25PM +0100, Henrik Rydberg wrote:
> >>
>
> >> But, I think ABS_X/Y arbitration should be considered in the kernel to
> >> reduce the overhead in userland.
> >
> > With option 1 you have natural ST arbitration - the first touch gets to
> > report (ABS_X, ABS_Y), the rest will have to report ABS_MT_* till the
> > first touch is lifted, right?
>
>
> Right. Perhaps this is a good time to discuss some additional helper functions
> Chris and myself are playing with right now.
>
> /**
> * input_mt_report_state() - report contact state
> * @dev: input device with allocated MT slots
> * @active: true if contact is active, false otherwise
> *
> * Reports an active touch via ABS_MT_TRACKING_ID. If active is
> * true and the slot is currently inactive, a new tracking id is
> * assigned to the slot.
> */
> void input_mt_report_state(struct input_dev *dev, bool active);
>
> Since all tracking-capable drivers we have seen so far have a contact id with
> the same semantics as the slot id, it makes sense to have the above function to
> remove the need for individual drivers to assign tracking ids.
>
> With the input core (or input-mt.c) controlling the tracking id, it is easy to
> add more goodness, such as
>
> /**
> * input_mt_report_pointer_emulation() - common pointer emulation
> * @dev: input device with allocated MT slots
> *
> * Performs legacy pointer emulation via BTN_TOUCH, etc.
> */
> void input_mt_report_pointer_emulation(struct input_dev *dev);
>
> Since the input device knows the MT state and what buttons and abs axes are in
> use, it can provide the right set of data to emit to emulate pointer and touch
> events. The track-oldest-contact logic can be readily implemented.
>
> From what I can see, this would remove two complications from each MT slots
> driver, removing both code and headaches.
>
> What do you think?
>
input-mt.c seems like a good idea for keeping a common library of
goodies for MT drivers.
--
Dmitry
next prev parent reply other threads:[~2010-11-11 19:55 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
[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 [this message]
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=20101111195540.GA14508@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=chris@cnpbagwell.com \
--cc=hramrach@centrum.cz \
--cc=linux-input@vger.kernel.org \
--cc=pinglinux@gmail.com \
--cc=rydberg@euromail.se \
--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).