[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C6C52DE.4040700@codeaurora.org>
Date: Wed, 18 Aug 2010 17:38:38 -0400
From: Neil Leeder <nleeder@...eaurora.org>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
CC: Stepan Moskovchenko <stepanm@...eaurora.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Horace Fu <horace.fu@...ntatw.com>,
Mandeep Singh Baines <msb@...omium.org>,
Trilok Soni <tsoni@...eaurora.org>
Subject: Re: [PATCH v2] input: mouse: add qci touchpad driver
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists