weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2024-01-22T16:22:07Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/868Fullscreen video with GL overlay does not hit plane-only renderer on rk3399 -...2024-01-22T16:22:07ZRobert MaderFullscreen video with GL overlay does not hit plane-only renderer on rk3399 - missing Wayland dmabuf scanout trancheThis issue might be hard to fix and the issue here is mostly for documentary purposes.
On the rk3399 (and likely similar devices) we currently don't send scanout tranches in certain situations where we should.
Primary example: a fullsc...This issue might be hard to fix and the issue here is mostly for documentary purposes.
On the rk3399 (and likely similar devices) we currently don't send scanout tranches in certain situations where we should.
Primary example: a fullscreen video surface with a fullscreen GL overlay surface on top (seen in GTK4/Chromium etc.). Mesas Wayland EGL platform will create the overlay surface with `ARM_AFBC` modifier (at least for supported resolutions), which is supported by the primary plane. The overlay planes, however, only support `LINEAR`.
When attempting the state-only renderer, we'll detect the overlay surface as supported by a plane - the primary - and not [set the `FAILURE_REASONS_FB_FORMAT_INCOMPATIBLE` flag to trigger sending scanout tranches](https://gitlab.freedesktop.org/wayland/weston/-/blob/e454de5af3d06f8db413515b9a71d11bb0800cc9/libweston/backend-drm/fb.c#L765-769). The state-only algorithm will then place the surface/view on the primary and fail as it doesn't have a plane left to place the video surface on.
Optimally we'd find a way to enhance the algorithm to somehow detect cases like this. On newer hardware, the problem can probably avoided by more capable planes, either supporting the relevant modifiers - or underlay zpos support.
On the rk3399 a possible workaround is [forcing `LINEAR` for clients](https://gitlab.freedesktop.org/rmader/weston/-/commits/issue-868-rk3399-overlay-workaround-linear-only):
```
--- a/libweston/renderer-gl/gl-renderer.c
+++ b/libweston/renderer-gl/gl-renderer.c
@@ -3167,7 +3167,7 @@ populate_supported_formats(struct weston_compositor *ec,
for (j = 0; j < num_modifiers; j++) {
/* Skip MOD_INVALID, as it has already been added. */
- if (modifiers[j] == DRM_FORMAT_MOD_INVALID)
+ if (modifiers[j] != DRM_FORMAT_MOD_LINEAR)
continue;
ret = weston_drm_format_add_modifier(fmt, modifiers[j]);
if (ret < 0) {
```
<details><summary>drm_info (relevant part)</summary>
```
├───Plane 2
│ ├───Object ID: 38
│ ├───CRTCs: {1}
│ ├───Legacy info
│ │ ├───FB ID: 56
│ │ │ ├───Object ID: 56
│ │ │ ├───Size: 1920x1080
│ │ │ ├───Format: XRGB8888 (0x34325258)
│ │ │ ├───Modifier: ARM_AFBC(BLOCK_SIZE = 16x16, YTR, SPARSE) (0x800000000000051)
│ │ │ └───Planes:
│ │ │ └───Plane 0: offset = 0, pitch = 7680 bytes
│ │ └───Formats:
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ABGR8888 (0x34324241)
│ │ ├───RGB888 (0x34324752)
│ │ ├───BGR888 (0x34324742)
│ │ ├───RGB565 (0x36314752)
│ │ ├───BGR565 (0x36314742)
│ │ ├───NV12 (0x3231564e)
│ │ ├───NV21 (0x3132564e)
│ │ ├───NV16 (0x3631564e)
│ │ ├───NV61 (0x3136564e)
│ │ ├───NV24 (0x3432564e)
│ │ └───NV42 (0x3234564e)
│ └───Properties
│ ├───"type" (immutable): enum {Overlay, Primary, Cursor} = Primary
│ ├───"FB_ID" (atomic): object framebuffer = 56
│ │ ├───Object ID: 56
│ │ ├───Size: 1920x1080
│ │ ├───Format: XRGB8888 (0x34325258)
│ │ ├───Modifier: ARM_AFBC(BLOCK_SIZE = 16x16, YTR, SPARSE) (0x800000000000051)
│ │ └───Planes:
│ │ └───Plane 0: offset = 0, pitch = 7680 bytes
│ ├───"IN_FENCE_FD" (atomic): srange [-1, INT32_MAX] = -1
│ ├───"CRTC_ID" (atomic): object CRTC = 44
│ ├───"CRTC_X" (atomic): srange [INT32_MIN, INT32_MAX] = 0
│ ├───"CRTC_Y" (atomic): srange [INT32_MIN, INT32_MAX] = 0
│ ├───"CRTC_W" (atomic): range [0, INT32_MAX] = 1920
│ ├───"CRTC_H" (atomic): range [0, INT32_MAX] = 1080
│ ├───"SRC_X" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_Y" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_W" (atomic): range [0, UINT32_MAX] = 1920
│ ├───"SRC_H" (atomic): range [0, UINT32_MAX] = 1080
│ ├───"IN_FORMATS" (immutable): blob = 39
│ │ ├───ARM_AFBC(BLOCK_SIZE = 16x16, YTR, SPARSE) (0x800000000000051)
│ │ │ ├───XRGB8888 (0x34325258)
│ │ │ ├───ARGB8888 (0x34325241)
│ │ │ ├───XBGR8888 (0x34324258)
│ │ │ ├───ABGR8888 (0x34324241)
│ │ │ ├───RGB888 (0x34324752)
│ │ │ ├───BGR888 (0x34324742)
│ │ │ ├───RGB565 (0x36314752)
│ │ │ └───BGR565 (0x36314742)
│ │ └───DRM_FORMAT_MOD_LINEAR (0x0)
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ABGR8888 (0x34324241)
│ │ ├───RGB888 (0x34324752)
│ │ ├───BGR888 (0x34324742)
│ │ ├───RGB565 (0x36314752)
│ │ ├───BGR565 (0x36314742)
│ │ ├───NV12 (0x3231564e)
│ │ ├───NV21 (0x3132564e)
│ │ ├───NV16 (0x3631564e)
│ │ ├───NV61 (0x3136564e)
│ │ ├───NV24 (0x3432564e)
│ │ └───NV42 (0x3234564e)
│ └───"rotation": bitmask {rotate-0, reflect-x, reflect-y} = (rotate-0)
├───Plane 3
│ ├───Object ID: 41
│ ├───CRTCs: {1}
│ ├───Legacy info
│ │ ├───FB ID: 57
│ │ │ ├───Object ID: 57
│ │ │ ├───Size: 64x64
│ │ │ ├───Format: ARGB8888 (0x34325241)
│ │ │ ├───Modifier: DRM_FORMAT_MOD_LINEAR (0x0)
│ │ │ └───Planes:
│ │ │ └───Plane 0: offset = 0, pitch = 256 bytes
│ │ └───Formats:
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ABGR8888 (0x34324241)
│ │ ├───RGB888 (0x34324752)
│ │ ├───BGR888 (0x34324742)
│ │ ├───RGB565 (0x36314752)
│ │ └───BGR565 (0x36314742)
│ └───Properties
│ ├───"type" (immutable): enum {Overlay, Primary, Cursor} = Cursor
│ ├───"FB_ID" (atomic): object framebuffer = 57
│ │ ├───Object ID: 57
│ │ ├───Size: 64x64
│ │ ├───Format: ARGB8888 (0x34325241)
│ │ ├───Modifier: DRM_FORMAT_MOD_LINEAR (0x0)
│ │ └───Planes:
│ │ └───Plane 0: offset = 0, pitch = 256 bytes
│ ├───"IN_FENCE_FD" (atomic): srange [-1, INT32_MAX] = -1
│ ├───"CRTC_ID" (atomic): object CRTC = 44
│ ├───"CRTC_X" (atomic): srange [INT32_MIN, INT32_MAX] = 1797
│ ├───"CRTC_Y" (atomic): srange [INT32_MIN, INT32_MAX] = 114
│ ├───"CRTC_W" (atomic): range [0, INT32_MAX] = 64
│ ├───"CRTC_H" (atomic): range [0, INT32_MAX] = 64
│ ├───"SRC_X" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_Y" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_W" (atomic): range [0, UINT32_MAX] = 64
│ ├───"SRC_H" (atomic): range [0, UINT32_MAX] = 64
│ ├───"IN_FORMATS" (immutable): blob = 42
│ │ └───DRM_FORMAT_MOD_LINEAR (0x0)
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ABGR8888 (0x34324241)
│ │ ├───RGB888 (0x34324752)
│ │ ├───BGR888 (0x34324742)
│ │ ├───RGB565 (0x36314752)
│ │ └───BGR565 (0x36314742)
│ └───"rotation": bitmask {rotate-0, reflect-y} = (rotate-0)
├───Plane 4
│ ├───Object ID: 45
│ ├───CRTCs: {1}
│ ├───Legacy info
│ │ ├───FB ID: 0
│ │ └───Formats:
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ABGR8888 (0x34324241)
│ │ ├───RGB888 (0x34324752)
│ │ ├───BGR888 (0x34324742)
│ │ ├───RGB565 (0x36314752)
│ │ ├───BGR565 (0x36314742)
│ │ ├───NV12 (0x3231564e)
│ │ ├───NV21 (0x3132564e)
│ │ ├───NV16 (0x3631564e)
│ │ ├───NV61 (0x3136564e)
│ │ ├───NV24 (0x3432564e)
│ │ └───NV42 (0x3234564e)
│ └───Properties
│ ├───"type" (immutable): enum {Overlay, Primary, Cursor} = Overlay
│ ├───"FB_ID" (atomic): object framebuffer = 0
│ ├───"IN_FENCE_FD" (atomic): srange [-1, INT32_MAX] = -1
│ ├───"CRTC_ID" (atomic): object CRTC = 0
│ ├───"CRTC_X" (atomic): srange [INT32_MIN, INT32_MAX] = 0
│ ├───"CRTC_Y" (atomic): srange [INT32_MIN, INT32_MAX] = 0
│ ├───"CRTC_W" (atomic): range [0, INT32_MAX] = 0
│ ├───"CRTC_H" (atomic): range [0, INT32_MAX] = 0
│ ├───"SRC_X" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_Y" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_W" (atomic): range [0, UINT32_MAX] = 0
│ ├───"SRC_H" (atomic): range [0, UINT32_MAX] = 0
│ ├───"IN_FORMATS" (immutable): blob = 46
│ │ └───DRM_FORMAT_MOD_LINEAR (0x0)
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ABGR8888 (0x34324241)
│ │ ├───RGB888 (0x34324752)
│ │ ├───BGR888 (0x34324742)
│ │ ├───RGB565 (0x36314752)
│ │ ├───BGR565 (0x36314742)
│ │ ├───NV12 (0x3231564e)
│ │ ├───NV21 (0x3132564e)
│ │ ├───NV16 (0x3631564e)
│ │ ├───NV61 (0x3136564e)
│ │ ├───NV24 (0x3432564e)
│ │ └───NV42 (0x3234564e)
│ └───"rotation": bitmask {rotate-0, reflect-x, reflect-y} = (rotate-0)
└───Plane 5
├───Object ID: 48
├───CRTCs: {1}
├───Legacy info
│ ├───FB ID: 0
│ └───Formats:
│ ├───XRGB8888 (0x34325258)
│ ├───ARGB8888 (0x34325241)
│ ├───XBGR8888 (0x34324258)
│ ├───ABGR8888 (0x34324241)
│ ├───RGB888 (0x34324752)
│ ├───BGR888 (0x34324742)
│ ├───RGB565 (0x36314752)
│ └───BGR565 (0x36314742)
└───Properties
├───"type" (immutable): enum {Overlay, Primary, Cursor} = Overlay
├───"FB_ID" (atomic): object framebuffer = 0
├───"IN_FENCE_FD" (atomic): srange [-1, INT32_MAX] = -1
├───"CRTC_ID" (atomic): object CRTC = 0
├───"CRTC_X" (atomic): srange [INT32_MIN, INT32_MAX] = 0
├───"CRTC_Y" (atomic): srange [INT32_MIN, INT32_MAX] = 0
├───"CRTC_W" (atomic): range [0, INT32_MAX] = 0
├───"CRTC_H" (atomic): range [0, INT32_MAX] = 0
├───"SRC_X" (atomic): range [0, UINT32_MAX] = 0
├───"SRC_Y" (atomic): range [0, UINT32_MAX] = 0
├───"SRC_W" (atomic): range [0, UINT32_MAX] = 0
├───"SRC_H" (atomic): range [0, UINT32_MAX] = 0
├───"IN_FORMATS" (immutable): blob = 49
│ └───DRM_FORMAT_MOD_LINEAR (0x0)
│ ├───XRGB8888 (0x34325258)
│ ├───ARGB8888 (0x34325241)
│ ├───XBGR8888 (0x34324258)
│ ├───ABGR8888 (0x34324241)
│ ├───RGB888 (0x34324752)
│ ├───BGR888 (0x34324742)
│ ├───RGB565 (0x36314752)
│ └───BGR565 (0x36314742)
└───"rotation": bitmask {rotate-0, reflect-y} = (rotate-0)
```
</details>
<details><summary>weston-debug drm-backend example</summary>
```
[repaint] Beginning repaint; pending_state 0xaaaaf7676950
Weston scene graph at 52359.000338386:
Output 0 (eDP-1):
position: (0, 0) -> (1920, 1080)
mode: 1920x1080@60.000Hz
scale: 1
repaint status: repaint scheduled
next repaint: 52359.000450666
Head 0 (eDP-1): connected
Layer 0 (pos 0xffffffff):
[no views]
Layer 1 (pos 0xfffffffe):
View 0 (role wl_pointer-cursor, PID 17069, surface ID 19, cursor, 0xaaaaf77dae90):
position: (685, 616) -> (709, 640)
[not opaque]
outputs: 0 (eDP-1) (primary)
SHM buffer
[2 references may use buffer content]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 24, height: 24
Layer 2 (pos 0xdfffffff):
[no views]
Layer 3 (pos 0xb0000000):
View 0 (role xdg_toplevel, PID 17069, surface ID 8, top-level window 'Video Player' of gtk4-demo, 0xaaaaf77d7070):
position: (0, 0) -> (1920, 1080)
[not opaque]
outputs: 0 (eDP-1) (primary)
dmabuf buffer
[2 references may use buffer content]
format: 0x34325241 ARGB8888
modifier: ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE (0x800000000000051)
width: 1920, height: 1080
View 1 (role wl_subsurface, PID 17069, surface ID 27, sub-surface, 0xaaaaf77d7c50):
[view is under parent view layer]
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (eDP-1) (primary)
dmabuf buffer
[2 references may use buffer content]
format: 0x3231564e NV12
modifier: LINEAR (0x0)
width: 3840, height: 2160
View 2 (role (null), PID 0, surface ID 0, black background surface for top-level window 'Video Player' of gtk4-demo, 0xaaaaf77de3f0):
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (eDP-1) (primary)
solid-colour buffer
[R 0.000000, G 0.000000, B 0.000000, A 1.000000]
[2 references may use buffer content]
format: 0x34325258 XRGB8888
modifier: LINEAR (0x0)
width: 1, height: 1
Layer 4 (pos 0x80000000):
View 0 (role (null), PID 17042, surface ID 17, panel for output eDP-1, 0xaaaaf75f4db0):
position: (0, 0) -> (1920, 32)
[not opaque]
outputs: 0 (eDP-1) (primary)
SHM buffer
[buffer has been released to client]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 1920, height: 32
Layer 5 (pos 0x50000000):
View 0 (role xdg_toplevel, PID 17062, surface ID 15, top-level window 'test@pinebook-pro:~' of org.freedesktop.weston.wayland-terminal, 0xaaaaf77cba40):
position: (397, 266) -> (1203, 847)
[opaque: (432, 301) -> (1168, 812)]
outputs: 0 (eDP-1) (primary)
SHM buffer
[buffer has been released to client]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 806, height: 581
Layer 6 (pos 0x2):
View 0 (role (null), PID 17042, surface ID 18, background for output eDP-1, 0xaaaaf75e55d0):
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (eDP-1) (primary)
SHM buffer
[buffer has been released to client]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 1920, height: 1080
[repaint] preparing state for output eDP-1 (0)
[repaint] trying planes-only build state
[view] evaluating view 0xaaaaf77dae90 for output eDP-1 (0)
[plane] started with zpos 18446744073709551615
[plane] plane 41 picked from candidate list, type: cursor
[cursor] provisionally assigned view 0xaaaaf77dae90 to cursor
[view] view 0xaaaaf77dae90 has been placed to cursor plane with computed zpos 4
[plane] next zpos to use 4
[view] evaluating view 0xaaaaf77d7070 for output eDP-1 (0)
[plane] started with zpos 4
[plane] plane 38 picked from candidate list, type: primary
[view] provisionally placing view 0xaaaaf77d7070 on plane 38
[view] view 0xaaaaf77d7070 has been placed to primary plane with computed zpos 0
[plane] next zpos to use 0
[view] evaluating view 0xaaaaf77d7c50 for output eDP-1 (0)
[plane] started with zpos 0
[overlay] not placing view on overlay: no free overlay planes matching format NV12 (0x3231564e) modifier 0x0
[view] view 0xaaaaf77d7c50 format: NV12
[plane] not trying plane 45: plane's minimum zpos (2) above current lowest zpos (0)
[plane] not trying plane 38: another view already assigned
[view] failing state generation: placing view 0xaaaaf77d7c50 to renderer not allowed
[repaint] could not build planes-only state, trying mixed
[state] using renderer FB ID 60 for mixed mode for output eDP-1 (0)
[state] scanout will use for zpos 0
[view] evaluating view 0xaaaaf77dae90 for output eDP-1 (0)
[plane] started with zpos 18446744073709551615
[plane] plane 41 picked from candidate list, type: cursor
[cursor] provisionally assigned view 0xaaaaf77dae90 to cursor
[view] view 0xaaaaf77dae90 has been placed to cursor plane with computed zpos 4
[plane] next zpos to use 4
[view] evaluating view 0xaaaaf77d7070 for output eDP-1 (0)
[plane] started with zpos 4
[view] view 0xaaaaf77d7070 will be placed on the renderer
[view] evaluating view 0xaaaaf77d7c50 for output eDP-1 (0)
[view] not assigning view 0xaaaaf77d7c50 to plane (occluded by renderer views)
[view] view 0xaaaaf77d7c50 will be placed on the renderer
[view] evaluating view 0xaaaaf77de3f0 for output eDP-1 (0)
[view] ignoring view 0xaaaaf77de3f0 (occluded on our output)
[view] evaluating view 0xaaaaf75f4db0 for output eDP-1 (0)
[view] ignoring view 0xaaaaf75f4db0 (occluded on our output)
[view] evaluating view 0xaaaaf77cba40 for output eDP-1 (0)
[view] ignoring view 0xaaaaf77cba40 (occluded on our output)
[view] evaluating view 0xaaaaf75e55d0 for output eDP-1 (0)
[view] ignoring view 0xaaaaf75e55d0 (occluded on our output)
[atomic] testing output 0 (eDP-1) state
[CRTC:44] 23 (MODE_ID) -> 61 (0x3d)
[CRTC:44] 22 (ACTIVE) -> 1 (0x1)
[CRTC:44] 28 (GAMMA_LUT) -> 0 (0x0)
[CRTC:44] 24 (VRR_ENABLED) -> 0 (0x0)
[CONN:52] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:38] 17 (FB_ID) -> 60 (0x3c)
[PLANE:38] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:38] 9 (SRC_X) -> 0 (0x0)
[PLANE:38] 10 (SRC_Y) -> 0 (0x0)
[PLANE:38] 11 (SRC_W) -> 125829120 (0x7800000)
[PLANE:38] 12 (SRC_H) -> 70778880 (0x4380000)
[PLANE:38] 13 (CRTC_X) -> 0 (0x0)
[PLANE:38] 14 (CRTC_Y) -> 0 (0x0)
[PLANE:38] 15 (CRTC_W) -> 1920 (0x780)
[PLANE:38] 16 (CRTC_H) -> 1080 (0x438)
[PLANE:38] FORMAT: XRGB8888
[PLANE:38] 40 (rotation) -> 1 (0x1)
[PLANE:41] 17 (FB_ID) -> 58 (0x3a)
[PLANE:41] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:41] 9 (SRC_X) -> 0 (0x0)
[PLANE:41] 10 (SRC_Y) -> 0 (0x0)
[PLANE:41] 11 (SRC_W) -> 4194304 (0x400000)
[PLANE:41] 12 (SRC_H) -> 4194304 (0x400000)
[PLANE:41] 13 (CRTC_X) -> 685 (0x2ad)
[PLANE:41] 14 (CRTC_Y) -> 616 (0x268)
[PLANE:41] 15 (CRTC_W) -> 64 (0x40)
[PLANE:41] 16 (CRTC_H) -> 64 (0x40)
[PLANE:41] FORMAT: ARGB8888
[PLANE:41] 43 (rotation) -> 1 (0x1)
[atomic] drmModeAtomicCommit
[repaint] Using mixed state composition
[repaint] view 0xaaaaf77dae90 on Cursor plane 41
[repaint] Need to update and resend the dma-buf feedback for surface of view 0xaaaaf77d7070
[repaint] view 0xaaaaf77d7070 using renderer composition
[repaint] view 0xaaaaf77d7c50 using renderer composition
[repaint] view 0xaaaaf77de3f0 using renderer composition
[repaint] view 0xaaaaf75f4db0 using renderer composition
[repaint] view 0xaaaaf77cba40 using renderer composition
[repaint] view 0xaaaaf75e55d0 using renderer composition
[atomic] applying output 0 (eDP-1) state
[CRTC:44] 23 (MODE_ID) -> 61 (0x3d)
[CRTC:44] 22 (ACTIVE) -> 1 (0x1)
[CRTC:44] 28 (GAMMA_LUT) -> 0 (0x0)
[CRTC:44] 24 (VRR_ENABLED) -> 0 (0x0)
[CONN:52] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:38] 17 (FB_ID) -> 55 (0x37)
[PLANE:38] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:38] 9 (SRC_X) -> 0 (0x0)
[PLANE:38] 10 (SRC_Y) -> 0 (0x0)
[PLANE:38] 11 (SRC_W) -> 125829120 (0x7800000)
[PLANE:38] 12 (SRC_H) -> 70778880 (0x4380000)
[PLANE:38] 13 (CRTC_X) -> 0 (0x0)
[PLANE:38] 14 (CRTC_Y) -> 0 (0x0)
[PLANE:38] 15 (CRTC_W) -> 1920 (0x780)
[PLANE:38] 16 (CRTC_H) -> 1080 (0x438)
[PLANE:38] FORMAT: XRGB8888
[PLANE:38] 40 (rotation) -> 1 (0x1)
[PLANE:41] 17 (FB_ID) -> 59 (0x3b)
[PLANE:41] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:41] 9 (SRC_X) -> 0 (0x0)
[PLANE:41] 10 (SRC_Y) -> 0 (0x0)
[PLANE:41] 11 (SRC_W) -> 4194304 (0x400000)
[PLANE:41] 12 (SRC_H) -> 4194304 (0x400000)
[PLANE:41] 13 (CRTC_X) -> 685 (0x2ad)
[PLANE:41] 14 (CRTC_Y) -> 616 (0x268)
[PLANE:41] 15 (CRTC_W) -> 64 (0x40)
[PLANE:41] 16 (CRTC_H) -> 64 (0x40)
[PLANE:41] FORMAT: ARGB8888
[PLANE:41] 43 (rotation) -> 1 (0x1)
[atomic] drmModeAtomicCommit
[CRTC:44] setting pending flip
[repaint] flushed pending_state 0xaaaaf7676950
```
</details>
<details><summary>weston-debug drm-backend example (with workaround)</summary>
```
Weston scene graph at 52826.781324700:
Output 0 (eDP-1):
position: (0, 0) -> (1920, 1080)
mode: 1920x1080@60.000Hz
scale: 1
repaint status: repaint scheduled
next repaint: 52826.781404666
Head 0 (eDP-1): connected
Layer 0 (pos 0xffffffff):
[no views]
Layer 1 (pos 0xfffffffe):
View 0 (role wl_pointer-cursor, PID 17300, surface ID 19, cursor, 0xaaaae63d5320):
position: (618, 462) -> (642, 486)
[not opaque]
outputs: 0 (eDP-1) (primary)
SHM buffer
[2 references may use buffer content]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 24, height: 24
Layer 2 (pos 0xdfffffff):
[no views]
Layer 3 (pos 0xb0000000):
View 0 (role xdg_toplevel, PID 17300, surface ID 8, top-level window 'Video Player' of gtk4-demo, 0xaaaae63d28e0):
position: (0, 0) -> (1920, 1080)
[not opaque]
outputs: 0 (eDP-1) (primary)
dmabuf buffer
[3 references may use buffer content]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 1920, height: 1080
View 1 (role wl_subsurface, PID 17300, surface ID 27, sub-surface, 0xaaaae63d34c0):
[view is under parent view layer]
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (eDP-1) (primary)
dmabuf buffer
[2 references may use buffer content]
format: 0x3231564e NV12
modifier: LINEAR (0x0)
width: 3840, height: 2160
View 2 (role (null), PID 0, surface ID 0, black background surface for top-level window 'Video Player' of gtk4-demo, 0xaaaae63d8be0):
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (eDP-1) (primary)
solid-colour buffer
[R 0.000000, G 0.000000, B 0.000000, A 1.000000]
[2 references may use buffer content]
format: 0x34325258 XRGB8888
modifier: LINEAR (0x0)
width: 1, height: 1
Layer 4 (pos 0x80000000):
View 0 (role (null), PID 17259, surface ID 17, panel for output eDP-1, 0xaaaae6200160):
position: (0, 0) -> (1920, 32)
[not opaque]
outputs: 0 (eDP-1) (primary)
SHM buffer
[buffer has been released to client]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 1920, height: 32
Layer 5 (pos 0x50000000):
View 0 (role xdg_toplevel, PID 17293, surface ID 15, top-level window 'test@pinebook-pro:~' of org.freedesktop.weston.wayland-terminal, 0xaaaae63c7b60):
position: (397, 266) -> (1203, 847)
[opaque: (432, 301) -> (1168, 812)]
outputs: 0 (eDP-1) (primary)
SHM buffer
[buffer has been released to client]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 806, height: 581
Layer 6 (pos 0x2):
View 0 (role (null), PID 17259, surface ID 18, background for output eDP-1, 0xaaaae61efc40):
position: (0, 0) -> (1920, 1080)
[fully opaque]
outputs: 0 (eDP-1) (primary)
SHM buffer
[buffer has been released to client]
format: 0x34325241 ARGB8888
modifier: LINEAR (0x0)
width: 1920, height: 1080
[repaint] preparing state for output eDP-1 (0)
[repaint] trying planes-only build state
[view] evaluating view 0xaaaae63d5320 for output eDP-1 (0)
[plane] started with zpos 18446744073709551615
[plane] plane 41 picked from candidate list, type: cursor
[cursor] provisionally assigned view 0xaaaae63d5320 to cursor
[view] view 0xaaaae63d5320 has been placed to cursor plane with computed zpos 4
[plane] next zpos to use 4
[view] evaluating view 0xaaaae63d28e0 for output eDP-1 (0)
[plane] started with zpos 4
[plane] plane 45 picked from candidate list, type: overlay
[view] provisionally placing view 0xaaaae63d28e0 on plane 45
[view] view 0xaaaae63d28e0 has been placed to overlay plane with computed zpos 2
[plane] next zpos to use 2
[view] evaluating view 0xaaaae63d34c0 for output eDP-1 (0)
[plane] started with zpos 2
[overlay] not placing view on overlay: no free overlay planes matching format NV12 (0x3231564e) modifier 0x0
[view] view 0xaaaae63d34c0 format: NV12
[plane] plane 38 picked from candidate list, type: primary
[view] provisionally placing view 0xaaaae63d34c0 on plane 38
[view] view 0xaaaae63d34c0 has been placed to primary plane with computed zpos 0
[plane] next zpos to use 0
[view] evaluating view 0xaaaae63d8be0 for output eDP-1 (0)
[view] ignoring view 0xaaaae63d8be0 (occluded on our output)
[view] evaluating view 0xaaaae6200160 for output eDP-1 (0)
[view] ignoring view 0xaaaae6200160 (occluded on our output)
[view] evaluating view 0xaaaae63c7b60 for output eDP-1 (0)
[view] ignoring view 0xaaaae63c7b60 (occluded on our output)
[view] evaluating view 0xaaaae61efc40 for output eDP-1 (0)
[view] ignoring view 0xaaaae61efc40 (occluded on our output)
[atomic] testing output 0 (eDP-1) state
[CRTC:44] 23 (MODE_ID) -> 60 (0x3c)
[CRTC:44] 22 (ACTIVE) -> 1 (0x1)
[CRTC:44] 28 (GAMMA_LUT) -> 0 (0x0)
[CRTC:44] 24 (VRR_ENABLED) -> 0 (0x0)
[CONN:52] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:41] 17 (FB_ID) -> 57 (0x39)
[PLANE:41] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:41] 9 (SRC_X) -> 0 (0x0)
[PLANE:41] 10 (SRC_Y) -> 0 (0x0)
[PLANE:41] 11 (SRC_W) -> 4194304 (0x400000)
[PLANE:41] 12 (SRC_H) -> 4194304 (0x400000)
[PLANE:41] 13 (CRTC_X) -> 618 (0x26a)
[PLANE:41] 14 (CRTC_Y) -> 462 (0x1ce)
[PLANE:41] 15 (CRTC_W) -> 64 (0x40)
[PLANE:41] 16 (CRTC_H) -> 64 (0x40)
[PLANE:41] FORMAT: ARGB8888
[PLANE:41] 43 (rotation) -> 1 (0x1)
[PLANE:38] 17 (FB_ID) -> 64 (0x40)
[PLANE:38] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:38] 9 (SRC_X) -> 0 (0x0)
[PLANE:38] 10 (SRC_Y) -> 0 (0x0)
[PLANE:38] 11 (SRC_W) -> 251658240 (0xf000000)
[PLANE:38] 12 (SRC_H) -> 141557760 (0x8700000)
[PLANE:38] 13 (CRTC_X) -> 0 (0x0)
[PLANE:38] 14 (CRTC_Y) -> 0 (0x0)
[PLANE:38] 15 (CRTC_W) -> 1920 (0x780)
[PLANE:38] 16 (CRTC_H) -> 1080 (0x438)
[PLANE:38] FORMAT: NV12
[PLANE:38] 40 (rotation) -> 1 (0x1)
[PLANE:45] 17 (FB_ID) -> 61 (0x3d)
[PLANE:45] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:45] 9 (SRC_X) -> 0 (0x0)
[PLANE:45] 10 (SRC_Y) -> 0 (0x0)
[PLANE:45] 11 (SRC_W) -> 125829120 (0x7800000)
[PLANE:45] 12 (SRC_H) -> 70778880 (0x4380000)
[PLANE:45] 13 (CRTC_X) -> 0 (0x0)
[PLANE:45] 14 (CRTC_Y) -> 0 (0x0)
[PLANE:45] 15 (CRTC_W) -> 1920 (0x780)
[PLANE:45] 16 (CRTC_H) -> 1080 (0x438)
[PLANE:45] FORMAT: ARGB8888
[PLANE:45] 47 (rotation) -> 1 (0x1)
[atomic] drmModeAtomicCommit
[repaint] Using plane-only state composition
[repaint] view 0xaaaae63d5320 on Cursor plane 41
[repaint] view 0xaaaae63d28e0 on Overlay plane 45
[repaint] view 0xaaaae63d34c0 on Primary plane 38
[repaint] view 0xaaaae63d8be0 using renderer composition
[repaint] view 0xaaaae6200160 using renderer composition
[repaint] view 0xaaaae63c7b60 using renderer composition
[repaint] view 0xaaaae61efc40 using renderer composition
[atomic] applying output 0 (eDP-1) state
[CRTC:44] 23 (MODE_ID) -> 60 (0x3c)
[CRTC:44] 22 (ACTIVE) -> 1 (0x1)
[CRTC:44] 28 (GAMMA_LUT) -> 0 (0x0)
[CRTC:44] 24 (VRR_ENABLED) -> 0 (0x0)
[CONN:52] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:41] 17 (FB_ID) -> 57 (0x39)
[PLANE:41] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:41] 9 (SRC_X) -> 0 (0x0)
[PLANE:41] 10 (SRC_Y) -> 0 (0x0)
[PLANE:41] 11 (SRC_W) -> 4194304 (0x400000)
[PLANE:41] 12 (SRC_H) -> 4194304 (0x400000)
[PLANE:41] 13 (CRTC_X) -> 618 (0x26a)
[PLANE:41] 14 (CRTC_Y) -> 462 (0x1ce)
[PLANE:41] 15 (CRTC_W) -> 64 (0x40)
[PLANE:41] 16 (CRTC_H) -> 64 (0x40)
[PLANE:41] FORMAT: ARGB8888
[PLANE:41] 43 (rotation) -> 1 (0x1)
[PLANE:38] 17 (FB_ID) -> 64 (0x40)
[PLANE:38] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:38] 9 (SRC_X) -> 0 (0x0)
[PLANE:38] 10 (SRC_Y) -> 0 (0x0)
[PLANE:38] 11 (SRC_W) -> 251658240 (0xf000000)
[PLANE:38] 12 (SRC_H) -> 141557760 (0x8700000)
[PLANE:38] 13 (CRTC_X) -> 0 (0x0)
[PLANE:38] 14 (CRTC_Y) -> 0 (0x0)
[PLANE:38] 15 (CRTC_W) -> 1920 (0x780)
[PLANE:38] 16 (CRTC_H) -> 1080 (0x438)
[PLANE:38] FORMAT: NV12
[PLANE:38] 40 (rotation) -> 1 (0x1)
[PLANE:45] 17 (FB_ID) -> 61 (0x3d)
[PLANE:45] 20 (CRTC_ID) -> 44 (0x2c)
[PLANE:45] 9 (SRC_X) -> 0 (0x0)
[PLANE:45] 10 (SRC_Y) -> 0 (0x0)
[PLANE:45] 11 (SRC_W) -> 125829120 (0x7800000)
[PLANE:45] 12 (SRC_H) -> 70778880 (0x4380000)
[PLANE:45] 13 (CRTC_X) -> 0 (0x0)
[PLANE:45] 14 (CRTC_Y) -> 0 (0x0)
[PLANE:45] 15 (CRTC_W) -> 1920 (0x780)
[PLANE:45] 16 (CRTC_H) -> 1080 (0x438)
[PLANE:45] FORMAT: ARGB8888
[PLANE:45] 47 (rotation) -> 1 (0x1)
[atomic] drmModeAtomicCommit
[CRTC:44] setting pending flip
[repaint] flushed pending_state 0xaaaae63d5a40
```
</details>
---
Related:
- https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1443
- https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1445
- https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258https://gitlab.freedesktop.org/wayland/weston/-/issues/494Use paint nodes everywhere2024-01-22T13:00:35ZPekka Paalanenppaalanen@gmail.comUse paint nodes everywhereMR !612 introduces "paint nodes" as suggested by @daniels.
The following discussion from !582 should be addressed:
- @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_895765): (+11...MR !612 introduces "paint nodes" as suggested by @daniels.
The following discussion from !582 should be addressed:
- @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_895765): (+11 comments)
In that thread, a plan was drafted for making use of paint nodes to resolve several internal design problems in libweston. This plan, when fully realized, should:
- allow overlapping `weston_output`s with correct damage tracking
- simplify `weston_view` handling vs. sub-surfaces
- help DRM-backend with KMS plane vs. view related bookkeeping
- provide per-output z-ordered view repaint lists optimized for each output
- allow caching the total geometric transformation from buffer to output pixel coordinates
Many new tests will be needed to minimize regressions:
- [ ] Ensuring damage is correctly handled with damage from clients, and view map, unmap, move, resize, restack. (This should be correct already.)
- [ ] Check that damage masked by unchanged opaque regions gets correctly ignored on repainting an output. (This should happen already too.)
- [ ] In-compositor inflicted damage does not result in texture uploads (#3).
- [ ] Test everything also multiple outputs, and views spanning multiple outputs.
Issues from !612:
- [x] `weston_output` `paint_node_z_order_list` needs to be pruned; build it so that it contains only those paint nodes that actually affect the output.
From https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_899406:
- `weston_view` is retained as the structure for the frontend window manager to place surfaces into the scene graph, which are placed in layer lists
- [x] we create a new structure for the backends (including renderer) to consume as part of repaint (call it `weston_paint_node`) containing view ptr + link, output ptr + link, and surface ptr + link; it's placed in a list in `weston_view`, with `weston_compositor_build_view_list` creating it for every `weston_view` + `weston_output` combination if not already existing, and `weston_output_destroy`/`weston_view_destroy` destroying any paint nodes which reference that output/view (!612)
- [x] we create a `weston_paint_node->color_state` which this patchset can use to cache the core color state without the need for surface/view/output destroy listeners, since it will be explicitly destroyed from either surface -> view -> paint_node destruction or output -> paint_node destruction (!582)
- [x] output repaint (backend and renderer) is changed to iterate paint-nodes rather than views, albeit mostly just back-referencing to views for everything (!612)
- [ ] over time, we hollow out `weston_view` as things like damage/geometry/plane/etc migrate to `weston_paint_node`, being constructed from surface+view as required (e.g. `weston_surface_damage` calls through to `weston_view_damage`, however this just iterates the list of paint-nodes and applies damage to those, at this point we could probably make the paint-node damage be pre-transformed to output co-ordinate space too, as well as handling occlusion)
- [ ] `view_list` becomes completely untouched by backends at this point, being used only by middle end surface (e.g. surface damage -> paint-node damage via views) and input picking (global co-ord -> surface+co-ord via views)
- [ ] `weston_paint_node` gains a `root_view` member, referring to the view which was actually created by the frontend rather than internal
- [ ] input picking is refactored: touch events (being derived from output co-ordinates) pick a paint-node directly, pointer events (being derived from global co-ordinates) are transformed to output co-ordinate space and then pick a paint-node, focus is stored as a root-view + surface pair (and we eventually create a more sensible focus interface for frontends but this is already too long to get into)
- [ ] middle-end paint-node generation is refactored: rather than generating views as required (e.g. materialising views for subsurfaces), it begins from a root view, directly materialising paint nodes as required for every surface+output combination under that root view (perhaps generating multiple paint-nodes for each render key such as blended-under vs. unoccluded, etc)
From https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_901104:
- [ ] At a later point, paint nodes later get their own `transform` member (transformed into output space and clipped for occlusion), which the backend and renderers are modified to use during repaint, initially just derived from the `weston_view`. At a further later point (either commit or MR), the view's `transform` is removed, with each paint-node's transform being derived from the *root* view's geometry + (sub)surface transform + output transform.
From https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_901163:
> The path to sensible damage tracking looks quite similar, I think, and *definitely* comes after the above movement of transform, but also comes somewhere before being able to move away from views in the backend/renderer.
>
> In rough order, here's what I see we need to do:
1. [x] Everything remains as is, nothing is touched
1. [x] Paint nodes gain a `damage` member, and `view_accumulate_damage` propagates the damage region down to each paint node for that view, transformed to the output and clipped to the paint node's total clip (i.e. none if occluded)
1. [x] `output_accumulate_damage` is changed to accumulate from all the paint nodes for that output, rather than from the view
1. [ ] `output_accumulate_damage` is changed to only flush surface damage for surfaces whose paint nodes on that output contain active damage, which means we no longer flush surface damage for occluded surfaces (the first client-visible behaviour change)
1. [ ] `weston_view_damage` is introduced to damage a region (or all) of a view, which internally calls a new `weston_paint_node_damage()` for all of its paint nodes
1. [x] `weston_view->plane` is moved to the paint node, with damage incurred from plane changes being placed on the paint node rather than the whole view
1. \[everything after this point is a little hazy as it's too far in the future to say confidently, but in broad strokes ...\]
1. [x] the logic for incurring damage from subsurface stacking/geometry changes and view transform updates (e.g. moving a view), is moved to act on paint nodes, if a paint node changes position or is added/removed within the stack, it is that operation of manipulating the paint nodes which incurs damage, rather than the current mechanism of surface commit -> subsurface commit -> subsurface z-order stack change -> damage all surfaces -> schedule repaint for involved outputs -> \[wait for output repaint\] -> accumulate surface damage into view damage -> reduce view damage into paint-node damage
1. [x] `weston_surface_damage` callers are migrated to damage either paint nodes (for low-level operations), or damage views (for window-management operations) which in turn damage paint nodes
1. [x] view damage is removed, since it is no longer used by anyone and no longer makes sense at this point
1. [x] We now have one less obstacle in the way of requiring one view per (sub)surface in the scene graph, and we've fixed #3, and we can finally have outputs which overlap in global co-ordinate space
> Suffice to say, this is a lot of work, but it can at least be done incrementally, and gives us a lot of good intermediate points to write new tests against: with the new model separating client-provoked damage from WM-provoked damage, we have semantics we can reason about and validate at each point.https://gitlab.freedesktop.org/wayland/weston/-/issues/848Deprecate fullscreen-shell2024-01-22T07:59:40ZMarius VladDeprecate fullscreen-shellWith the changes from !1397 and !1401 merged we might start considering deprecating fullscreen-shell entirely and suggest
users using kiosk-shell instead.
screen-share module is dependent on it so need documenting how to set-up overlap...With the changes from !1397 and !1401 merged we might start considering deprecating fullscreen-shell entirely and suggest
users using kiosk-shell instead.
screen-share module is dependent on it so need documenting how to set-up overlapping outputs to achieve the same functionality I suppose.14.0.0https://gitlab.freedesktop.org/wayland/weston/-/issues/802Implement the drm-lease-v1 protocol2024-01-19T14:20:45ZDallas StrouseImplement the drm-lease-v1 protocolI'm currently looking at [implementing DRM leasing in Mutter](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3205), and would appreciate it if Weston supported DRM leasing as a reference implementation. I have the kwin and wlroot...I'm currently looking at [implementing DRM leasing in Mutter](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3205), and would appreciate it if Weston supported DRM leasing as a reference implementation. I have the kwin and wlroots implementations open right now to see how *they* do it, but both are more designed for *their* compositors (kwin being C++, and it's not too applicable to Mutter, and wlroots having some weird wlroots abstractions I can't apply here). As such, I'd appreciate it if a plain C reference implementation, with no (or little) additional abstractions, were available. Weston seems like the best place for that, especially as it is the reference Wayland compositor implementation.https://gitlab.freedesktop.org/wayland/weston/-/issues/847Weston Kiosk Shell chromium losing focus upon sad tab kill2024-01-19T14:19:11ZW Scott McKibbinWeston Kiosk Shell chromium losing focus upon sad tab killHello,
Working on a project which is launching a Weston Kisok Shell for a single chromium kiosk targeting a localhost webserver, running on imx8.
We are encountering an issue when chromium kills a "sad_tab". Seems as though this kills ...Hello,
Working on a project which is launching a Weston Kisok Shell for a single chromium kiosk targeting a localhost webserver, running on imx8.
We are encountering an issue when chromium kills a "sad_tab". Seems as though this kills and restarts the tab in the event of memory issues within chromium. When this happens, we lose focus on the chromium window and are no longer able to navigate with the keypad input setup for the kiosk.
Here is our config weston ini:
```ini
[core]
shell=kiosk-shell.so
idle-time=0
useg2d=0
xwayland=false
#use-g2d=1
[output]
name=HDMI-A-1
app-ids=chromium-browser (/home/root/.config/)
mode=71.00 1280 1328 1360 1440 800 803 809 823 +hsync +vsync
```
I thought adding the app id as capture from our chromium launch command would stop the focus from changing but it did not. I need to find a way to prevent the focus from leaving. We are able to restore focus by clicking but that is only because this is in the lab on a test machine with a keyboard/mouse hooked up, the real setup will only have a small keypad.
```sh
WAYLAND_DEBUG=1 chromium 2>&1 \
--no-sandbox \
--window-size=1920,1080 \
--start-fullscreen \
--kiosk \
--incognito \
--noerrdialogs \
--disable-translate \
--no-first-run \
--fast \
--fast-start \
--disable-infobars \
--disable-features=TranslateUI \
--disk-cache-dir=/dev/null \
--password-store=basic \
--in-process-gpu \
--touch-events \
--user-data-dir=/home/root/.config/ \
--disable-web-security \
http://127.0.0.1 | grep app
[4088792.203] -> xdg_toplevel@36.set_app_id("chromium-browser (/home/root/.config/)")
```
Any tips, tricks or advice you could give would be greatly appreciated.
Thankshttps://gitlab.freedesktop.org/wayland/weston/-/issues/765Support portals for screenshots2024-01-19T13:58:16ZbinzhaiSupport portals for screenshotsI installed weston in docker, the version of weston is 12.0.90, the backend is vnc-backend.so, and it is displayed remotely through vnc. When I install some applications with screenshot function, such as qq, wechat, when taking screensho...I installed weston in docker, the version of weston is 12.0.90, the backend is vnc-backend.so, and it is displayed remotely through vnc. When I install some applications with screenshot function, such as qq, wechat, when taking screenshots, it will cause a black screen.What could be the cause of this?https://gitlab.freedesktop.org/wayland/weston/-/issues/865Add support for listening and reconfiguring the keyboard settings from locale12024-01-19T13:39:06ZNeal Gompa (ニール・ゴンパ)Add support for listening and reconfiguring the keyboard settings from locale1Weston currently only supports [statically configuring the keyboard from `weston.ini(5)`](https://www.mankier.com/5/weston.ini#Keyboard_Section), but nowadays there is a good source for keyboard settings that Weston could listen to: [`or...Weston currently only supports [statically configuring the keyboard from `weston.ini(5)`](https://www.mankier.com/5/weston.ini#Keyboard_Section), but nowadays there is a good source for keyboard settings that Weston could listen to: [`org.freedesktop.locale1`](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.locale1.html).
Please add support for it so that things like login managers and keyboard layout configuration tools that set the keyboard through `org.freedesktop.locale1` would be able to configure Weston dynamically.
Here are a couple of example implementations for other compositors:
* KWin: https://invent.kde.org/plasma/kwin/-/merge_requests/2921
* Sway: https://github.com/alebastr/sway-systemd/blob/main/src/locale1-xkb-confighttps://gitlab.freedesktop.org/wayland/weston/-/issues/294Input and output control protocols for the headless backend2024-01-19T11:41:30ZPekka Paalanenppaalanen@gmail.comInput and output control protocols for the headless backendI believe that the headless backend would have much more value if it exposed external interfaces for
- dynamically creating, configuring, and removing heads, and
- dynamically creating, configuring, and removing `wl_seat`s.
The weston-t...I believe that the headless backend would have much more value if it exposed external interfaces for
- dynamically creating, configuring, and removing heads, and
- dynamically creating, configuring, and removing `wl_seat`s.
The weston-test plugin already has a rudimentary Wayland interface for input device control, but it is completely ad hoc and organic. I envision something that would be well structured and more or less match the libweston backend API and the `wl_seat` family of Wayland interfaces.
Controlling heads would allow automated testing of monitor hotplug, and controlling input devices would allow automated testing of input device hotplug and synthetic input events. These would be useful in testing not only the Weston frontend and libweston core behaviour, but it would also create a nice test bed for application testing. Especially the synthetic input events should be a great help for automating application UI testing without involving uinput.
The natural choice would be to write these interfaces as Wayland protocol extensions implemented directly in the headless backend.
This idea is continuation from using GL-renderer with the headless backend, allowing headless hardware-accelerated graphics, which is already implemented.https://gitlab.freedesktop.org/wayland/weston/-/issues/866RFC: Modernizing configuration management2024-01-15T21:00:17ZPekka Paalanenppaalanen@gmail.comRFC: Modernizing configuration managementThese are some hand-wavy ideas for improving Weston's configurability.
Current situation:
- configuration is read only once at Weston start-up, and cannot be changed at runtime
- `weston.ini` uses a home-grown parser, `weston_config`, t...These are some hand-wavy ideas for improving Weston's configurability.
Current situation:
- configuration is read only once at Weston start-up, and cannot be changed at runtime
- `weston.ini` uses a home-grown parser, `weston_config`, that is not worthwhile extending
I would not limit us to be backward-compatible with current `weston.ini` nor even use an INI format at all if better alternatives exist. I'd suggest a new Weston frontend with the new configuration tools. The current frontend can be left with the current `weston.ini` to not break existing users.
Wishlist:
- ability to change configuration dynamically; read, modify, and write configuration files, so that dynamic changes can persist on next start-up
- use a library, so we do not need to develop or maintain the fundamentals
- complex data types, e.g. vectors/lists as values
Additionally, we would need an IPC for actually changing the configuration. If there is a library offering also that, e.g. via D-Bus, that would be cool. Then we could expose volatile debug settings too.
Not all settings would fit a generic configuration library, though, e.g. #341, unless the library offers testable transactions. This gets easily complicated, so perhaps we should keep the IPC separate from the config library. Some topics have prior art, like wlr-output-management for #341.
This is also orthogonal to alternative configuration sources like requested for in #865 which would replace parts of configuration rather than be an API to change and save it.https://gitlab.freedesktop.org/wayland/weston/-/issues/719Process fragments from a *.d type of directory / drop-in files / weston.ini.d2024-01-15T12:55:18ZMarius VladProcess fragments from a *.d type of directory / drop-in files / weston.ini.dSimilarly to what we have in systemd, or some sort of conf.d/ directory from apache, where we have multiple virtual sites, we can have a weston.ini.d/ directory from which we can assemble a fully ini configuration file.
For instance, ha...Similarly to what we have in systemd, or some sort of conf.d/ directory from apache, where we have multiple virtual sites, we can have a weston.ini.d/ directory from which we can assemble a fully ini configuration file.
For instance, having the following directory:
```
weston.ini.d/
weston.ini.d/core.cfg
weston.ini.d/output_virtual.cfg
weston.ini.d/remote.cfg
weston.ini.d/hdmi.cfg
```
And their corresponding files:
- weston.ini.d/core.cfg:
```
[core]
modules=systemd-notify.so
idle-time=0
```
- weston.ini.d/output_virtual.cfg
```
[output]
name=Virtual-1
mode=1280x1024
```
- weston.ini.d/remote.cfg
```
[remote-output]
name=remote-1
mode=640x720@30
host=192.168.100.49
port=9991
```
- weston.ini.d/hdmi.cfg
```
[output]
name=HDMI-A-1
mode=1920x1200
```
This seems to be quite useful to have in systems (yocto/OE and the like) where we need to mix various
configurations and generate these configure fragments as such.Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/issues/341Libweston needs atomic output configuration API2024-01-15T12:39:24ZPekka Paalanenppaalanen@gmail.comLibweston needs atomic output configuration APIThe current output configuration API of libweston only allows reconfiguring disabled (inactive) outputs. This makes changing output configuration a very glitchy experience. An atomic output configuration API is needed, with the same spir...The current output configuration API of libweston only allows reconfiguring disabled (inactive) outputs. This makes changing output configuration a very glitchy experience. An atomic output configuration API is needed, with the same spirit as the atomic KMS UAPI. #22 did not actually reach an atomic API.
A transaction based API is needed, because an output has many parameters. Changing each parameter one at a time would repeatedly apply intermediate configuration states for users and clients to see. Some of the consequences can be quite heavy, see https://gitlab.freedesktop.org/wayland/weston/issues/339#note_385588.
Second, since the hardware resources used by outputs are usually shared, the configuration of one output affects what is possible for another output. It would be good to be able to configure multiple outputs in one step to avoid intermediate configurations that might prevent the final configuration from being reached.
Third, with `TEST_ONLY` in the atomic KMS API, we would be able to test if a global output configuration will work. Using transactions for output configuration allows testing the complete configuration in one step to see if it is possible.
This issue partially closes #25 by recording the atomic API thoughts from the now inaccessible Phabricator document.
## Atomic Libweston API
The libweston API needs to be atomic. It would probably be good to follow the DRM backend atomic state design somewhat. One needs to be able to construct a configuration covering all outputs, and test if it would work, then commit it as a whole to be taken into use on the next repaint cycle of each weston_canvas.
1. Compositor constructs a tentative output configuration from canvases and heads.
1. Compositor calls a test function with the tentative configuration.
1. Test gets relayed to the DRM backend.
1. DRM backend tries all the possible CRTC and connector combinations until it finds one that works, or returns test failed.
1. Compositor:
* If test failed: discards the tentative configuration.
* If test succeeds: commits the tentative configuration, which schedules a repaint, which will then do the actual modesets.
### Questions
* What would the libweston API look like?
* What parts of the API should be common and what parts should be backend-specific?
* How to make the common API parts make sense to all the other backends?
* How to stage a tentative configuration without modifying the current state in `weston_canvas` and `weston_head`?
* How to re-use the atomic request helpers in the DRM backend with the tentative configuration?https://gitlab.freedesktop.org/wayland/weston/-/issues/861Weston does not scale launcher icons to match the launcher width2024-01-03T21:12:06ZM BWeston does not scale launcher icons to match the launcher widthWeston 13.0.0 does not scale the size of launcher icons to match the size of the launcher panel. If the end-user supplies icons larger than the width/height of the launcher panel, the icons are rendered outside of their boundaries. The l...Weston 13.0.0 does not scale the size of launcher icons to match the size of the launcher panel. If the end-user supplies icons larger than the width/height of the launcher panel, the icons are rendered outside of their boundaries. The launcher buttons still continue to work as if the buttons were square and the width/height of the panel, even if another applications icon has obscured the buttons (in the below snapshots, clicking in the first launcher position launches `xfce4-terminal` even though the button is obscured with firefox's icon).
```plaintext
[launcher]
displayname=term
icon=/usr/share/icons/hicolor/32x32/apps/org.xfce.terminal.png
path=/usr/bin/xfce4-terminal
[launcher]
displayname=firefox
icon=/usr/share/icons/hicolor/32x32/apps/firefox.png
path=/usr/bin/firefox
```
[term-first-32-rotation-weston13.png](/uploads/ad5b8584ab03629d2933a3836f64c221/term-first-32-rotation-weston13.png)
```plaintext
[launcher]
displayname=term
icon=/usr/share/icons/hicolor/128x128/apps/org.xfce.terminal.png
path=/usr/bin/xfce4-terminal
[launcher]
displayname=firefox
icon=/usr/share/icons/hicolor/128x128/apps/firefox.png
path=/usr/bin/firefox
```
[term-first-128-rotation-weston13.png](/uploads/8fc034cbc814d4b67ddfc9f9d8904fcb/term-first-128-rotation-weston13.png)
When the `panel-position` is set to `left` instead of `top`, the width of the launcher bar is very different than when it is in the `top` position, which requires an entirely different set of icons.
Ideally, the end-user could either supply a higher-resolution icon that is automatically scaled down or the Weston configuration could accept multiple icons of different sizes for each launcher and automatically pick the most appropriately sized icon.https://gitlab.freedesktop.org/wayland/weston/-/issues/640no weston-terminal when no input devices2023-12-25T11:49:09ZPiotr Oniszczukno weston-terminal when no input devicesHi,
I'm using weston10.0.1 with wayland1.20.0 and libinput1.17.1 and no systemd.
(it is linux based appliance minimyth2).
Issue i have is no weston-terminal when appliance has no keyb/mice connected.
In such case launching weston-termi...Hi,
I'm using weston10.0.1 with wayland1.20.0 and libinput1.17.1 and no systemd.
(it is linux based appliance minimyth2).
Issue i have is no weston-terminal when appliance has no keyb/mice connected.
In such case launching weston-terminal gives v.show black screen and nothing more on screen.
All works correctly when there is any input device (keyb/mice, etc) connected.
Also connecting keyb or mice shortly and disconnecting makes weston-terminal started to working ok without keyb/mice.
It looks like weston has kind of bug for use-case without any input device.
weston log:
```
root@Myth-Frontend-da19c87a6df4:~ # cat /var/log/weston.log
Date: 2022-07-22 CEST
[11:49:38.983] weston 10.0.1
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 10.0.1
[11:49:38.984] Command line: /usr/bin/weston --log=/var/log/weston.log --config=/etc/weston-minimal.ini
[11:49:38.984] OS: Linux, 5.18.12, #1 SMP PREEMPT Mon Jul 18 16:49:09 CEST 2022, aarch64
[11:49:38.984] Flight recorder: enabled
[11:49:38.986] Using config file '/etc/weston-minimal.ini'
[11:49:39.003] Output repaint window is 7 ms maximum.
[11:49:39.007] Loading module '/usr/lib/libweston-10/drm-backend.so'
[11:49:39.016] initializing drm backend
[11:49:39.016] Trying weston_launch launcher...
[11:49:39.019] using /dev/dri/card0
[11:49:39.019] DRM: supports atomic modesetting
[11:49:39.019] DRM: supports GBM modifiers
[11:49:39.019] DRM: supports picture aspect ratio
[11:49:39.021] Loading module '/usr/lib/libweston-10/gl-renderer.so'
[11:49:40.440] EGL client extensions: EGL_EXT_client_extensions
EGL_EXT_device_base EGL_EXT_device_enumeration
EGL_EXT_device_query EGL_EXT_platform_base
EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
EGL_EXT_platform_device EGL_EXT_platform_wayland
EGL_KHR_platform_wayland EGL_EXT_platform_x11
EGL_KHR_platform_x11 EGL_MESA_platform_xcb
EGL_MESA_platform_gbm EGL_KHR_platform_gbm
EGL_MESA_platform_surfaceless
[11:49:40.449] EGL device extensions: EGL_EXT_device_drm
[11:49:40.449] EGL version: 1.4
[11:49:40.449] EGL vendor: Mesa Project
[11:49:40.449] EGL client APIs: OpenGL OpenGL_ES
[11:49:40.449] EGL extensions: EGL_ANDROID_blob_cache
EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2
EGL_KHR_config_attribs EGL_KHR_create_context
EGL_KHR_create_context_no_error EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_partial_update
EGL_KHR_reusable_sync EGL_KHR_surfaceless_context
EGL_EXT_pixel_format_float EGL_KHR_wait_sync
EGL_MESA_configless_context EGL_MESA_drm_image
EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
EGL_WL_bind_wayland_display
[11:49:40.449] EGL_KHR_surfaceless_context available
[11:49:40.552] GL version: OpenGL ES 2.0 Mesa 22.1.4
[11:49:40.552] GLSL version: OpenGL ES GLSL ES 1.0.16
[11:49:40.552] GL vendor: lima
[11:49:40.552] GL renderer: Mali450
[11:49:40.552] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_format_BGRA8888
GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth_texture
GL_OES_packed_depth_stencil GL_OES_get_program_binary
GL_APPLE_texture_max_level GL_EXT_discard_framebuffer
GL_EXT_read_format_bgra GL_NV_pack_subimage GL_EXT_frag_depth
GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_ANGLE_pack_reverse_row_order GL_EXT_texture_rg
GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil
GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug
GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_separate_shader_objects
GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_EXT_blend_func_extended
GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d
GL_EXT_clip_control GL_KHR_parallel_shader_compile GL_MESA_bgra
[11:49:40.757] GL ES 2.0 - renderer features:
read-back format: BGRA
EGL Wayland extension: yes
[11:49:40.783] event0 - gpio_ir_recv: not tagged as supported input device
[11:49:40.783] event0 - not using input device '/dev/input/event0'
[11:49:40.784] event1 - eventlircd: not tagged as supported input device
[11:49:40.784] event1 - not using input device '/dev/input/event1'
[11:49:40.784] warning: no input devices found, but none required as per configuration.
[11:49:40.896] DRM: head 'HDMI-A-1' updated, connector 42 is connected, EDID make 'STK', model 'S2-TEK TV', serial 'SN-000000001'
[11:49:40.896] DRM: head 'HDMI-A-1' found, connector 42 is connected, EDID make 'STK', model 'S2-TEK TV', serial 'SN-000000001'
[11:49:40.897] Registered plugin API 'weston_drm_output_api_v1' of size 24
[11:49:40.897] Color manager: no-op
[11:49:40.897] Output 'HDMI-A-1' using color profile: built-in default sRGB SDR profile
[11:49:40.897] Chosen EGL config details: id: 7 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8888 (0x34325258)
[11:49:40.897] Output HDMI-A-1 (crtc 37) video modes:
1920x1080@60.0, preferred, current, 148.5 MHz
1920x1080@60.0 16:9, 148.5 MHz
1920x1080@59.9 16:9, 148.4 MHz
1920x1080@50.0 16:9, 148.5 MHz
1280x720@60.0, 74.2 MHz
1280x720@60.0 16:9, 74.2 MHz
1280x720@59.9 16:9, 74.2 MHz
1280x720@50.0 16:9, 74.2 MHz
800x600@60.3, 40.0 MHz
720x576@50.0 16:9, 27.0 MHz
720x576@50.0 4:3, 27.0 MHz
720x480@59.9 16:9, 27.0 MHz
720x480@59.9 4:3, 27.0 MHz
[11:49:40.897] Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
[11:49:40.897] 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
[11:49:40.900] Loading module '/usr/lib/weston/desktop-shell.so'
[11:49:40.905] launching '/usr/libexec/weston-keyboard'
[11:49:40.907] Warning: support for deprecated wl_shell interface is enabled. Please migrate legacy clients to xdg-shell.
[11:49:40.908] launching '/usr/libexec/weston-desktop-shell'
root@Myth-Frontend-da19c87a6df4:~ # cat /var/log/weston.log
Date: 2022-07-22 CEST
[11:49:38.983] weston 10.0.1
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 10.0.1
[11:49:38.984] Command line: /usr/bin/weston --log=/var/log/weston.log --config=/etc/weston-minimal.ini
[11:49:38.984] OS: Linux, 5.18.12, #1 SMP PREEMPT Mon Jul 18 16:49:09 CEST 2022, aarch64
[11:49:38.984] Flight recorder: enabled
[11:49:38.986] Using config file '/etc/weston-minimal.ini'
[11:49:39.003] Output repaint window is 7 ms maximum.
[11:49:39.007] Loading module '/usr/lib/libweston-10/drm-backend.so'
[11:49:39.016] initializing drm backend
[11:49:39.016] Trying weston_launch launcher...
[11:49:39.019] using /dev/dri/card0
[11:49:39.019] DRM: supports atomic modesetting
[11:49:39.019] DRM: supports GBM modifiers
[11:49:39.019] DRM: supports picture aspect ratio
[11:49:39.021] Loading module '/usr/lib/libweston-10/gl-renderer.so'
[11:49:40.440] EGL client extensions: EGL_EXT_client_extensions
EGL_EXT_device_base EGL_EXT_device_enumeration
EGL_EXT_device_query EGL_EXT_platform_base
EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
EGL_EXT_platform_device EGL_EXT_platform_wayland
EGL_KHR_platform_wayland EGL_EXT_platform_x11
EGL_KHR_platform_x11 EGL_MESA_platform_xcb
EGL_MESA_platform_gbm EGL_KHR_platform_gbm
EGL_MESA_platform_surfaceless
[11:49:40.449] EGL device extensions: EGL_EXT_device_drm
[11:49:40.449] EGL version: 1.4
[11:49:40.449] EGL vendor: Mesa Project
[11:49:40.449] EGL client APIs: OpenGL OpenGL_ES
[11:49:40.449] EGL extensions: EGL_ANDROID_blob_cache
EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2
EGL_KHR_config_attribs EGL_KHR_create_context
EGL_KHR_create_context_no_error EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_partial_update
EGL_KHR_reusable_sync EGL_KHR_surfaceless_context
EGL_EXT_pixel_format_float EGL_KHR_wait_sync
EGL_MESA_configless_context EGL_MESA_drm_image
EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
EGL_WL_bind_wayland_display
[11:49:40.449] EGL_KHR_surfaceless_context available
[11:49:40.552] GL version: OpenGL ES 2.0 Mesa 22.1.4
[11:49:40.552] GLSL version: OpenGL ES GLSL ES 1.0.16
[11:49:40.552] GL vendor: lima
[11:49:40.552] GL renderer: Mali450
[11:49:40.552] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_format_BGRA8888
GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth_texture
GL_OES_packed_depth_stencil GL_OES_get_program_binary
GL_APPLE_texture_max_level GL_EXT_discard_framebuffer
GL_EXT_read_format_bgra GL_NV_pack_subimage GL_EXT_frag_depth
GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_ANGLE_pack_reverse_row_order GL_EXT_texture_rg
GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil
GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug
GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_separate_shader_objects
GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_EXT_blend_func_extended
GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d
GL_EXT_clip_control GL_KHR_parallel_shader_compile GL_MESA_bgra
[11:49:40.757] GL ES 2.0 - renderer features:
read-back format: BGRA
EGL Wayland extension: yes
[11:49:40.783] event0 - gpio_ir_recv: not tagged as supported input device
[11:49:40.783] event0 - not using input device '/dev/input/event0'
[11:49:40.784] event1 - eventlircd: not tagged as supported input device
[11:49:40.784] event1 - not using input device '/dev/input/event1'
[11:49:40.784] warning: no input devices found, but none required as per configuration.
[11:49:40.896] DRM: head 'HDMI-A-1' updated, connector 42 is connected, EDID make 'STK', model 'S2-TEK TV', serial 'SN-000000001'
[11:49:40.896] DRM: head 'HDMI-A-1' found, connector 42 is connected, EDID make 'STK', model 'S2-TEK TV', serial 'SN-000000001'
[11:49:40.897] Registered plugin API 'weston_drm_output_api_v1' of size 24
[11:49:40.897] Color manager: no-op
[11:49:40.897] Output 'HDMI-A-1' using color profile: built-in default sRGB SDR profile
[11:49:40.897] Chosen EGL config details: id: 7 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8888 (0x34325258)
[11:49:40.897] Output HDMI-A-1 (crtc 37) video modes:
1920x1080@60.0, preferred, current, 148.5 MHz
1920x1080@60.0 16:9, 148.5 MHz
1920x1080@59.9 16:9, 148.4 MHz
1920x1080@50.0 16:9, 148.5 MHz
1280x720@60.0, 74.2 MHz
1280x720@60.0 16:9, 74.2 MHz
1280x720@59.9 16:9, 74.2 MHz
1280x720@50.0 16:9, 74.2 MHz
800x600@60.3, 40.0 MHz
720x576@50.0 16:9, 27.0 MHz
720x576@50.0 4:3, 27.0 MHz
720x480@59.9 16:9, 27.0 MHz
720x480@59.9 4:3, 27.0 MHz
[11:49:40.897] Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
[11:49:40.897] 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
[11:49:40.900] Loading module '/usr/lib/weston/desktop-shell.so'
[11:49:40.905] launching '/usr/libexec/weston-keyboard'
[11:49:40.907] Warning: support for deprecated wl_shell interface is enabled. Please migrate legacy clients to xdg-shell.
[11:49:40.908] launching '/usr/libexec/weston-desktop-shell'
root@Myth-Frontend-da19c87a6df4:~ #
```https://gitlab.freedesktop.org/wayland/weston/-/issues/145DRM output writeback support2023-12-11T16:17:19ZDaniel Stonedaniel@fooishbar.orgDRM output writeback supportThe KMS API now has support for [writeback connectors](https://cgit.freedesktop.org/drm/drm-tip/commit/?id=935774cd71fe604cc8ed24adcb507d7784255672), which attach to a CRTC and provide a snapshot of that CRTC's output into a FB ID nomina...The KMS API now has support for [writeback connectors](https://cgit.freedesktop.org/drm/drm-tip/commit/?id=935774cd71fe604cc8ed24adcb507d7784255672), which attach to a CRTC and provide a snapshot of that CRTC's output into a FB ID nominated at atomic commit time.
The DRM backend does not currently provide native support for screenshots. If a screenshot is requested, planes will be temporarily disabled and another output repaint scheduled with the output from the renderer recorded. This is bad because it requires an extra repaint cycle (which isn't great for performance), but also totally precludes its use for debugging any issues with planes.
If supported, we should use a writeback connector to capture the output from the CRTC into a specially-allocated FB which we can then pass directly to the consumer, which avoids the above dance. Constant-capture mode would mean that, at the cost of allocating more buffers, we could also retain snapshots for every repaint for post-mortem debugging (#144).
The same also applies to, e.g., output streaming into VA-API, which would again allow us to use planes where possible.
A good implementation would, I think, proceed in steps of:
* adding awareness of writeback-connector types to the DRM backend, and ignoring them for regular output configuration
* storing lists of writeback connectors in the backends, with a set of CRTCs they can be associated with (maybe they need to be `drm_head`s?)
* the ability to allocate buffers for writeback connectors (I think GBM + `USE_LINEAR` is what we want here) and create `drm_fb`s for them
* the ability to capture content through writeback connectors for one commit on request, falling back to the renderer if unsupported
* using this for screenshots
* using this for screen recording (VA-API etc)
* implementing a per-output screenshot of last-repaint screenshots, to use for post-mortem debugging
Open questions:
* are writeback connectors best exposed as `drm_head`/`weston_head`s which we just make sure libweston ignores?
* how do we allocate buffers: GBM linear or dumb buffers?
* when a screenshot is requested, do we go through another repaint cycle or do we immediately screenshot (potentially delaying the next repaint)?https://gitlab.freedesktop.org/wayland/weston/-/issues/295Remove the partial_dependency workaround2023-12-07T08:11:19ZPekka Paalanenppaalanen@gmail.comRemove the partial_dependency workaroundSee the XXX in https://gitlab.freedesktop.org/wayland/weston/blob/ccf24076ddd42b1523e135e0827a31358d6fbd19/libweston/meson.build#L105 .
Once we require at least Meson 0.50.1, remove the workaround.See the XXX in https://gitlab.freedesktop.org/wayland/weston/blob/ccf24076ddd42b1523e135e0827a31358d6fbd19/libweston/meson.build#L105 .
Once we require at least Meson 0.50.1, remove the workaround.https://gitlab.freedesktop.org/wayland/weston/-/issues/777[BUG]Unable to differentiate connectors by their name when displays are ident...2023-12-06T14:36:19Zsdikshit786[BUG]Unable to differentiate connectors by their name when displays are identicalI have noticed one issue with 2 identical display (2 HDMI with same resolution) I am not able to map the display based on their connector name and it gets changed.
Further investigating I found that the connector name is aasigned from ma...I have noticed one issue with 2 identical display (2 HDMI with same resolution) I am not able to map the display based on their connector name and it gets changed.
Further investigating I found that the connector name is aasigned from make_connector_name().[https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/backend-drm/drm.c#L1400](url)
Here the connector name is formed by combining the connector_type & connector_type_id.
In case of two identical display the connector_type is same and connector_type_id is subject to change based on which device appears first to kernel.
How to fix this?
I have looked a bit into the struct drmModeConnector and I was thinking if we call drmModeGetEncoder() and retrieve the crtc-id from it if that will be unique after bootup?
Please suggest any suitable way for mapping the display.https://gitlab.freedesktop.org/wayland/weston/-/issues/333Clone mode with independent CRTCs2023-12-06T11:42:23ZPekka Paalanenppaalanen@gmail.comClone mode with independent CRTCsWeston already supports shared-CRTC clone mode via `weston.ini`. That mode depends on the kernel driver and the hardware to be able to drive multiple connectors from the same CRTC, which is not a very common feature. When that is not ava...Weston already supports shared-CRTC clone mode via `weston.ini`. That mode depends on the kernel driver and the hardware to be able to drive multiple connectors from the same CRTC, which is not a very common feature. When that is not available, cloning does not work.
To let cloning work in other cases, each cloned connector needs to be driven from its own CRTC, and Weston needs to paint for each CRTC independently. For more information, see #22.
This needs two things:
- A way to configure it in `weston.ini`, different from the `same-as` directive so that users can make the difference between guaranteed synchronized monitor timings (shared-CRTC clone mode) and not -- asynchronous clone mode (independent CRTCs). See also #165.
- Damage tracking fixes inside libweston. Currently damage is tracked in a single region in global coordinate system and cleared respectively when any output repaints its own region. If outputs overlap, the output repainting first will update correctly but the output repainting next won't see the damage anymore, because the first output cleared it on the overlap area.https://gitlab.freedesktop.org/wayland/weston/-/issues/73611.0.0 Weston screen sharing in embedded environment is very laggy with 100% ...2023-12-05T11:22:38Zbot crack11.0.0 Weston screen sharing in embedded environment is very laggy with 100% CPU usageHello,
I have been experiencing a very laggy screen sharing while using Weston 11.0.0 in my embedded environment. The CPU usage also reaches up to 100%. I am using an ARM Cortex-A55 1.5GHz processor and 2GB DDR RAM.
I have performed VN...Hello,
I have been experiencing a very laggy screen sharing while using Weston 11.0.0 in my embedded environment. The CPU usage also reaches up to 100%. I am using an ARM Cortex-A55 1.5GHz processor and 2GB DDR RAM.
I have performed VNC and RDP tests and have configured them in the weston.ini file as follows:
[screen-share]
command=/usr/bin/weston --backend=vnc-backend.so --shell=fullscreen-shell.so
or
[screen-share]
command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/server.crt --rdp-tls-key=/etc/freerdp/keys/server.key
To start the screen sharing, I used the following command:
1. weston --backend=drm-backend.so --modules=screen-share.so
2. Press Ctrl + Alt + S to activate the screen sharing. However, the screen becomes very laggy at this point and CPU usage reaches 100%.
Can you please assist me with resolving this issue in my embedded environment?
Thank you.https://gitlab.freedesktop.org/wayland/weston/-/issues/560Crash on rdp-backend from/by using Windows 10 rdp client2023-11-24T09:35:47ZVyacheslav YurkovCrash on rdp-backend from/by using Windows 10 rdp clientI have pretty recent build of weston from main branch, which I start with rdp backend:
`/usr/bin/weston --backend=rdp-backend.so --rdp-tls-cert tls.crt --rdp-tls-key tls.key` on arm64 board.
I connect to it with Remote Desktop from a Wi...I have pretty recent build of weston from main branch, which I start with rdp backend:
`/usr/bin/weston --backend=rdp-backend.so --rdp-tls-cert tls.crt --rdp-tls-key tls.key` on arm64 board.
I connect to it with Remote Desktop from a Win10 machine. The first connection usually succeeds. But when I close the connection _and_ do not close the Remote Desktop application, but try to reconnect right away I get one of the following:
- either it's https://gitlab.freedesktop.org/wayland/weston/-/issues/509 and connection can't be established;
- or weston crashes. I've got a stacktrace for the crash
```
#0 0x0000ffff812935c4 in notify_motion_absolute (seat=0x0, time=time@entry=0xffffca045d00, x=x@entry=1070, y=y@entry=597) at ../git/libweston/input.c:1837
#1 0x0000ffff80a4ccc0 in xf_mouseEvent (input=<optimized out>, flags=<optimized out>, x=<optimized out>, y=597) at ../git/libweston/backend-rdp/rdp.c:1039
#2 0x0000ffff80937e3c in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#3 0x0000ffff8094af04 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#4 0x0000ffff8094b7e0 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#5 0x0000ffff8093afe0 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#6 0x0000ffff809325e4 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#7 0x0000ffff8094a524 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#8 0x0000ffff80a4ce1c in rdp_client_activity (fd=<optimized out>, mask=<optimized out>, data=0xaaaac2f76ff0) at ../git/libweston/backend-rdp/rdp.c:734
#9 0x0000ffff81230e18 in wl_event_loop_dispatch () from /usr/lib/libwayland-server.so.0
#10 0x0000ffff8122e73c in wl_display_run () from /usr/lib/libwayland-server.so.0
#11 0x0000ffff8144290c in wet_main (argc=<optimized out>, argv=0xffffca046958, test_data=<optimized out>) at ../git/compositor/main.c:3506
#12 0x0000ffff812e6994 in __libc_start_main () from /lib/libc.so.6
#13 0x0000aaaabbb1a738 in _start () at ../sysdeps/aarch64/start.S:91
```
It seems to be a null pointer dereference. If you have any ideas what could be the reason, I could look into it further and fix it probably.https://gitlab.freedesktop.org/wayland/weston/-/issues/3weston_surface_damage does it wrong2023-11-24T01:27:10ZBugzilla Migration Userweston_surface_damage does it wrong## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#18)](https://phabricator.freedesktop.org/T18)**
## Description
```c
/**
* XXX: This function does it the wrong way.
* surfa...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#18)](https://phabricator.freedesktop.org/T18)**
## Description
```c
/**
* XXX: This function does it the wrong way.
* surface->damage is the damage from the client, and causes
* surface_flush_damage() to copy pixels. No window management action can
* cause damage to the client-provided content, warranting re-upload!
*
* Instead of surface->damage, this function should record the damage
* with all the views for this surface to avoid extraneous texture
* uploads.
*/
WL_EXPORT void
weston_surface_damage(struct weston_surface *surface);
```