Touchscreen inactive after waking from sleep

[DerVerruckteFuchs]

After booting and logging in the touchscreen takes input like normal. After closing the Pixel's lid and opening it back up to wake it the touchscreen no longer takes input as if it's been deactivated. A reboot fixes the issue temporarily until the next close/open of the lid.

I've been using version 4.4-4 (or 4.4.0-4ph according to uname -r) after upgrading from v4.2-11 (Linux kernel ver. 4.2.8).

My first assumption is that the touchscreen driver might need reset similar to the touchpad, except after sleep/wake instead of at boot.

[wulvyrn]

I'm using archlinux with systemd. The service runs the script on boot up after all the binaries run and after sleep. It has both conditions set in the service file.

could you add suspend.target after sleep.target in the atmel.service file and see if it works for you then? atmel.service is located in /etc/systemd/system. thanks.

[DerVerruckteFuchs]

So I edited /etc/systemd/system/atmel.service to have the line WantedBy=multi-user.target sleep.target suspend.target and rebooted. The touchscreen is still inactive on wake.

edit: I'm also using Arch with systemd, for reference.

[wulvyrn]

good news, i can verify your issue. i mis-read trouchscreen for trackpad. i don't use my touchscreen. i'll dig into it and see what i can figure out.

[wulvyrn]

#73 mentioned the touchscreen not working also after resume. i tried

sudo mxt-app -d i2c-dev:1-004a #1 is my current touchscreen else it could be 8
Version:1.26-15-geae11c3
Registered i2c-dev adapter:1 address:0x4a
Error Remote I/O error (121) writing to i2c
Failed to read ID information

i'm not sure what to suggest next. perhaps @ehegnes might have some insight.

[wulvyrn]

the following command will reset the touchscreen

sudo mxt-app -d i2c-dev:1-004b  

note this if your touchpad is 0 else it's 8 when the touch pad is 7 also note it's 004b not 004a just hit r and then q.

[DerVerruckteFuchs]

Running sudo mxt-app -d i2c-dev:1-004b then hitting r then q seems to run successfully, but the touchscreen still won't take any input after running a few times.

xinput lists my touchscreen as id=10 and touchpad as `id=9'

I looked through my system folders and there is a /dev/i2c-0 through /dev/i2c-8. I tested running sudo mxt-app -d i2c-dev:0-004b, sudo mxt-app -d i2c-dev:8-004b, and tried it with 9-004b and 10-004b at the end for good measure in case the numbers had any relation to the xinput output. Only sudo mxt-app -d i2c-dev:1-004b seemed to work, yet the touchscreen still doesn't take any input.

I'm going to reboot and test sudo mxt-app -d i2c-dev:1-004b again immediately after a sleep/wake to see if that works.

[DerVerruckteFuchs]

So running sudo mxt-app -d i2c-dev:1-004b immeadiately after a sleep/wake works it seems. Maybe having a systemd service automatically run it on wake should do it.

I'm going to try letting my Pixel sleep for a few minutes and see if resetting the touchscreen via sudo mxt-app -d i2c-dev:1-004b still works.

Edit: My trackpad does not work after doing this.

[wulvyrn]

there is an error in the script - i have a fix and will be submitting it. enable-atmel.sh 2nd to the last line should read:

echo -ne 'r\nq\n' | $PROMPT mxt-app -d i2c-dev:$((DEV+1))-004b &>/dev/null 

[DerVerruckteFuchs]

Editing that line in /usr/local/bin/enable-atmel.sh and running sudo systemctl restart atmel.service fixed the trackpad issue.

I tried sleep/waking the device afterwards and still needed to reset the touchscreen with sudo mxt-app -d i2c-dev:1-004b to get it working.

[wulvyrn]

i would reboot and see if you still have it. i also removed the suspend.target out of the service i'm using. the only thing on my system now different than the main repo is that small change to the script.

[wulvyrn]

note there are two lines in the enable-atmel.sh file at the bottom. one for the trackpad 004a and one for the touchscreen 004b.

[DerVerruckteFuchs]

The edit to enable-atmel.sh is still there, and I previously removed suspend.target from atmel.service after finding it didn't seem to do anything to help the touchscreen issue.

Sometimes sudo mxt-app -d i2c-dev:1-004b will not work, but sudo mxt-app -d i2c-dev:8-004b will work instead after booting and sleep/waking.

Another more elusive issue is sometimes the trackpad needs reset with sudo systemctl restart atmel.service after a sleep/wake, but only needs it after one sleep/wake cycle while the Pixel remains on. After rebooting a single reset will need to be done again in similar fashion. However the touchscreen still needs reset after every sleep/wake. The trackpad only gave me this issue a few times and no longer is the issue occuring. I can't seem to replicate it as hard as I try after a reboot or full shut down and boot, so I don't think it's a problem for now.

I get lucky on some sleep/wake cycles and the touchscreen won't need reset. Maybe the Pixel is not in 'complete' sleep mode despite the light bar being off? On some resets, most of the time it's the first one after a reboot, it takes a few seconds for the reset to kick in to get the touchscreen working again.

[DerVerruckteFuchs]

So I let the Pixel sleep a minute and the touchscreen worked fine for a couple seconds before dying on me and needing a reset.

[wulvyrn]

i am getting the same after resume. the touchscreen works for a while and then doesn't.

[DerVerruckteFuchs]

I looked through the new changes in the repo and found I was missing an added Type=idle in the atmel.service file. After adding it, the touchscreen seems to work fine on resume at the moment. I'll play around some more with it to see if it stops working after awhile.

[wulvyrn]

it will fail again as i have Type=idle in my service file. i just had a failed service. until i can reproduce it consistently, it may be hard to troubleshoot.

[DerVerruckteFuchs]

The touchscreen has been working fine for me in the last few minutes I've been playing with it. How long does it take for yours to stop working?

[DerVerruckteFuchs]

So letting it sleep for an hour or more and the touchscreen stops taking input for just the OS.

some journalctl output related to touchscreen/trackpad at the time of waking the Pixel:

Jan 23 00:20:01 archbook-pixel-ls systemd[1]: Started Update man-db cache.

Jan 23 00:20:01 archbook-pixel-ls sudo[5661]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/sbin/modprobe i2c-dev

Jan 23 00:20:01 archbook-pixel-ls sudo[5661]: pam_unix(sudo:session): session opened for user root by (uid=0)

Jan 23 00:20:01 archbook-pixel-ls sudo[5661]: pam_unix(sudo:session): session closed for user root Jan 23 00:20:01 archbook-pixel-ls sudo[5665]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/local/bin/mxt-app -d i2c-dev:0-004a

Jan 23 00:20:01 archbook-pixel-ls sudo[5665]: pam_unix(sudo:session): session opened for user root by (uid=0)

Jan 23 00:20:01 archbook-pixel-ls sudo[5665]: pam_unix(sudo:session): session closed for user root

Jan 23 00:20:01 archbook-pixel-ls sudo[5668]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/local/bin/mxt-app -d i2c-dev:0-004a

Jan 23 00:20:01 archbook-pixel-ls sudo[5668]: pam_unix(sudo:session): session opened for user root by (uid=0)

Jan 23 00:20:01 archbook-pixel-ls sudo[5668]: pam_unix(sudo:session): session closed for user root

Jan 23 00:20:01 archbook-pixel-ls sudo[5671]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/local/bin/mxt-app -d i2c-dev:1-004b

Jan 23 00:20:01 archbook-pixel-ls sudo[5671]: pam_unix(sudo:session): session opened for user root by (uid=0)

Jan 23 00:20:01 archbook-pixel-ls sudo[5671]: pam_unix(sudo:session): session closed for user root

Jan 23 00:20:01 archbook-pixel-ls enable-atmel.sh[5470]: touchpad device i2c-dev:0-004a reset

I had left Chromium open when I put the laptop to sleep/suspend. Chromium oddly enough still takes touchscreen input while the OS does not. I'm going to reset the touchscreen and test whether or not that Chromium is causing the issue.

I may also test Firefox since I am using the Grab and Drag extension for touch input and that's what I normally leave open instead of chromium. It could be a touch event focus stealing issue.

edit: double checking the journalctl output and something along the lines of touchscreen device i2c-dev:1-004b reset is noticeably absent. I'm not sure that's an issue though as running sudo mxt-app -d i2c-dev:1-004b to reset the touchscreen and rerunning journalctl -b does not have touchscreen device i2c-dev:1-004b reset present in the logs afterwards either.

[colemickens]

What input driver are you using in X?

[wulvyrn]

i'm using just xf86-input-libinput and my trackpad is happy and i just figured out how to right click!

[DerVerruckteFuchs]

I also have xf86-input-libinput along with xf86-input-synaptics so I can have tap-to-click enabled.

[colemickens]

Does X actually use both simultaneously? Either way, libinput supports tap-to-click.

Regardless, I think that there is a bug with Chromium and how it handles libinput events. I've actually been having issues with various input mechanisms and Chromium for some months now. It might be related: https://code.google.com/p/chromium/issues/detail?id=519114

[DerVerruckteFuchs]

Both seemed to work fine for me. I assumed I needed synaptics for tap-to-click, but all libinput needed was a proper xorg config file for that. Two finger tap gives me right clicks now like I want, so I'll stick to libinput since that's all I need. I removed synaptics to make further troubleshooting easier.

[wulvyrn]

if you want to open in tab using chromium, it's control key + tap the bottom middle of the touch pad.

[colemickens]

@wulvyrn ? Ctrl + click is always open in new tab in Chromium.

[DerVerruckteFuchs]

When the problem first showed up for me I was using Firefox at the time. Chromium was not even open. I'm going to see if I can replicate the issue with Firefox.

So ctrl+middle tap does what two finger tap did with synaptics. So I have two finger tap doing right click like I want plus that, which is nice.

Weirdly enough Chromium kept crashing when I would scroll pages before a reboot. I'm not sure if that's related to the current issue though. It's not crashing now at all though.

[DerVerruckteFuchs]

So I was able to replicate the issue with Firefox. Having Firefox open then a following sleep/wake cycle kills touchscreen input. I've been using the Grab and Drag extension to be able to use the touchscreen with Firefox. I'm going to remove the extension to see if I still have problems after that.

[DerVerruckteFuchs]

Alright, so removing the extension seems to eliminate the problem. I re-added the Grab and Drag extension to Firefox and after a sleep/wake cycle it killed touchscreen input again.

[DerVerruckteFuchs]

Further testing without Grab and Drag and keeping Firefox open, I can still lose touchscreen input after a sleep/wake. I'm now going to try some sleep/wake cycles without any browsers/applications open to see if I still have issues. It could be two separate problems with each browser, or just an OS/driver issue.

[wulvyrn]

@colemikens - true on ChromeOS. With just libinput, I could only get it to ctk+ tap on the bottom middle. Anywhere else on the touchpad and no go.