From: Seth Forshee <seth.forshee@canonical.com>
To: George Pantalos <gpantalos@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: ALPS v4 Semi-mt Support
Date: Tue, 17 Apr 2012 08:16:18 -0500 [thread overview]
Message-ID: <20120417131618.GA14091@thinkpad-t410> (raw)
In-Reply-To: <2024920.Dutyu6QMZV@vaio>
On Tue, Apr 17, 2012 at 01:21:45AM +0300, George Pantalos wrote:
> I have noticed that the sync bit can at times be set in the second packet of
> the sequence. Couldn't this reset the position to priv->multi_packet=0 when
> in fact we are in priv->multi_packet=1 position?
> I have also thought about "if((packet[6] & 0x40) && (priv->multi_packet ==
> 0))" so that sync is not lost.
I think there are two possibilities for when you see the sync bit set in
the second packet.
The first is that the touchpad aborted the previous sequence and started
a new one. In this case you really do want to reset priv->multi_packet.
The other option is that it really isn't a sync bit, and that it has
some other meaning. In that case you'll need to find some other reliable
method for assembling the MT data in the correct order.
The only way you'll be able to tell is by inspecting the packets after
the one with the unexpected sync. I suspect you'll either see one of two
sequences. This one:
sync -> sync -> non-sync -> non-sync -> sync -> ...
Which would appear to be an aborted sequence followed by the start of a
new one. Or this one:
sync -> sync -> non-sync -> sync -> ...
Which would appear to indicate that what we're calling the sync bit
isn't really a sync after all.
Seth
next prev parent reply other threads:[~2012-04-17 13:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 14:02 ALPS v4 Semi-mt Support George Pantalos
2012-04-10 15:21 ` Seth Forshee
2012-04-10 21:59 ` Seth Forshee
2012-04-16 14:24 ` George Pantalos
2012-04-16 21:24 ` Seth Forshee
2012-04-16 22:21 ` George Pantalos
2012-04-17 13:16 ` Seth Forshee [this message]
2012-04-17 0:52 ` George Pantalos
2012-04-17 15:22 ` Seth Forshee
-- strict thread matches above, loose matches on Subject: below --
2012-04-10 14:01 George Pantalos
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=20120417131618.GA14091@thinkpad-t410 \
--to=seth.forshee@canonical.com \
--cc=gpantalos@gmail.com \
--cc=linux-input@vger.kernel.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).