linux-kernel - Re: [PATCH v2] input: mouse: add qci touchpad driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/