On 24/07/14 22:19, Stephen Warren wrote: >> mxt-app [device] --save fail.xcfg > > That command always experiences a timeout error, but still seems to dump > something out. Is this timeout error an issue? I'm a little hesitant to > modify the COMMSCONFIG settings until I know load/save are really working. > > root@localhost:~/obp-utils# ./mxt-app -d i2c-dev:1-004b --save > ~/mxt-save-no-movement.xml > Version:1.16-65-g0a4c > Registered i2c-dev adapter:1 address:0x4b > Opening config file /root/mxt-save-no-movement.xml... > REPORTALL command issued > Timeout The timeout is benign. In the mode that we're using it here, it is unable to query the chip to query the configuration checksum, hence in the file it says "CHECKSUM=0x000000". This won't affect --load/--save. > 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 It should still work fine with the older driver, it will just be enabled for an additional short time during bootup before the first call to mxt_input_open(). 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. Thanks for your patience in debugging this. -- 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
