我正在开发一个嵌入式系统，具备触摸屏幕。触摸屏幕既能作为输入又能作为输出，具有图形化输出的“虚拟”键盘覆盖。
我已经有一个工作正常的设备驱动程序，可以从触摸传感器读取输入并正确地将其转换为按键输入，该驱动程序是在kernel.org上的指南的帮助下创建的。我想扩展这个驱动程序，使其还能处理向屏幕输出的图像。
我希望支持getty和X，同时尽量避免重复。我运行一个最小的Debian变体，并进行了精选软件包，例如最小的X。请注意，我没有打算将此驱动程序尝试放入存储库流程中，尽管我可能会将其发布在公共GitHub存储库上。
目前通过一种糟糕的解决方法来输出屏幕图像：引导选项强制将呈现到CPU的嵌入式图形硬件，尽管它未连接到显示器，并且一个守护进程不断地屏幕抓取该缓冲区，修改少量预定义像素以创建键盘视觉效果，并将其推送到真实屏幕上。
这起初只是一个概念的证明，证明我确实理解屏幕设备希望的语言，但显然并不是最佳解决方案。
我的任何硬件都没有类似于3D加速的东西，所以我得出结论，这可能不是我想要的。
我应该使用哪个子系统/API？我认为缺少的术语阻碍了我的搜索，但任何有关如何完成此操作的更多信息都将不胜感激。
硬件详细信息（可能不相关）：CPU和屏幕通过类似8080的并行协议进行通信，CPU本身不支持该协议，因此我正在使用GPIO进行仿真（通过mmap操纵寄存器）。
发送完整屏幕图像需要约20毫秒，但从嵌入式图形缓冲区获取完整副本需要约180毫秒，因此跳过该步骤是最重要的目标。屏幕硬件包括足够的 SGRAM内存来保存整个帧的数据，并支持编写矩形子区域，因此希望添加钩子以仅更新已更改的屏幕部分。
屏幕对于输入数据的时间没有特别要求。触摸传感器输入由专门设计的IC处理，并通过I²C与CPU通信，而CPU支持此协议。目前的驱动程序使用
我已经有一个工作正常的设备驱动程序，可以从触摸传感器读取输入并正确地将其转换为按键输入，该驱动程序是在kernel.org上的指南的帮助下创建的。我想扩展这个驱动程序，使其还能处理向屏幕输出的图像。
我希望支持getty和X，同时尽量避免重复。我运行一个最小的Debian变体，并进行了精选软件包，例如最小的X。请注意，我没有打算将此驱动程序尝试放入存储库流程中，尽管我可能会将其发布在公共GitHub存储库上。
目前通过一种糟糕的解决方法来输出屏幕图像：引导选项强制将呈现到CPU的嵌入式图形硬件，尽管它未连接到显示器，并且一个守护进程不断地屏幕抓取该缓冲区，修改少量预定义像素以创建键盘视觉效果，并将其推送到真实屏幕上。
这起初只是一个概念的证明，证明我确实理解屏幕设备希望的语言，但显然并不是最佳解决方案。
kernel.org还有一个“DRM”设备驱动程序指南，但这似乎对我的硬件来说过于繁琐：Linux DRM层包含旨在支持复杂图形设备需求的代码，通常包含适合于3D图形加速的可编程流水线。
我的任何硬件都没有类似于3D加速的东西，所以我得出结论，这可能不是我想要的。
我应该使用哪个子系统/API？我认为缺少的术语阻碍了我的搜索，但任何有关如何完成此操作的更多信息都将不胜感激。
硬件详细信息（可能不相关）：CPU和屏幕通过类似8080的并行协议进行通信，CPU本身不支持该协议，因此我正在使用GPIO进行仿真（通过mmap操纵寄存器）。
发送完整屏幕图像需要约20毫秒，但从嵌入式图形缓冲区获取完整副本需要约180毫秒，因此跳过该步骤是最重要的目标。屏幕硬件包括足够的 SGRAM内存来保存整个帧的数据，并支持编写矩形子区域，因此希望添加钩子以仅更新已更改的屏幕部分。
屏幕对于输入数据的时间没有特别要求。触摸传感器输入由专门设计的IC处理，并通过I²C与CPU通信，而CPU支持此协议。目前的驱动程序使用
linux/input-polldev.h接口。CPU是Broadcom BCM2835，屏幕是带有嵌入式Himax HX8357控制器的TFT，触摸屏传感器解码器是ST STMPE610，在HX8357和BCM2835之间还有一个电压级移器（Nexperia 74LVCH245A）。如需更多详细信息，请联系我们。