Weston问题定位共享
前言：
此问题的Qt版本为5.9.0，weston版本为3.0.0
1、问题
在IMX8MQ平台下，采用铣削厂家提供的固件进行qt接口开发； 在接口上使用QComboBox类时会发生什么情况；
点击下拉列表，弹出各选项后，选择其中一个选项，下拉列表不退出； 操作界面上的其他按钮不会退出下拉列表，此时将无法再使用该列表。
qtApp与weston交互概述
2 .定位问题切入点
可能有问题的地方
a.qt库中的GUI中存在的错误。 与qt库wayland的clientc.weston集成的窗口管理系统存在问题。 (上述问题的分析结果是，Weston中有错误，即窗口管理的处理有问题，但应该隐藏控制renderer，但没有隐藏renderer； 解决方案：由于weston属于第三方开源库，因此在复杂的投入分析中解决weston错误工作效率较低，而且由于使用的是较旧的版本，因此将升级并验证和解决weston库)
3 .使用相同的程序缩小范围：
在qt提供的用例combowidgetmapper中关闭weston后，没有此问题； 由此可知，不是qt库GUI问题引起的上述问题的出现。
可能有问题的地方
qt库中与wayland客户端Weston集成的窗口管理系统存在问题
4 .分析Qt库加载wayland插件的过程：
在qt源代码中分析qt加载插件的过程：
qui应用程序：3360 qguiapplication
d_func(-init
qguiapplicationprivate :3360 init
//加载平台集成
createplatformintegration./app-platform wayland
init_platform
text-align:left;"> 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, ®istry_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启动的。前者在截屏快捷键按下时启动，后者在需要锁屏时启动。
另外，Weston启动时会读取weston.ini这个配置文件，其中可以配置桌面，动画和后端等等信息。
IMX8MQ平台下的weston相关的进程如下图：
至此qt、weston和wayland的与此问题相关功能的分析大致完成，可以得出上面红色字体的结论，更详细的weston分析请自行阅读附件的源码及相关文件。
ps:此篇文章参考许多其他作者对weston源码分析的文章，对weston的框架有一个宏观了解的基础对weston的进行gdb调试后分析出具体的原因。同时也引用了它们的文章内存。