All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chase Douglas <chase.douglas@canonical.com>
To: Chris Bagwell <chris@cnpbagwell.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Peter Hutterer <peter.hutterer@who-t.net>,
	linux-input <linux-input@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] Alternative approach to MT_TOOL_ENVELOPE
Date: Wed, 15 Dec 2010 16:08:04 -0500	[thread overview]
Message-ID: <4D092E34.8060002@canonical.com> (raw)
In-Reply-To: <AANLkTik4aS4mA_yrEDiG0QRxHx2pJ+KGGMKEWSDep1CB@mail.gmail.com>

On 12/15/2010 03:41 PM, Chris Bagwell wrote:
> I meant to mention: once your initial draft gets committed I would
> love to help update it some.  I specifically want to show two example
> usage.  1) touchpad as 1 to 3 touchs occur and show special
> considerations to ABS_* that apps should handle.  2) a touchscreen
> that supports a pen as well and show how tool change (finger to pen)
> should work.  For both those examples, it would be interesting to
> discuss how MT can be used concurrently (does pen in slot 0 and touch
> in slot 1 make sense for example).

This is the other main reason I wanted to make the document. Having a
place where best practices are detailed will help future driver writers
and hopefully reduce errors in evdev code usage. I'd love to see this
added to the document.

I do think that MT is complex enough that related documentation should
be in multi-touch-protocol.txt, though. Anywhere I discussed MT in
evdev-codes.txt I referred the reader to the other file. Henrik, does
that sound good to you?

> I think it will be invaluable to document this stuff for driver
> writers and apps but I'm not sure yet what level needs to be enforced.

That's the biggest issue I see right now. Do we want black and white
specificity? For example, using terms like "must" and "may not" etc. Or
do we want the document to merely hold best practices while not
proscribing exact details? I think even with exact details we can loosen
them if needed, but that has its own can of worms.

Dmitry, what are your thoughts on this?

Thanks,

-- Chase

  reply	other threads:[~2010-12-15 21:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-15 10:26 [PATCH 0/4] Alternative approach to MT_TOOL_ENVELOPE Henrik Rydberg
2010-12-15 17:40 ` Chase Douglas
2010-12-15 19:36   ` Henrik Rydberg
2010-12-15 21:13     ` Chase Douglas
2010-12-16 14:41       ` Henrik Rydberg
2010-12-15 20:41   ` Chris Bagwell
2010-12-15 21:08     ` Chase Douglas [this message]
2010-12-16 14:35       ` Henrik Rydberg
2010-12-16  0:19 ` Peter Hutterer
  -- strict thread matches above, loose matches on Subject: below --
2010-12-14 21:21 Chase Douglas
2010-12-14 21:38 ` Chase Douglas
2010-12-14 22:12 ` Dmitry Torokhov
2010-12-15  0:21   ` Chase Douglas
2010-12-15  1:37     ` Henrik Rydberg
2010-12-15  7:25       ` Dmitry Torokhov
2010-12-15 17:31         ` Chase Douglas
2010-12-15 20:25           ` Chris Bagwell
2010-12-15 20:25             ` Chris Bagwell

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=4D092E34.8060002@canonical.com \
    --to=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=peter.hutterer@who-t.net \
    --cc=rydberg@bitmath.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 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.