Ubuntu
linux package

Touchscreen breaks after suspend on Acer Aspire Switch 11

Bug #1796580 reported by Matthijs Kooijman on 2018-10-07

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	linux (Ubuntu)	Expired	Medium	Unassigned

Bug Description

I'm not entirely sure this bug belongs in package xinput, but I'm following the lead of https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1275416, which describes the same symptoms (but on other hardware, so likely a different underlying problem).

On this notebook, the touchscreen works well out of the box. But as soon as I suspend (by pressing the power button or closing the lid) and resume again, the touch screen no longer works. Kernel and Xorg logs show no indication of any problem, xinput still lists the touchscreen, but it just no longer works.

The touchscreen can be made to work again by reloading the hid_multitouch module (that works by unloading and reloading after a resume, or by unloading the module before suspend and reloading it after resume).

I tried updating the bios from v1.03 to the latest v1.04 (no changelog available), but that did not change the problem.

I'm attaching a dmesg.txt in addition to the stuff ubuntu-bug collected. In this dmesg log, I've shown a full boot, a suspend (breaking the touchscreen), a module reload (fixing the touchscreen), then a module unload, suspend and module reload, after which the touchscreen also works (I've added annotations to the log to indicate what happens when). The log also shows some USB-related errors after suspend, but that seems to be about the bluetooth adapter (looking at the usb ids), so I think these are unrelated.

The touchscreen in question seems to be connected through I2c, according to dmesg:

[ 4.561527] input: SYNA7508:00 06CB:77B2 Pen as /devices/pci0000:00/INT33C3:00/i2c-1/i2c-SYNA7508:00/0018:06CB:77B2.0002/input/input8
[ 4.561741] input: SYNA7508:00 06CB:77B2 as /devices/pci0000:00/INT33C3:00/i2c-1/i2c-SYNA7508:00/0018:06CB:77B2.0002/input/input9
[ 4.561917] hid-multitouch 0018:06CB:77B2.0002: input,hidraw1: I2C HID v1.00 Mouse [SYNA7508:00 06CB:77B2] on i2c-SYNA7508:00

I realize that this is not enough information to diagnose and fix the problem, but I'd gladly receive some suggestions on debug strategies to dig into this issue.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xinput 1.6.2-1build1
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sun Oct 7 19:40:05 2018
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
GraphicsCard:
Intel Corporation Device [8086:0a1e] (rev 0b) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device [1025:0930]
InstallationDate: Installed on 2018-10-06 (0 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
MachineType: Acer Aspire SW5-171P
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-36-generic root=UUID=4893a2e6-84af-4d45-8e31-773e622c36c6 ro quiet splash vt.handoff=1
SourcePackage: xinput
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/7/2014
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: V1.04
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: Longchamp_S
dmi.board.vendor: Acer
dmi.board.version: V1.04
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnInsydeCorp.:bvrV1.04:bd11/7/2014:svnAcer:pnAspireSW5-171P:pvrV1.04:rvnAcer:rnLongchamp_S:rvrV1.04:cvnAcer:ct10:cvrChassisVersion:
dmi.product.family: Haswell-Y System
dmi.product.name: Aspire SW5-171P
dmi.product.version: V1.04
dmi.sys.vendor: Acer
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.91-2
version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~18.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~18.04.1
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2

See original description

Tags:

Revision history for this message

Matthijs Kooijman (matthijskooijman) wrote on 2018-10-07:

dmesg.txt Edit (68.0 KiB, text/plain)
CurrentDmesg.txt Edit (55.2 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (345 bytes, text/plain; charset="utf-8")
DpkgLog.txt Edit (1.3 MiB, text/plain; charset="utf-8")
Lspci.txt Edit (8.4 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (487 bytes, text/plain; charset="utf-8")
MonitorsUser.xml.txt Edit (552 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (4.4 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.1 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (310 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (3.2 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (7.2 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (192.4 KiB, text/plain; charset="utf-8")
XorgLog.txt Edit (40.5 KiB, text/plain; charset="utf-8")
XorgLogOld.txt Edit (64.8 KiB, text/plain; charset="utf-8")
Xrandr.txt Edit (20.0 KiB, text/plain; charset="utf-8")
xdpyinfo.txt Edit (18.6 KiB, text/plain; charset="utf-8")

Matthijs Kooijman (matthijskooijman) on 2018-10-07

description:

updated

Revision history for this message

Matthijs Kooijman (matthijskooijman) wrote on 2018-10-07:

I dug around a bit, and found that the touchscreen can also be fixed by reloading the ic2_hid module.

It also works to reinitialize just the hid driver for the touchscreen (rather than reloading the entire module) by running:

echo 0018:06CB:77B2.000C > /sys/bus/hid/drivers/hid-multitouch/unbind
echo 0018:06CB:77B2.000C > /sys/bus/hid/drivers/hid-multitouch/bind

Disabling and re-enabling the device with xinput does *not* work.

Revision history for this message

Matthijs Kooijman (matthijskooijman) wrote on 2018-10-07:

Download full text (4.4 KiB)

I also ran the i2c_hid module with debug enabled (`modprobe i2c_hid debug=1`), which gives a bit of insight in what commands are sent to the touch screen. On a suspend, it seems to send a sleep command. On a resume, it sends a power on command, followed by a reset command (which is properly acknowledge through an empty interrupt, as suggested by the kernel sources). After that, no further activity happens for the touch screen (its interrupt also does not trigger according to /proc/interrupts).

I wonder if this device perhaps needs another power on command, or needs to be reconfigured (setting report descriptors?) after a reset? I can't quite find how to do this manually, so I might need to modify the kernel module for that. Or perhaps try to sniff the windows driver to see how that handles resume?

Since this device is autodetected through ACPI, I dumped and decompiled the system's ACPI tables. The part about this device is here:

    Scope (_SB.PCI0.I2C1)
    {
        Device (TPL4)
        {
            Name (_HID, "SYNA7508") // _HID: Hardware ID
            Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID: Compatible ID
            Name (_UID, One) // _UID: Unique ID
            Name (_S0W, 0x04) // _S0W: S0 Device Wake State
            Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
            {
                If ((Arg0 == ToUUID ("3cdff6f7-4267-4555-ad05-b30a3d8938de") /* HID I2C Device */))
                {
                    If ((Arg2 == Zero))
                    {
                        If ((Arg1 == One))
                        {
                            Return (Buffer (One)
                            {
                                 0x03 // .
                            })
                        }
                        Else
                        {
                            Return (Buffer (One)
                            {
                                 0x00 // .
                            })
                        }
                    }

                    If ((Arg2 == One))
                    {
                        Return (0x20)
                    }
                }
                Else
                {
                    Return (Buffer (One)
                    {
                         0x00 // .
                    })
                }
            }

Since this device is autodetected through ACPI, I dumped and decompiled the system's ACPI tables. The part about this device is here:

Scope (_SB.PCI0.I2C1)
    {
        Device (TPL4)
        {
            Name (_HID, "SYNA7508")  // _HID: Hardware ID
            Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */)  // _CID: Compatible ID
            Name (_UID, One)  // _UID: Unique ID
            Name (_S0W, 0x04)  // _S0W: S0 Device Wake State
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If ((Arg0 == ToUUID ("3cdff6f7-4267-4555-ad05-b30a3d8938de") /* HID I2C Device */))
                {
                    If ((Arg2 == Zero))
                    {
                        If ((Arg1 == One))
                        {
                            Return (Buffer (One)
                            {
                                 0x03                                             // .
                            })
                        }
                        Else
                        {
                            Return (Buffer (One)
                            {
                                 0x00                                             // .
                            })
                        }
                    }

If ((Arg2 == One))
                    {
                        Return (0x20)
                    }
                }
                Else
                {
                    Return (Buffer (One)
                    {
                         0x00                                             // .
                    })
                }
            }

Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (((SDS1 & 0x0200) == 0x0200))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (SBFI, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0020, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                    Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
                    {
                        0x00000022,
                    }
                    GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionInputOnly,
                        "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                        )
                        {   // Pin list
                            0x0026
                        }
                })
                Return (SBFI) /* \_SB_.PCI0.I2C1.TPL4._CRS.SBFI */
            }
        }
    }

In the last block, it describes the I2c address and interrupt that is being used (also shown in /proc/interrupts). However, it also describes some GPIO being relevant, but AFAICS the i2c_hid driver does not handle any GPIOs, so this GPIO might be ignored (or might be handled by an upper layer of ACPI). I wonder if this pin might be the subject of a problem similar to the one fixed by https://marc.info/?l=linux-gpio&m=147610677825233&w=2 (but that fixes the intel pinctrl driver, but I think there are no pinctrl drivers involved here). I couldn't figure out how to get the state of a GPIO pin, though (other than exporting it to sysfs, which did not work, probably because the pin is in use?).

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2018-10-08:

you could try installing newer mainline kernels to see if they help

http://kernel.ubuntu.com/~kernel-ppa/mainline/

affects:	xinput (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status:	New → Incomplete

Revision history for this message

Matthijs Kooijman (matthijskooijman) wrote on 2018-10-08:

Good call, thanks!

This turns out to be fixed in the latest mainline kernel. Looking at the git log for the i2c_hid driver, I found this commit which I suspect is the fix for my problem.

https://github.com/torvalds/linux/commit/52cf93e63ee672a92f349edc6ddad86ec8808fd8
https://patchwork.kernel.org/patch/10589793/

This fix first appeared in the 4.19-rc4 kernel. I tested 4.19-rc3, which is broken while 4.19-rc4 works, which supports my suspicion. I also tested 4.15.0-37.40 (from bionic proposed), which has this same fix backported and also works.

I guess this issue can be closed / marked as fix released, but I'm not sure how exactly, so I'll leave that to others.

Joseph Salisbury (jsalisbury) on 2018-10-09

Changed in linux (Ubuntu):
importance:	Undecided → Medium

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-12-09:

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status:	Incomplete → Expired

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

Bug watches keep track of this bug in other bug trackers.

Ubuntulinux package

Touchscreen breaks after suspend on Acer Aspire Switch 11

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
linux package