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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ