Thread (20 messages) flat view 20 messages, 3 authors, 2015-08-11

Re: [PATCH 2/9] Input: atmel_mxt_ts - use deep sleep mode when stopped

From: Benjamin Tissoires <hidden>
Date: 2015-08-11 16:29:55

Hi Nick,

On Tue, Aug 11, 2015 at 11:55 AM, Nick Dyer [off-list ref] wrote:
On 11/08/15 15:24, Nick Dyer wrote:
quoted
On 10/08/15 21:11, Benjamin Tissoires wrote:
quoted
I am currently running v4.2-rc6, merged with Dmitry's and Jiri's tree.
This patch completely kills my touchpad on the Pixel 2. No touch
information is sent while the physical button still emits values. You
said that you tested it on this laptop too, so I wonder why mine
refuses to work.
I'm just building that version to see if I can reproduce. Dmitry made some
minor changes when he merged it, but I don't think it should have affected
anything.

Are you able to send me some dmesg output with dyndbg=+pt enabled?
I will do that after lunch if you still need them.
quoted
It would also be useful if you could compile mxt-app and try issuing a
calibrate or reset command to see if that restores touch (let me know if
you need instructions).
I've done some testing and I believe I'm able to reproduce your issue. It
appears to be caused by a bad calibration, i.e. if I run the following
command then the touchpad starts working:

sudo ./mxt-app -d i2c-dev:0-004a --calibrate
Yep, this works with the deep sleep patches applied. On the regular
fedora kernel (without these patches, and after a boot with the kernel
with the patches), it does not make the touchpad back alive, however,
a reset with the mxt-app works.

Thanks for the fast work-around.
(it times out waiting for the calibration complete message when in i2c-dev
mode, but that's expected)

Could you verify this at your end?

The patch under discussion sends a calibrate command as the input device is
opened. However I can see that user space is opening/closing the device 3x
in the space of about a second as X starts up, which may be confusing the
firmware. It might be that we need to wait for the calibration to complete,
I will try adding some code to do that.
Can't you start a worker on open which will keep a ref count on how
many open/close you make and which would do the calibration in the
background without blocking the user-space? This way, you will be able
to guarantee that the calibration will end, and not be re-sent if
there are several open/close in a raw.

Cheers,
Benjamin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help