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 // .
})
}
}
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?).
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xinput in Ubuntu.
https://bugs.launchpad.net/bugs/1796580
Title:
Touchscreen breaks after suspend on Acer Aspire Switch 11
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1796580/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help : https://help.launchpad.net/ListHelp
