Analyzing the Startup Process of Wayland & Weston Display Services

Introduction

As we all know, the i.MX series chips have a wide range of applications in the multimedia field. Based on this point, we introduced various display interfaces and methods for building GStreamer pipelines in previous series. In the coming period, we will analyze another important component of the display part – Wayland & Weston.

Applications of Wayland & Weston

In previous articles, we taught you step-by-step how to use systemd to set up auto-start at boot. We introduced that systemd is an initialization system and service manager for Linux operating systems, responsible for starting and managing various services and processes in the system. Weston can also be auto-started during the Kernel boot process through systemd’s service. We can view the service name corresponding to Weston by using the command systemctl list-unit-files --type=service:

Then, we can find that the file path corresponding to its startup service is /lib/systemd/system/weston.service. From this, we can see the dependencies and startup order of Weston, where the Service section defines the executable file at startup and the log save directory:

ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so

By analyzing the startup log of Weston (/run/user/0/weston.log), we can further analyze the startup of Weston, where we can see the BSP and the version number used by Weston. For i.MX93, Lf 6.1.55 will be used with Weston version 11.0.0.3:

[09:49:27.620] weston 11.0.3               https://wayland.freedesktop.org               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/               Build: 11.0.3-54-gba6a8a02+[09:49:27.621] Command line: /usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so[09:49:27.621] OS: Linux, 6.1.55+gde8d5a614f8f, #1 SMP PREEMPT Fri Mar  8 07:53:09 UTC 2024, aarch64

Then, we can see that it calls the configuration file weston.ini for display-related configurations. In previous demonstration examples, we achieved multi-screen display and corresponding resolution settings through weston.ini.

[09:49:27.623] Using config file '/etc/xdg/weston/weston.ini'

Next, we can see that Weston uses DRM as the backend by default. In this mode, the Wayland output interface is displayed directly through the /dev/dri/card0 node:

[09:49:27.631] Loading module '/usr/lib/libweston-11/drm-backend.so'[09:49:27.637] initializing drm backend[09:49:27.637] Trying logind launcher...[09:49:27.650] logind: session control granted[09:49:27.663] using /dev/dri/card0[09:49:27.663] DRM: supports atomic modesetting[09:49:27.663] DRM: does not support GBM modifiers[09:49:27.663] DRM: supports picture aspect ratio

We use the official DSI screen (MX8-DSI-OLED1A) that comes with i.MX93 as the display configuration, and its corresponding device tree is ‘imx93-11×11-evk-rm67199.dtb’. From the DTS, we can see that this DSI screen is configured with a touchscreen, specifically Goodix:

&amp;lpi2c1 {        touchscreen@14 {                compatible = "goodix,gt1151";                reg = &lt;0x14&gt;;                interrupt-parent = &lt;&amp;pcal6524&gt;;                interrupts = &lt;7 IRQ_TYPE_EDGE_FALLING&gt;;                irq-gpios = &lt;&amp;pcal6524 7 GPIO_ACTIVE_HIGH&gt;;                reset-gpios = &lt;&amp;adp5585gpio 9 GPIO_ACTIVE_HIGH&gt;;                edge-failling-trigger;                touchscreen-size-x = &lt;1080&gt;;                touchscreen-size-y = &lt;1920&gt;;        };};

Therefore, we can see the registration of touch events in the Weston log. Regarding touch, keyboard, and mouse input settings in Weston, we will explain them in detail in future theoretical articles with code:

[09:49:27.804] event1  - Goodix Capacitive TouchScreen: is tagged by udev as: Keyboard Touchscreen[09:49:27.805] event1  - Goodix Capacitive TouchScreen: device is a keyboard[09:49:27.805] event1  - Goodix Capacitive TouchScreen: device is a touch device[09:49:27.813] event2  - WM8962 Beep Generator: not tagged as supported input device[09:49:27.813] event2  - not using input device '/dev/input/event2'[09:49:27.822] event0  - 44440000.bbnsm:pwrkey: is tagged by udev as: Keyboard[09:49:27.822] event0  - 44440000.bbnsm:pwrkey: device is a keyboard[09:49:27.863] Touchscreen - Goodix Capacitive TouchScreen - /sys/devices/platform/soc@0/44000000.bus/44340000.i2c/i2c-0/0-0014/input/input1/event1[09:49:27.863] libinput: configuring device "Goodix Capacitive TouchScreen".[09:49:27.863] input device event1 has no enabled output associated (none named), skipping calibration for now.[09:49:27.863] libinput: configuring device "44440000.bbnsm:pwrkey".

Then comes the actual display output part, where the DSI screen we are using will serve as the Weston display output.

[09:49:27.864] DRM: head 'DSI-1' updated, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'               Supported EOTF modes: SDR[09:49:27.864] DRM: head 'DSI-1' found, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'               Supported EOTF modes: SDR[09:49:27.864] Registered plugin API 'weston_drm_output_api_v1' of size 32[09:49:27.864] Color manager: no-op[09:49:27.864] Module '/usr/lib/libgbm.so' already loaded[09:49:27.864] Failed to lookup init function: /usr/lib/libgbm.so.1: undefined symbol: gbm_surface_get_in_fence_fd[09:49:27.865] Output 'DSI-1' attempts EOTF mode: SDR[09:49:27.865] Output 'DSI-1' using color profile: built-in default sRGB SDR profile[09:49:27.874] Initialized backlight for head 'DSI-1', device /sys/class/backlight/4ae10000.dsi.0[09:49:27.874] Output DSI-1 (crtc 33) video modes:               [email protected], preferred, current, 121.0 MHz[09:49:27.874] associating input device event1 with output DSI-1 (none by udev)[09:49:27.875] associating input device event0 with output DSI-1 (none by udev)[09:49:27.875] Output 'DSI-1' enabled with head(s) DSI-1

The log also contains part of the information about the DSI display, with its connector number being ‘35’, output display being 1080×[email protected] and other related information. We can also confirm this information through the command modetest -M imx-drm:

In the final part, we can see that modules related to the window manager (shell) are loaded from the log. Here we can see that the weston-desktop-shell responsible for the global interface of the system and the soft keyboard panel weston-keyboard are loaded and started by Weston:

[09:49:27.875] Compositor capabilities:               arbitrary surface rotation: yes               screen capture uses y-flip: yes               cursor planes: yes               arbitrary resolutions: no               view mask clipping: yes               explicit sync: yes               color operations: no               presentation clock: CLOCK_MONOTONIC, id 1               presentation clock resolution: 0.000000001 s[09:49:27.876] Loading module '/usr/lib/weston/desktop-shell.so'[09:49:27.879] Loading module '/usr/lib/libweston-11/xwayland.so'[09:49:27.913] Registered plugin API 'weston_xwayland_v1' of size 32[09:49:27.913] Registered plugin API 'weston_xwayland_surface_v1' of size 16[09:49:27.913] xserver listening on display :0[09:49:27.914] Loading module '/usr/lib/weston/systemd-notify.so'[09:49:27.915] info: add 1 socket(s) provided by systemd[09:49:27.915] launching '/usr/libexec/weston-keyboard'[09:49:27.918] launching '/usr/libexec/weston-desktop-shell'

Once Weston has successfully started through the auto-start service, the Weston desktop will be displayed on the DSI screen. In terms of usage scenarios, for example, in previous GStreamer articles, we used waylandsink to display video on the Weston desktop. We can use the following command to display video captured by the camera using the waylandsink element on the Weston desktop.

gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=YUY2,width=1920,height=1080 ! waylandsink

Then on the i.MX93, we can further process the image using PXP to meet our multimedia display needs:

gst-launch-1.0 -v imxcompositor_pxp name=comp \ sink_0::xpos=0 sink_0::ypos=0 sink_0::width=640 sink_0::height=480 \\ sink_1::xpos=0 sink_1::ypos=480 sink_1::width=640 sink_1::height=480 \\ sink_2::xpos=640 sink_2::ypos=0 sink_2::width=640 sink_2::height=480 \\ sink_3::xpos=640 sink_3::ypos=480 sink_3::width=640 sink_3::height=480 ! \\ waylandsink \\ v4l2src device=/dev/video2 ! video/x-raw, format=YUY2, width=640, height=480 ! comp.sink_0 \\ v4l2src device=/dev/video0 ! video/x-raw, format=YUY2, width=640, height=480 ! comp.sink_1 \\ videotestsrc ! comp.sink_2 \\ videotestsrc ! comp.sink_3

Conclusion

In this article, we analyzed the startup of Weston through its auto-start service and the corresponding log. In future articles, we will further explain the principles and relationships of each part, so stay tuned.

Related posts:

Leave a Comment Cancel reply