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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux