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
