从触摸屏唤醒在嵌入式 Linux 中不起作用

Question

我正在开发嵌入式Linux（内核5.10.24），并且有一个基于GT911的触摸屏。 触摸屏现在工作正常。

然后我尝试测试该系统中的挂起/恢复。 有一个RTC，配置为120秒唤醒系统，效果也很好，触摸屏在挂起时也是黑色的，恢复后又恢复工作。

目前，我想通过触摸屏来唤醒系统，但失败了。 我发现设备树没有启用滑动唤醒功能，所以我按如下方式更改了 dts，

goodix,slide-wakeup = <1>;

我可以从内核日志中看到唤醒已启用。

goodix-ts 0-0004: slide-wakeup enabled
goodix-ts 0-0004: INT num 36, trigger type:2
goodix-ts 0-0004: slide wakeup enabled

我可以看到

/sys/class/wakeup/*

显示了有关gt9xx的名称。

当我将系统置于挂起模式时，我仍然无法通过触摸屏幕唤醒系统。

我对 Linux 挂起/恢复架构不太熟悉，我想知道从触摸屏唤醒系统需要什么。

gt9xx代码来自https://github.com/goodix/gt9xx_driver_android/blob/master/gt9xx.c

其功能如下，

static int gtp_wakeup_sleep(struct goodix_ts_data *ts)
{
    u8 retry = 0;
    int ret = -1;

    while (retry++ < 10) {
        gtp_int_output(ts, 1);
        usleep_range(5000, 6000);

        ret = gtp_i2c_test(ts->client);
        if (!ret) {
            dev_dbg(&ts->client->dev, "Success wakeup sleep\n");

            gtp_int_sync(ts, 25);
            if (ts->pdata->esd_protect)
                gtp_init_ext_watchdog(ts->client);

            return ret;
        }
        gtp_reset_guitar(ts->client, 20);
    }

    dev_err(&ts->client->dev, "Failed wakeup from sleep mode\n");
    return -EINVAL;
}

并且在

 gtp_probe()

它执行以下操作来设置唤醒。

    gtp_work_control_enable(ts, false);
    if (ts->pdata->slide_wakeup) {
        dev_info(&client->dev, "slide wakeup enabled\n");
        ret = enable_irq_wake(client->irq);
        if (ret < 0)
            dev_err(&client->dev, "Failed set irq wake\n");
    }

为了测试代码，我做了以下操作，

echo standby > /sys/power/state

。 系统已暂停。
我触摸屏幕（点击并滑动）来唤醒系统，但失败了。
系统在 120 秒后被 RTC 闹钟定时器唤醒。

Answer 1

我来这里试图调试一个表面上相似的问题，并且可能与此处OP的硬件+操作系统设置相关，也可能不相关......所以，对于Google基于类似查询引导到这里的人：

首先，我在 Ask Ubuntu 找到了一个 主题，该主题涉及 USB 设备活动的“从挂起状态唤醒”。它的详细描述使我能够为我的设置启用“从挂起唤醒”，它更像桌面，并且在 USB 上有一个 eGalaxTouch 电容传感器+控制器。而且，结论是，这对我的具体情况没有帮助。

我偶然发现的怪癖实际上在其他地方。 当屏幕变为空白（通过 DPMS 操作）时，即系统正在运行且未处于 ACPI S3 挂起状态时，屏幕无法通过触摸屏幕来“取消空白”。显然，此时 TS 控制器完全处于活动状态，并将事件移交给内核的“输入”子系统。就我而言，问题似乎出在 Gnome 桌面环境中，即屏幕空白时等待用户输入的某些部分（gdm3 锁屏？） - 在旧的 Gnome bugzilla 中有一张票据，已关闭与“不是错误”，即这似乎是一种理想的节能行为......无论如何在维护者的宇宙中。在 Debian 和 Ubuntu 中也是如此。

目前我不确定原生 X.org 与 XWayland 是否有区别。

xinput

（来自包

xinput

）报告的设备列表确实存在差异 - 在 XWayland 下，您获得的只是 Wayland“合成器”提供的虚拟输入设备。而在 X 下，您可以更接近物理设备。不确定这是否重要。
其他有用的故障排除工具可能是 

lsinput

 包中的 

input-events

 和 

input-utils

 - 这取决于裸 Linux 内核，而不是 XWindows 或 Wayland。