linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Henrik Rydberg" <rydberg@euromail.se>
To: Ping Cheng <pinglinux@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH 3/4] input - wacom : support one finger touch the touchscreen way
Date: Fri, 25 Feb 2011 15:44:47 +0100	[thread overview]
Message-ID: <20110225144447.GA22165@polaris.bitmath.org> (raw)
In-Reply-To: <AANLkTikKiZeKcWCGgZ5ZADpA-odXuLP1yDk4847cjuN=@mail.gmail.com>

> touch_down represents the touch status that the driver gets/sets, not the
> actual touch down. Driver touch down (touch_down) is decided by both the
> actual touch and pen status, while it won't be changed by actual touch
> status when pen is in.

Understood, but it hides complex state transitions and therefore
becomes error prone. I believe your code is correct, but less
maintainable than it could be. I would like to take the opportunity to
express that here, with the following argument.

Let us assume we have two variables, A and B, representing the actual
touch and pen down. We can then try to write down the boolean function
for when touch and pen events should not be sent. Starting out simple,
we could try, for an arbitrary time step n,

inhibit_touch(n) = T(A(n), B(n))
inhibit_pen(n) = P(A(n), B(n))

Now, you already stated that this does not work very well, because if
B changes state, for instance, and inhibit_touch changes state at the
same time, we get a race for the pointer events. So, expanding on
this, we could take history into account and try

inhibit_touch(n) = T(A(n), B(n), A(n-1), B(n-1))
inhibit_pen(n) = P(A(n), B(n), A(n-1), B(n-1))

This seems like it could work, since we can detect the state change
and decide how to deal with the pointer events by choosing the
functions T and P appropriately.

The point of all this is that code using simple input variables (A, B)
and a complex boolean function (T, P) has no hidden error
states. Conversely, code using complex input variables and a simple
boolean function may contain an arbitrary number of hidden error
states. As time goes by, those error states may be enabled by accident
during a code change. Sure, both approaches lead to correct code if
performed properly, but the former is less error prone and therefore
easier to maintain.

Henrik

  parent reply	other threads:[~2011-02-25 14:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-16 22:53 [PATCH 3/4] input - wacom : support one finger touch the touchscreen way Ping Cheng
2011-02-20 12:21 ` Henrik Rydberg
     [not found]   ` <AANLkTikKiZeKcWCGgZ5ZADpA-odXuLP1yDk4847cjuN=@mail.gmail.com>
2011-02-25 14:44     ` Henrik Rydberg [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-02-22 17:40 Ping Cheng
2011-02-11  1:32 Ping Cheng
2011-02-11 19:56 ` Henrik Rydberg
2011-02-11 20:24   ` Ping Cheng
2011-02-11 20:40     ` Ping Cheng
2011-02-11 20:58       ` Chris Bagwell
2011-02-11 21:49         ` Henrik Rydberg

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=20110225144447.GA22165@polaris.bitmath.org \
    --to=rydberg@euromail.se \
    --cc=linux-input@vger.kernel.org \
    --cc=pinglinux@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 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).