WESTON-DRM(7) | Miscellaneous Information Manual | WESTON-DRM(7) |
weston-drm - the DRM backend for Weston
weston-launch
weston --backend=drm-backend.so
The DRM backend is the native Weston backend for systems that support the Linux kernel DRM, kernel mode setting (KMS), and evdev input devices. It is the recommended backend for desktop PCs, and aims to provide the full Wayland experience with the "every frame is perfect" concept. It also relies on the Mesa GBM interface.
With the DRM backend, weston runs without any underlying windowing system. The backend uses the Linux KMS API to detect connected monitors. Monitor hot-plugging is supported. Input devices are found automatically by udev(7). Compositing happens mainly in GL ES 2, initialized through EGL. It is also possible to take advantage of hardware cursors and overlays, when they exist and are functional. Full-screen surfaces will be scanned out directly without compositing, when possible. Hardware accelerated clients are supported via EGL.
The backend chooses the DRM graphics device first based on seat id. If seat identifiers are not set, it looks for the graphics device that was used in boot. If that is not found, it finally chooses the first DRM device returned by udev(7). Combining multiple graphics devices is not supported yet.
The DRM backend relies on weston-launch for managing input device access and DRM master status, so that weston can be run without root privileges. On switching away from the virtual terminal (VT) hosting Weston, all input devices are closed and the DRM master capability is dropped, so that other servers, including Xorg(1), can run on other VTs. On switching back to Weston's VT, input devices and DRM master are re-acquired through the parent process weston-launch.
The DRM backend also supports virtual outputs that are transmitted over an RTP session as a series of JPEG images (RTP payload type 26) to a remote client. Virtual outputs are configured in the remote-output section of weston.ini.
The DRM backend uses the following entries from weston.ini.
CEA defines the timing of a video mode, which is considered as a standard for HDMI spcification and compliance testing. It defines each and every parameter of a video mode, like hactive, vactive, vfront, vback etc., including aspect-ratio information. For CEA modes, the drm layer, stores this aspect-ratio information in user-mode (drmModeModeInfo) flag bits 19-22. For the non-CEA modes a value of 0 is stored in the aspect-ratio flag bits.
Each CEA-mode is identified by a unique, Video Identification Code (VIC). For example, VIC=4 is 1280x720@60 aspect-ratio 16:9. This mode will be different than a non-CEA mode 1280x720@60 0:0. When the video mode 1280x720@60 0:0 is applied, since its timing doesn't exactly match with the CEA information for VIC=4, it would be treated as a non-CEA mode. Also, while setting the HDMI-AVI-Inforframe, VIC parameter will be given as '0'. If video mode 1280x720@60 16:9 is applied, its CEA timimgs matches with that of video mode with VIC=4, so the VIC parameter in HDMI-AVI-Infoframe will be set to 4.
Many a times, an output may have both CEA and non-CEA modes, which are similar in all resepct, differing only in the aspect-ratio. A user can select a CEA mode by giving the aspect-ratio, along with the other arguments for the mode. By omitting the aspect-ratio, user can specify the non-CEA modes. This helps when certification testing is done, in tests like 7-27, the HDMI-analyzer applies a particular CEA mode, and expects the applied mode to be with exactly same timings, including the aspect-ratio and VIC field.
The resolution can also be a detailed mode line as below.
NOTE: cms-colord plugin does not work correctly with this option. The plugin chooses an arbitrary monitor to load the color profile for, but the profile is applied equally to all cloned monitors regardless of their properties.
When the DRM backend is loaded, weston will understand the following additional command line options.
2012-11-27 | Weston 10.0.1 |