Cursor gone after upgrading from 4.2-11 to 4.3-2

[brianhall]

I seem to have lost my cursor after installing the new kernel. I was able to get everything that touchpad.sh does to run successfully, but am still without a cursor. Are there any details I can provide to help troubleshoot? Thanks in advance!

[willmaddrey]

My touchscreen works fine, but my touchpad doesn't work at all. Earlier my touchpad worked but the touchscreen didn't

[brianhall]

This is the same for me. Touchscreen is still working.

On Wed, Jan 6, 2016, 7:44 PM Will Maddrey [email protected] wrote:

My touchscreen works fine, but my touchpad doesn't work at all. Earlier my
touchpad worked but the touchscreen didn't

—
Reply to this email directly or view it on GitHub
#73 (comment).

[raphael]

I've noticed that this happens too - rebooting seems to fix it. I've narrowed it down to the id assigned to the touchpad in X: if that id is anything but 9 then the touchpad won't work. You can see what the id is by running xinput. I would love for someone that understands better the meaning of that id to shed some light....

[willmaddrey]

Even when I reboot, it still is broken for me. I have moved temporally to the linux kernel

[raphael]

Did you check xinput to see what was reported for the Touchpad? would be interesting to see if it's the same issue.

[millserd]

I can confirm this happens for me as well. I checked xinput when the touchpad was not responding and it was assigned id=11. After 2 reboots it is now working with an assigned id=9. The touchscreen always maintained id=10 and always responded.

[raphael]

ok good to know thanks.

[willmaddrey]

My touchpad is id=9, but it still isn't working

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

[willmaddrey]

After another reboot it works, my xinput now:
⎡ 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

[aaron235]

Having the same problem here, it still doesn't work when my trackpad's ID is 9. I diff'd those two outputs, they're the same. I'm gonna be trying some things on my own too, I'll report back if I solve it.

[aaron235]

I think I've pinpointed the issue. I get a line in dmesg during broken-synaptics boots that I don't get during working ones:

[ 7.800707] atmel_mxt_ts i2c-ATML0000:01: Wait for completion timed out.

Also, I've included xinput list --long for both working and non-working.

workingSynaptics.txt
brokenSynaptics.txt

[willmaddrey]

Yeah i also saw the atmel message when logging in, rolling back temporally fixed the problem till it is updated.

[raphael]

I had seen that message too, just not sure how to fix it. The code in this repo shouldn't affect the touchpad at all, it only contains changes to the sound driver. The fact that it's random is puzzling too. I'll try to take another look when I get a chance.

[ehegnes]

I have encountered a great success in making the touchpad work! I'll do some more digging (I think this issue relates to the CHG pin) but I wanted to get this workaround up ASAP so that people may profit from it.

If you reset the maXTouch chip that controls the touchpad using atmel-maxtouch/mxt-app, the touchpad will work again.

Workaround steps:

1. Install atmel-maxtouch/mxt-app (your official repos may have it, but I opted to DL and compile myself)

2. modprobe i2c-dev as root (unless it is already built-in to the kernel. This allows us to access i2c devices through /dev/i2c-*)

3. Discern the i2c bus ID that controls your touchpad. There are a few ways to do this. I ran dmesg | grep -i atmel and took note of the following line:

   input: Atmel maXTouch Touchpad as /devices/pci0000:00/INT3432:00/i2c-7/i2c-ATML0000:01/input/input13

4. Run mxt-app -d i2c-dev:7-004a with elevated privileges. Replace 7 with your bus number, but keep the 004a address the same.

5. You will see a menu as such:

   Version:1.26-15-geae11c3
   Registered i2c-dev adapter:7 address:0x4a
   Command line tool for Atmel maXTouch chips version: 1.26-15-geae11c3
   
   Select one of the options:
   
   Enter L:   (L)oad config file
   Enter S:   (S)ave config file
   Enter I:   Read (I)nfo block
   Enter D:   Rea(D) individual object config
   Enter W:   (W)rite individual object
   Enter T:   Run sel(T)-test
   Enter F:   (F)lash firmware to chip
   Enter B:   (B)ackup the config data to NVM
   Enter R:   (R)eset the maxtouch device
   Enter C:   (C)alibrate the maxtouch device
   Enter M:   Display raw (M)essages
   Enter U:   D(U)mp Diagnostic data
   Enter Q:   (Q)uit the application
   

6. Type R and press Return/Enter to reset the Atmel chip and regain mouse control.

NOTE: If you're like me, and you don't want to type all that junk every time your touchpad stops working, you can script the following command echo -ne 'r\nq\n' | sudo mxt-app -d i2c-dev:7-004a.

[raphael]

This is awesome, thank you! I'll wrap that up in a script and document it. I guess that begs the question of what is supposed to happen at boot time that doesn't...

[ehegnes]

You could try asking the Atmel folk, but I haven't had particularly delightful dealings with them in the past. Maybe it's even worth a post to the LKML?

Later today I should be able to dump the register settings from a working and non-working touchpad for comparison.

Are people experiencing this issue on the vanilla 4.3 kernel as well?

[SimionKreimer]

Thanks ehegnes, that fixed my touchpad (ArchLinux).

[razor-x]

I can confirm following ehegnes steps also got mine working again (ArchLinux).

[recri]

I lose my mouse cursor and rebooting Linux does not recover the cursor, but booting into ChromeOS and then back to Linux does recover the cursor.

I haven't lost the touchpad ever.

I lose the touch screen when I wake after sleep, a simple reboot of Linux fixes that.

Haven't tried any mxt-app hacks yet.

[ehegnes]

I did experience something similar, which was puzzling. I used to be able to reboot into a broken kernel that hanged, and then back into working 4.3, and the cursor would work. I guess that's the long way to flush and reinitialize the Atmel chip.

I have also experienced similar issues with the touchscreen not working after suspend. I haven't bothered to try anything yet, but I'll bet that either unloading the atmel_mxt_ts module before suspend and loading it after resume would solve that (pm-utils has pretty support for this). Alternatively, I'll bet you could reset the chip by using the mxt-app hack on the touchscreen controller instead of the touchpad controller.

[ehegnes]

Is everybody's touchpad connected to i2c-7? It should be, I think, because I²C addresses are not enumerated by the kernel but rather declared explicitly in the C module. This would make writing a global script easier.

[c00w]

I can confirm it happens with a stock kernel as well

[brianhall]

I can confirm that the steps from @ehegnes fixes the problem on a Pixel 2 running Ubuntu 15.10. Also, if you roll this into a script as suggested, don't forget to add the modprobe i2c-dev step!

[raphael]

I added the script script/setup/touchpad/enable-atmel.sh that runs the steps above. Also added a blurb to the README.

[ehegnes]

Oops! Well feel free to nix my PR. Also, it might be worth changing the line to

echo -ne 'r\nq\n' | sudo mxt-app -d i2c-dev:{7,8}-004a

so that the touchscreen chip is also reset. I've experienced issues with it failing after suspend.

Also, I like the cleanup to the directories in script/setup :)

[raphael]

Thank you! I have integrated your script (which was much cleaner) into the one I had slapped together.

[raphael]

It would be cool if there were scripts that created a systemd service and other init system integrations as well. I'll leave that issue opened until then.

[ehegnes]

I spoke too soon! When my touchscreen fails after suspend, resetting the controller (i2c-8) doesn't fix it. Oh well -- no harm, I suppose.

I can write a script to install an OpenRC init script, but I don't have a systemd box to test on. I suppose we have a few options for running a script at boot:

• i2c-dev should could/should be loaded using /etc/modprobe.d
• systemd, upstart, and SysV (I believe) all use /etc/rc.local as the final init script to run before login. sed or tee etc. could add our appropriate line(s). Might be more portable than a service file?
• Other init systems (OpenRC) uses something slightly different, but I'll bet not many others are using OpenRC.
• We could append a line to /etc/profile, but I personally think that's a mite messy.

Any preferences?

[raphael]

Another possibility I guess would be to hook into xinitrc since the touchpad really is only usefull in graphical environments?

[ehegnes]

Ah, another great idea. I suppose people are much less picky about their .xinitrc file being modified. I vote +1 for that, FWIW. I do still believe that i2c-dev should be loaded through modprobe.d as is the case with snd-hda-intel.

It is actually possible to use the mouse in a framebuffer through gpm (which is quite useful in conjunction with a curses web browser), but I doubt anybody uses this functionality.

[raphael]

Agreed on using modprobe.d for loading the modules. I wouldn't worry too much on the non-X use case for the Touchpad - we're not saying it won't work - just that it won't work automatically with the setup script this repo provides. The flip side is that the setup script will just work out of the box for most people which seems like a good trade off to me. Thanks for all the great contributions!

[burntcookie90]

@ehegnes just wanted to mention that my devices are setup to i2c-{0,1}

[raphael]

(oops didn't mean to close) ugh that means the script needs to dynamically figure it out. I guess it could query all the devices listed in /dev/i2c-*, it seems mxt-app is good about reporting an error when accessing the wrong device. The script could read the information block and check the family and variant match...

[ehegnes]

@burntcookie90 Oof, that's a shame. I'll bet the proper controllers IDs could be found using a pretty one-liner with a lot of pipes. grep the lines from dmesg containing 'touchpad' or 'touchscreen' and 'atmel', bash regex 'i2c-[:digit:]' in each line, and pipe the result to cut -d'-' -f2 in order to retrieve the number. I suppose awk could do most of that but I've not exactly mastered awk.

Something like this:

echo $(dmesg | grep -i "touchpad as" | cut -d'-' -f2 | head -c1)
echo $(dmesg | grep -i "touchscreen as" | cut -d'-' -f2 | head -c1)

Then again, @raphael's idea sounds much less convoluted and probably more reliable.

[burntcookie90]

@raphael that does seem like an idea that could work

[raphael]

I just released 4.4 - let's see if the problem still occurs with it,

[recri]

Cursor missing after reboot with 4.4, still gone after second reboot into 4.4, fixed by rebooting in ChromeOS and back to 4.4, no audio in 4.4:

[ 2.477197] haswell-pcm-audio haswell-pcm-audio: error: DMA request channel failed
[ 2.477260] haswell-pcm-audio haswell-pcm-audio: error: failed to load firmware
[ 2.478611] bdw-rt5677 bdw-rt5677: ASoC: CPU DAI System Pin not registered

but, on the positive side, the virtual terminals are displaying again.

[raphael]

You can re-enable the touchpad with the scripts/setup/enable-atmel.sh script. I'm looking into the audio issue, ugh not a dull moment.

[ghost]

I'm running Debian 8 my devices are also i2c-{0,1} a quick change to the script got my touchpad working. My cursor was still missing in 4.3 but a service lightdm restart brought it back and it stayed after the upgrade to 4.4. I can confirm that my touchscreen and touchpad are working and I have my cursor back

[colemickens]

In case anyone is on NixOS, forgot about this and upgraded to Linux 4.3, I have package "mxt_app" in my nixpkgs fork if you need to reset your touchpad.

[raphael]

I've updated the enable-atmel.sh script so looks for the i2c devices that corresponds to the Touchpad dynamically. I've also added setup.sh that configures ~/.xinit.rc to run the script on start.

[raphael]

The script now reconfigures the devices instead of resetting them. The big advantage is that this only needs to be run once so no more messy service or startup hacks. See https://lkml.org/lkml/2016/4/8/536 for the original thread.