Re: [PATCH 00/15] atmel_mxt_ts - device tree, bootloader, etc

[Stephen Warren]

On 07/25/2014 08:10 AM, Nick Dyer wrote:
> On 24/07/14 22:19, Stephen Warren wrote:
...
> > I've uploaded 2 logs to:
> >
> > http://avon.wwwdotorg.org/downloads/mxt-logs/
> > (note there's no directory indexing, so manually add the filenames below to
> > the URL)
> >
> > mxt-save-no-movement.xml
> >
> > This is with the whole series applied. Neither mouse movement nor clicks
> > works. I tried mxt-app --reset and it made no difference to the dump results.
> >
> > mxt-save-move-ok-no-clicking.xml
> >
> > This is with "Input: atmel_mxt_ts - use deep sleep mode when stopped"
> > reverted; mouse movement works, but clicking doesn't.
>
> Great, this has identified the issue with mouse movement (touch).
>
> The config programmed into the NVRAM on your touch controller has the first
> byte of the T9 touchscreen object set to zero. This is the CTRL byte which
> enables/disables the touch object and what it reports. It is relying on
> this to enable the touchscreen on resume:
>
> https://github.com/dtor/input/blob/9d8dc3e529/drivers/input/touchscreen/atmel_mxt_ts.c#L2005-L2006
>
> My "use deep sleep mode when stopped" patch stops the driver writing to the
> T9.CTRL byte, so whatever config you have in NVRAM for that byte will be
> used (ie zero, disabled). Going forward, deep sleep is more generic.
> Indeed, newer chips do not have T9 at all, or they might be using other
> touch objects. The deep sleep mode is a lower power state to be in, and is
> what Atmel recommends.
>
> However, it does mean changing the maxtouch cfg - you can write the 0x83 to
> the first byte of T9 and save it to NVRAM, by doing:
>
> mxt-app [device] -W -T9 83
> mxt-app [device] --backup

If I do that, then both mouse movement and "touch" clicks work:-)

(Dmitry, I guess that means it's fine to go ahead and apply "Input: 
atmel_mxt_ts - use deep sleep mode when stopped".)

I wonder why the configuration NVRAM in my device was incorrect though? 
I'm CCing a few ChromeOS people to try and find out any relevant history 
for the touchpad NVRAM settings on Venice2. Perhaps this is simply 
something that wasn't noticed because the driver used to initialize this 
configuration bit, so nobody realized the config in NVRAM was wrong.

...
> About the clicking - what does getevent -lp show? It should show the
> BTN_LEFT key. If that is working correctly, then the driver isn't parsing
> the messages correctly, it would be useful if you could add a
> mxt_dump_message() call to mxt_input_button() and capture some dmesg output
> of pressing the button.

I'm not sure what getevent is, but I think I tracked down the issue anyway.

With the NVRAM config fix you mentioned, "touch" clicks work OK. 
However, as such as I do a "physical" click (push the touchpad down), 
all kinds of click stop working. I think the answer lies in evtest logs:

First "touch" click (with touch pressure/position events removed):

> Event: time 1406318070.891773, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
> Event: time 1406318070.891773, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
...
> Event: time 1406318070.941752, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
> Event: time 1406318070.941752, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0

The second "touch" click generates the same events. Note how all the 
events are correctly mirrored between down/up events.

Now, the first "physical" click:

> Event: time 1406318085.303424, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
...
> Event: time 1406318085.319818, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
> Event: time 1406318085.319818, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
...
> Event: time 1406318085.515763, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
> Event: time 1406318085.515763, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0

Note the extra BTN_LEFT down event, which has no corresponding "up" 
event. After this, subsequent "physical" clicks don't generate any more 
BTN_LEFT events (down or up) at all, and a USB mouse's BTN_LEFT events 
are ignored, I suppose since the system still thinks the touchpad's left 
button is being held down.

Is this a driver bug (not generating the correct BTN_LEFT events), or 
some other touchpad HW/NVRAM configuration problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/