weston问题定位

最新推荐文章于 2025-05-08 14:21:55 发布

jufeng1307

最新推荐文章于 2025-05-08 14:21:55 发布

阅读量1.8k

点赞数 2

文章标签： qt 开发语言

本文链接：https://blog.csdn.net/ganxin7932508/article/details/121271773

版权

Weston问题定位分享

前言：

此问题出现的Qt版本为5.9.0，weston版本为3.0.0

1、问题

在IMX8MQ平台下，采用米尔厂家提供的固件，进行qt界面开发；在界面中使用到QComboBox类时，会出现如何下情况；

点击下拉列表，弹出各个选项后，选择其中一个选项，下拉列表不退出；操作界面的其他按钮时，下拉列表也不退出，此时下来列表不能再使用。

qtApp与weston交互总图

2.定位问题的切入点

可能存在问题的地方

a.qt库GUI存在的bug
b.集成到qt库中wayland的client
c.Weston里的窗口管理系统存在问题

（上述问题的分析结果如下：weston存在bug，即在处理窗口管理中处理存在问题，本该将控件renderer成隐藏的，却没有将它renderer成隐藏；处理方法：由于weston属于第三方开源库比较复杂投入分析解决weston bug的产出比较差，而且使用的也是比较旧的版本，故升级weston库进行验证解决）

3.使用同一个程序缩小范围：

用qt提供的用例combowidgetmapper，关闭weston后，此问题不在；如此可以知道不是qt库GUI的问题造成的上述问题的出现。

可能存在问题的地方

集成到qt库中wayland的client
Weston里的窗口管理系统存在问题

4.分析qt库加载wayland插件的过程：

在qt源码中分析qt加载插件的过程：

QGuiApplication::QGuiApplication

d_func()->init

QGuiApplicationPrivate::init

//加载平台的集成

createPlatformIntegration ./app -platform wayland

init_platform

init_plugins(pluginList);

QGenericPluginFactory::create

Wayland插件在qt库中的加载分析完后，发现对分析wayland是否存在问题没有什么用作。然后分析qt源码里的wayland目录，发现wayland client的代码比较复杂，无法在短时间内定位出问题。

5.分析Qt源码中wayland、weston中wayland源码中初始化流程；

Qt源码中wayland的源码目录如下：

Wayland的client和server交互总图如下（先给出交互图）：

Qt源码中wayland的初始化流程如下：

display->display = wl_display_connect()// 通过socket建立与Server端的连接，得到wl_display。它即代表了Server端的display资源，同时也是代理对象wl_proxy。Client可以通过它来向Server端提交调用请求和接收事件。

display->registry = wl_display_get_registry(display->display) // 申请创建registry，得到代理对象wl_registry。这个对象相当于Client在Server端放的一个用于嗅探资源的Observer。Client通过它得到Server端有哪些Global对象的信息。Server端有一系列的Global对象，如wl_compositor, wl_shm等，串在display->global_list链表里。Global对象在概念上类似于Service服务，因此Server端相当于充当了ServiceManager的角色。

wl_registry_add_listener(display->registry, &registry_listener,...) // 让Client监听刚才创建的wl_registry代理对象。这样，当Client调用wl_display_get_registry()函数或者有新的Global对象加入到Server端时，Client就会收到event通知。

wl_display_roundtrip() // 等待前面的请求全被Server端处理完，它同步了Client和Server端。这意味着到这个函数返回时，Server端有几个Global对象，回调处理函数registry_handle_global()应该就已经被调用过几次了。registry_handle_global()中会判断是当前这次event代表何种Global对象，然后调用wl_registry_bind()进行绑定，得到远程服务对象的本地代理对象。这些代理对象类型可以是wl_shm, wl_compositor等，但本质上都是wl_proxy类型。这步的作用类似于Android中的bindService()，它会得到一个远端Service的本地代理。

在weston和wayland源码中初始化流程如下：

weston_create_listening_socket()

wl_display_add_socket_auto()

wl_socket_init_for_display_name() // $XDG_RUNTIME_DIR/wayland-0,

_wl_display_add_socket()

wl_os_socket_cloexec() // create socket

bind()

listen()

wl_event_loop_add_fd(.., socket_data,...) 到此weston可以接受client发送的交互数据

6.分析weston库的内部处理：

Weston从内部体系结构来看，主要分为窗口管理（shell），合成器（compositor）和输入管理几个部分。从大体的流程上来看，输入管理模块接受用户输入，然后一方面shell作出相应的窗口管理操作（如窗口堆栈的改变，focus的变化等），另一方面将该input event传给之前注册了相应输入事件的client。client收到后会在handler中做相应动作，如调整视图然后重绘。如有重绘发生，新buffer渲染完成后client将其handle传给server，接着server端生成z-order序的窗口列表，之后compositor用renderer进行合成，最后输出(比如到framebuffer)。

Weston是主要服务进程，它的事件处理模型采用的是典型的Reactor模式。根据Linux中万物皆文件的原则，主循环通过epoll机制等待在一系列的文件fd上。这种模型与基于线程的binder不同，是一种串行的事件处理模型。在此模型上的过程调用在不加额外同步机制的情况下是异步的。好处是不会有竞争问题，数据同步开销较小。缺点是当有一个事件处理比较耗时或者在等待IO，则有可能使整个系统性能下降或响应不及时。

主循环上等待的几个核心fd包括：
• Server/Client通信：listener fd在Weston启动时建立，并一直监听新的client连接。一个client连接后会与Weston建立一对domain socket，Wayland就是基于它来通信的。
• 输入处理：一方面通过udev monitor监听设备的添加删除事件。另一方面如有新设备添加时会将该设备打开并监听该fd来得到输入事件。
• 其它：监听如timer（用于如睡眠锁屏等场景）和signal（如收到SIGINT, SIGTERM, SIGQUIT时退出主循环）等事件。timer和signal可以分别用timerfd和signalfd来用fd来表示。另外还有logind的dbus连接等。
除这些外，在event loop中还会维护一个idle list。Weston中需要异步处理的操作可以放在其中。每轮循环都会检查其中是否有任务，有的话拿出来执行。

下面看下Weston的运行时进程模型。Weston设计时是可以以一般用户运行的，但就需要用weston-launch来启动。当需要进行一些需要root权限的工作，比如关于DRM, TTY, input device的相关操作，就交由weston-launch去做。

Weston会在启动时或按需起一些子进程，它们本质上是Weston的client，它们会通过专用的协议做一些系统应用的工作。如系统应用weston-desktop-shell负责一些系统全局的界面，比如panel, background, cursor, app launcher, lock screen等。它不作为Weston服务本身的一部分，而是作为一个client。其作用有点类似于Android中的SystemUI。这样便可方便地替换成定制的界面。weston-keyboard是软键盘面板。weston-screenshooter和weston-screensaver分别用于截屏和屏保，它们都是按需才由Weston启动的。前者在截屏快捷键按下时启动，后者在需要锁屏时启动。