From: Neil Leeder <nleeder@codeaurora.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Horace Fu <horace.fu@quantatw.com>,
Mandeep Singh Baines <msb@chromium.org>,
Trilok Soni <tsoni@codeaurora.org>
Subject: Re: [PATCH v2] input: mouse: add qci touchpad driver
Date: Wed, 18 Aug 2010 17:38:38 -0400 [thread overview]
Message-ID: <4C6C52DE.4040700@codeaurora.org> (raw)
In-Reply-To: <BC741E3E-377E-45BF-80E1-A60F4E0FDFC9@gmail.com>
Hi Dmitry,
On 8/17/2010 2:05 PM, Dmitry Torokhov wrote:
> That suggests that the device responds to at least basic PS/2 queries.
>
>> I can see data being passed through the serio driver but the logitech
>> driver can't process it.
>>
>
> What about loading psmouse module with proto=bare?
>
> Could you also dump the data received from touchpad during probing?
>
It appears the controller does somewhat respond as a PS/2 device. The
first problem is it only responds to CMD_GETID correctly about 50% of
the time. Sometimes it responds well with a 0x00, other times with 0xfa,
which causes psmouse_probe to not recognize it as a pointing device.
[ 1.037223] wpce775x_send len=1 data=f2
[ 1.054412] wpce775x_recv ... data_in=fa fa 64 0 0 0 0 0 fa 0 0 0 0 0
0 0
It also doesn't respond well to CMD_GETINFO, which is why it gets
mis-detected as the wrong device type. As an aside, I'm not sure if
combining separate commands into one i2c packet is correct, but
separating them didn't seem to produce better results either.
[ 1.723943] wpce775x_send len=3 data=e8 3 e6
[ 1.735666] wpce775x_recv ... data_in=fa fa 64 0 0 0 0 0 fa 0 0 0 0 0
0 0
[ 1.735892] wpce775x_send len=3 data=e6 e6 e9
[ 1.748281] wpce775x_recv ... data_in=fe fa 64 0 0 0 0 0 fa 0 0 0 0 0
0 0
[ 1.748500] wpce775x_send len=3 data=e8 0 e6
[ 1.760233] wpce775x_recv ... data_in=fa fa 64 0 0 0 0 0 fa 0 0 0 0 0
0 0
[ 1.760457] wpce775x_send len=3 data=e6 e6 e9
[ 1.772876] wpce775x_recv ... data_in=fe fa 64 0 0 0 0 0 fa 0 0 0 0 0
0 0
Using proto=bare gets around the GETINFO failure, but doesn't help with
the more important GETID failure.
The other issue is that when the serio driver requests up to 16 bytes
over i2c, the controller responds with 16 bytes of data, which appear to
be the 3 flags/X/Y regs plus 13 bytes of irrelevant data. This all gets
passed to psmouse which interprets it 3 bytes at a time as movement
data. Not only does the extra data get interpreted as movement info, but
it causes subsequent real data to be mis-aligned and wrongly interpreted.
[ 115.915558] wpce775x_recv ... data_in=28 1 ff 0 0 0 0 0 9c 0 0 0 0 0 0 0
[ 115.915649] psmouse_process_byte data=28 01 ff rel_x=1 rel_y=1
<--- OK
[ 115.915688] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.915714] psmouse_process_byte data=00 00 9c rel_x=0 rel_y=-156
<--- bad
[ 115.915745] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.915771] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.928269] wpce775x_recv ... data_in=28 1 fe 0 0 0 0 0 9c 0 0 0 0 0 0 0
[ 115.928357] psmouse_process_byte data=00 28 01 rel_x=40 rel_y=-1
<--- wrong
[ 115.928396] psmouse_process_byte data=fe 00 00 rel_x=0 rel_y=0
<--- wrong
[ 115.928426] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.928457] psmouse_process_byte data=9c 00 00 rel_x=0 rel_y=0
[ 115.928484] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.939728] wpce775x_recv ... data_in=28 1 ff 0 0 0 0 0 9c 0 0 0 0 0 0 0
[ 115.939818] psmouse_process_byte data=00 00 28 rel_x=0 rel_y=-40
<--- wrong
[ 115.939857] psmouse_process_byte data=01 ff 00 rel_x=255 rel_y=0
<--- wrong
[ 115.939889] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.939916] psmouse_process_byte data=00 9c 00 rel_x=156 rel_y=0
<--- bad
[ 115.939947] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
[ 115.939972] psmouse_process_byte data=00 00 00 rel_x=0 rel_y=0
Is there a way to get the serio driver to only read 3 bytes of data per
interrupt?
Thanks.
--
Neil
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-08-18 21:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 16:49 [PATCH v2] input: mouse: add qci touchpad driver Neil Leeder
2010-08-12 17:25 ` Stepan Moskovchenko
2010-08-12 17:58 ` Neil Leeder
2010-08-13 2:49 ` Dmitry Torokhov
2010-08-13 21:56 ` Neil Leeder
2010-08-14 0:54 ` Dmitry Torokhov
2010-08-17 17:14 ` Neil Leeder
2010-08-17 18:05 ` Dmitry Torokhov
2010-08-18 21:38 ` Neil Leeder [this message]
2010-08-19 5:33 ` Dmitry Torokhov
2010-08-19 22:19 ` Neil Leeder
2010-08-19 23:35 ` Matthew Garrett
2010-08-20 19:16 ` Neil Leeder
2010-08-25 18:26 ` Neil Leeder
2010-08-26 14:49 ` Dmitry Torokhov
2010-08-26 21:00 ` Neil Leeder
2010-08-13 8:36 ` Datta, Shubhrajyoti
2010-08-13 9:34 ` Trilok Soni
2010-08-26 18:45 ` Neil Leeder
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=4C6C52DE.4040700@codeaurora.org \
--to=nleeder@codeaurora.org \
--cc=dmitry.torokhov@gmail.com \
--cc=horace.fu@quantatw.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=msb@chromium.org \
--cc=stepanm@codeaurora.org \
--cc=tsoni@codeaurora.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).