首页
/ LVGL项目中触摸屏坐标转换问题的技术解析

LVGL项目中触摸屏坐标转换问题的技术解析

2025-05-11 06:34:31作者:冯爽妲Honey

背景介绍

在嵌入式GUI开发中,LVGL作为一个轻量级图形库被广泛应用。其中,触摸屏输入与显示旋转的协调工作是一个常见的技术难点。本文深入分析LVGL v9.2.2版本中触摸屏坐标转换与显示旋转的交互问题,帮助开发者理解其工作原理并找到解决方案。

问题现象

当使用LVGL的显示旋转功能时,特别是设置为90度或270度旋转时,触摸屏输入坐标与实际显示位置会出现不匹配的情况。具体表现为:

  1. 在默认0度旋转(240x320竖屏)时,触摸屏坐标(0,0)正确对应显示左上角
  2. 当旋转90度(变为320x240横屏)后,触摸屏坐标(0,0)却对应到显示的左下角而非预期的左上角

技术原理分析

LVGL内部通过indev_pointer_proc函数处理触摸屏输入坐标转换。该函数包含两个关键转换步骤:

  1. 对于180度和270度旋转,先对坐标进行镜像翻转
  2. 对于90度和270度旋转,执行坐标交换和调整

核心转换代码如下:

if(disp->rotation == LV_DISPLAY_ROTATION_90 || disp->rotation == LV_DISPLAY_ROTATION_270) {
    int32_t tmp = data->point.y;
    data->point.y = data->point.x;
    data->point.x = disp->ver_res - tmp - 1;
}

这个转换实际上实现了一个标准的90度顺时针坐标旋转。然而,当与显示驱动配合使用时,特别是与TFT_eSPI这类驱动库结合时,可能会出现方向不一致的问题。

根本原因

问题根源在于LVGL与底层显示驱动对旋转方向的理解不一致:

  1. LVGL内部假设LV_DISPLAY_ROTATION_90代表显示内容逆时针旋转90度
  2. 但许多显示驱动(如TFT_eSPI)实际执行的是顺时针旋转
  3. 这种方向上的不一致导致触摸坐标转换结果与预期不符

解决方案

开发者可以采用以下几种方法解决此问题:

方法一:修改触摸屏回调函数

在触摸屏读取回调中预先对坐标进行180度旋转补偿:

// 对于90度和270度旋转情况
data->point.x = touch_width - data->point.x - 1;
data->point.y = touch_height - data->point.y - 1;

方法二:调整LVGL内部转换逻辑

修改lv_indev.c中的坐标转换代码,将90度和270度情况下的转换方向反转:

// 修改后的90度转换
int32_t tmp = data->point.y;
data->point.y = disp->hor_res - data->point.x - 1;
data->point.x = tmp;

方法三:协调显示驱动旋转方向

如果使用TFT_eSPI等驱动,可以尝试调整驱动的旋转方向设置,使其与LVGL期望的旋转方向一致。

最佳实践建议

  1. 在项目初期明确显示旋转方向的定义标准
  2. 统一LVGL与底层驱动的旋转方向理解
  3. 编写测试代码验证触摸坐标与显示位置的对应关系
  4. 考虑封装自定义的坐标转换函数以提高代码可维护性

总结

LVGL的触摸屏坐标转换机制设计合理,但在与特定显示驱动配合时可能出现方向不一致问题。理解其内部转换原理后,开发者可以通过多种方式解决这一问题。建议在实际项目中采用方法一或方法三,因为它们对LVGL核心代码的侵入性最小,同时也能有效解决问题。

对于长期解决方案,建议LVGL项目团队考虑增加旋转方向配置选项,或在文档中更明确地说明旋转方向的定义,以帮助开发者避免此类问题。

登录后查看全文

项目优选

收起
kernelkernel
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
471
465
kernelkernel
deepin linux kernel
C
32
16
atomcodeatomcode
Claude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started
Rust
2.09 K
218
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
700
1.4 K
docsdocs
暂无描述
Dockerfile
780
5.08 K
pytorchpytorch
Ascend Extension for PyTorch
Python
758
968
flutter_flutterflutter_flutter
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.04 K
271
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
880
2.03 K
mindquantummindquantum
MindQuantum is a general software library supporting the development of applications for quantum computation.
Python
183
111
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
1.11 K
682