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.

[wulvyrn]

If your above method is working for you? That would be good info.

[DerVerruckteFuchs]

My atmel.service currently has WantedBy=multi-user.target sleep.target in it, should it be WantedBy=multi-user.target suspend.target sleep.target or just WantedBy=suspend.target?

Usually the touchscreen won't take input when the screen wakes for me, though I have had a few instances where it stops working after a few seconds after wake and use of the touchscreen.

Chromium has had much fewer issues with killing touchscreen input in comparison to Firefox. The breakdown of most frequent touchscreen disabling in my experience is thus:

Firefox with Grab and Drag extension > Firefox without Grab and Drag extension > Chromium

An interesting occurence I found about an hour or two ago is that touchscreen input can die after sleep/suspend with zathura as well. So that's a third program to add to the list, and it's not a browser. Since it's a light weight pdf reader it might be easier to pin down what's causing the issue.

I have yet to test my method, I didn't realize that atmel.service already handled that. I can test both to see if one works better than the other.

[DerVerruckteFuchs]

Another detail is that with zathura, resetting took a long time to kick in. It took about a couple minutes or more, this occasionally happens with other programs, though it's rather infrequent.

[wulvyrn]

WantedBy=multi-user.target suspend.target
if yours didn't have both, that could be why it's not happy.

multi-user.target is on boot
suspend.target is after sleep

journalctl -xe will display and if if it was reset by saying xx004b reset
or journalctl -xe | grep atmel
for an easier view - it should run when everything is idle. else, best to get a working solution on your device and then verify with other to see if there is logic in it.

[DerVerruckteFuchs]

So I changed that line in atmel.service to WantedBy=multi-user.target suspend.target and rebooted.

What I get with journalctl -xe | grep atmel:

-- Subject: Unit atmel.service has finished start-up
-- Unit atmel.service has finished starting up.
Feb 04 20:13:00 archbook-pixel-ls enable-atmel.sh[1723]: touchpad device i2c-dev:0-004a reset
-- Subject: Unit atmel.service has finished start-up
-- Unit atmel.service has finished starting up.
Feb 04 20:26:09 archbook-pixel-ls enable-atmel.sh[2023]: touchpad device i2c-dev:0-004a reset
-- Subject: Unit atmel.service has finished start-up
-- Unit atmel.service has finished starting up.
Feb 04 20:26:50 archbook-pixel-ls enable-atmel.sh[2343]: touchpad device i2c-dev:0-004a reset
-- Subject: Unit atmel.service has finished start-up
-- Unit atmel.service has finished starting up.
Feb 04 20:29:40 archbook-pixel-ls enable-atmel.sh[2687]: touchpad device i2c-dev:0-004a reset
-- Subject: Unit atmel.service has finished start-up
-- Unit atmel.service has finished starting up.
Feb 04 20:33:18 archbook-pixel-ls enable-atmel.sh[2901]: touchpad device i2c-dev:0-004a reset

The touchpad resets, but the touchscreen does not. It took me about 3 suspend/wake cycles to kill touchscreen input with firefox.

[DerVerruckteFuchs]

So double checked the changes to the enable-atmel.sh script and found a few new ones that I missed.

#!/bin/bash

This script resets the Atmel maXTouch chips that control the touchscreen and

touchpad input devices.

It is recommended for this script to be run by the init system on boot and

after resuming from suspend.

Note the use of "mxt-app" which would have to be available to the init system.

Elevate privileges if necessary

PROMPT=sudo
[ "$UID" -eq 0 ] || exec $PROMPT $SHELL "$0" "$@"

Load i2c-dev module to access I2C devices through /dev

$PROMPT modprobe i2c-dev &>/dev/null

Reset controllers

Touchpad - seems to be using i2c dev 0 or 7

FOUND=0
DEV=0
while [ $FOUND -ne 1 ]; do
OUT=$(echo -ne 'i\nq\n' | $PROMPT mxt-app -d i2c-dev:$DEV-004a 2>/dev/null)
if [[ $OUT == "Atmel maXTouch" ]]; then
FOUND=1
else
((DEV++))
if [ $DEV -gt 15 ]; then
echo touchpad device not found - exiting
exit 1
fi
fi
done
echo -ne 'r\nq\n' | $PROMPT mxt-app -d i2c-dev:$DEV-004a &>/dev/null
echo -ne 'r\nq\n' | $PROMPT mxt-app -d i2c-dev:$((DEV+1))-004b &>/dev/null
echo touchpad device i2c-dev:$DEV-004a reset

After fixing it from this to what's in the repo, journalctl -xe | grep atmel is displaying a reset for both touchpad and touchscreen on wake. I edited the enable-atmel.sh script after the touchscreen input got killed. I'm going to reboot and test if that fixes it.

[wulvyrn]

this is my setup from journalctl -xe | grep atmel

-- Subject: Unit atmel.service has finished start-up
-- Unit atmel.service has finished starting up.
Feb 04 19:53:43 archer enable-atmel.sh[15109]: touchpad device i2c-dev:0-004a reset
Feb 04 19:53:43 archer enable-atmel.sh[15109]: touchpad device i2c-dev:1-004b reset

this is the enable-atmel.sh in the latest repo:

cat /usr/local/bin/enable-atmel.sh
#!/bin/bash

# This script resets the Atmel maXTouch chips that control the touchscreen and
# touchpad input devices.

# It is recommended for this script to be run by the init system on boot and
# after resuming from suspend.

# Note the use of "mxt-app" which would have to be available to the init system.

# Elevate privileges if necessary
PROMPT=sudo
[ "$UID" -eq 0 ] || exec $PROMPT $SHELL "$0" "$@"

# Load `i2c-dev` module to access I2C devices through /dev
$PROMPT modprobe i2c-dev &>/dev/null

# Reset controllers
# Touchpad - seems to be using i2c dev 0 or 7
FOUND=0
DEV=0
while [ $FOUND -ne 1 ]; do
  OUT=$(echo -ne 'i\nq\n' | $PROMPT mxt-app -d i2c-dev:$DEV-004a 2>/dev/null)
  if [[ $OUT == *"Atmel maXTouch"* ]]; then
    FOUND=1
  else
    ((DEV++))
    if [ $DEV -gt 15 ]; then
      echo touchpad device not found - exiting
      exit 1
    fi
  fi
done
echo -ne 'r\nq\n' | $PROMPT mxt-app -d i2c-dev:$DEV-004a &>/dev/null &&
echo touchpad device i2c-dev:$DEV-004a reset
echo -ne 'r\nq\n' | $PROMPT mxt-app -d i2c-dev:$((DEV+1))-004b &>/dev/null && 
echo touchpad device i2c-dev:$((DEV+1))-004b reset

note the last four lines, this was recently a merged change. if it all works, you should see both reset in journalctl -xe or from command line.

[wulvyrn]

a reboot isn't needed. to reload systemctl:

sudo systemctl daemon-reload

[DerVerruckteFuchs]

I went and re-downloaded mxt-app from the repo to make sure I didn't have one out of date. I also ran chmod 755 on it to make sure the permissions matched properly. I rebooted just in case it was necessary to, and to rule out needing to reboot.

[DerVerruckteFuchs]

So both the touchpad and touchscreen are resetting properly, and the touchscreen seemed to just randomly die on me with Firefox running.

[DerVerruckteFuchs]

It came back after awhile. There's a bit of lag on some resets.

[DerVerruckteFuchs]

Double checked it and the touchscreen does definitely reset with a noticeable delay. It ranges from like 5-30 seconds or so I think, sometimes longer it feels. The touchpad has had zero issues with resets. I wonder if there's a way to shorten the delay for the touchscreen, since this feels like it's working well.

[wulvyrn]

the service runs when the system is idle. idle was chosen so as it runs after all the binaries run else when it runs with them, it can fail. i'm not sure why the touchscreen would be lagging as it runs just like on command line in bash.

[DerVerruckteFuchs]

What I mean by "lag" is that it takes a few seconds for the touchscreen to become active/usable. I don't mean sluggish. Other than waiting for the touchscreen to become active, everthing works fine now. Reducing the activation time is the only concern I have now, since touchscreen resets actually work now like their supposed to.

Would laptop-mode-tools delay the touchscreen resets perhaps?

[wulvyrn]

i don't have those installed. they could cause a delay. You could change Type=idle in the service file to another option and see if that makes a difference. just restart the systemctl daemon after saving the change to see it.

[DerVerruckteFuchs]

Disabling and stopping laptop-mode-tools didn't seem to do anything. I tried Type=simple, then Type=forking in the service file, both seemed to fail outright. Type=oneshot with RemainAfterExit=yes seemed about as successful as Type=idle.

[raphael]

The script enable-atmel.sh has been updated to reconfigure the touchpad and touchscreen so they don't need to be manually resetted after a reboot. This removes the need for running a service. So far it's been working great for me, give it a shot.

[ehegnes]

@raphael, thanks so much for this! It's nice to finally have a proper fix instead of that workaround. I have also been experiencing good results with the new one-time script.

[DerVerruckteFuchs]

The new script is working great for me at the moment. If touchscreen support gets flaky again I'll let you know.

[Aesop7]

I still get this issue with the touchscreen. When I run the script I get touchpad device not found - exiting

Currently running 4.9.7-1-ARCH #1 SMP PREEMPT Wed Feb 1 19:33:40 CET 2017 x86_64 GNU/Linux

[raphael]

This is not running the kernel provided here, is that intentional?

[Aesop7]

I guess after reading #63 and seeing support for a lot (most?) of the pixel's features in 4.8 I switched. I didn't realize this kernel version was still being developed (I thought just the scripts were being maintained). Good stuff! I'll try switching back tomorrow and I'll see if it helps.

[raphael]

This kernel does not patch the source anymore but does provide a specific configuration. I'm just wondering whether the default config used by the ArchLinux kernel could be missing some modules. I don't know either way but it may be worth trying out this kernel.

[Aesop7]

I switched over to the Samus kernel. Same issue:

⌁25% [user:~/Desktop] % uname -a                                                       [/dev/pts/0]
Linux Home 4.9.8-7-ph #1 SMP Tue Feb 7 21:08:07 EST 2017 x86_64 GNU/Linux
⌁25% [user:~/Desktop] % bash enable_atmel.sh                                           [/dev/pts/0]
[sudo] password for user: 
touchpad device not found - exiting

[raphael]

OK at least we now know that's not the issue :) - what is the output of xinput?

[Aesop7]

⌁ [user:~/Desktop] % xinput                                                            [/dev/pts/2]
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Atmel maXTouch Touchpad                 	id=9	[slave  pointer  (2)]
⎜   ↳ Atmel maXTouch Touchscreen              	id=10	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ NCM-G102                                	id=8	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=11	[slave  keyboard (3)]

[Aesop7]

Do one of the ID numbers or the numbers in parentheses correspond to something in the script? I noticed this line:
# Touchpad - seems to be using i2c dev 0 or 7

[Aesop7]

FWIW, I just did a fresh install with the latest linux & samus (using archlinux and the AUR) and I'm having the same issues with resuming... both touchscreen and trackpad don't work when I open the laptop back up.