wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2022-07-28T07:52:10Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/312Store protocol error message for language bindings2022-07-28T07:52:10Zi509VCBStore protocol error message for language bindingsAt the moment there is no way to get the string describing a protocol error from libwayland-client.
Ideally this would involve storing the message and providing a way to access the message.At the moment there is no way to get the string describing a protocol error from libwayland-client.
Ideally this would involve storing the message and providing a way to access the message.https://gitlab.freedesktop.org/wayland/wayland/-/issues/310os: wrap SOCK_CLOEXEC2022-07-31T11:56:38ZWeijia Wangos: wrap SOCK_CLOEXECThe use of SOCK_CLOEXEC has been [abolished in InitWare](https://github.com/InitWare/InitWare/commit/56572184f7ecb994f319fe6949f6dcfba14dacbd) as Linuxism unsupported by macOS.
Additionally, fixing this would allow Wayland (**with libra...The use of SOCK_CLOEXEC has been [abolished in InitWare](https://github.com/InitWare/InitWare/commit/56572184f7ecb994f319fe6949f6dcfba14dacbd) as Linuxism unsupported by macOS.
Additionally, fixing this would allow Wayland (**with libraries**, without tests) to be built on macOS, which supersedes !136.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/98zxdg_exported_v2 is not required to outlive underlying surface2022-08-14T04:24:19Zi509VCBzxdg_exported_v2 is not required to outlive underlying surfacezxdg_exported_v2 or it's factory request does not state the exported handle must be destroyed before the originating surface is destroyed.zxdg_exported_v2 or it's factory request does not state the exported handle must be destroyed before the originating surface is destroyed.https://gitlab.freedesktop.org/wayland/weston/-/issues/641[Request] Add other indicators other than clock / date & launcher on panel.2023-04-05T17:48:49Zlidg nulinux[Request] Add other indicators other than clock / date & launcher on panel.It will be great to see a feature when we can add something other than clock /date & launcher, for example, passing bash script output to panel. It's just a request and I'm happy to wait. Thanks.It will be great to see a feature when we can add something other than clock /date & launcher, for example, passing bash script output to panel. It's just a request and I'm happy to wait. Thanks.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/639[Request] Better compatibility with `plymouth deactivate` / (Don't draw an al...2022-07-25T21:44:16Zn3rdopolis[Request] Better compatibility with `plymouth deactivate` / (Don't draw an all black rectangle upon startup?)Hi
One thing that would be cool is if Weston didn't blank the screen upon startup.
![weston2weston](/uploads/1f47c01924bc612518461c95adeb3798/weston2weston.webm)
Currently you can see that there is a very small blip where it's all blac...Hi
One thing that would be cool is if Weston didn't blank the screen upon startup.
![weston2weston](/uploads/1f47c01924bc612518461c95adeb3798/weston2weston.webm)
Currently you can see that there is a very small blip where it's all black for a bit when it starts.
Gnome Shell somehow does it a little better, it never blacks out the screen. It does do a gray window, which looks somewhat better
![weston2gnome](/uploads/7ad5377a468130fcf1017dd5f3a5e3f3/weston2gnome.webm)
I am not sure how they do it, but if Weston could do the same thing that would be pretty sweet, there's a longer pause for it to display anything, but it's less flickery
This is on a system without VTs BTW, so this might be why it's a bit cleaner
But here's what it looks like going to Plymouth to Weston
(Plymouth needs more work to better support systems without VTs at time of writing)
![plymouth2weston](/uploads/50f90f4a3ff14c5c5d081d193abbc303/plymouth2weston.webm)
This is `plymouth deactivate`, it holds onto the last display of the splash, but it lets another display server take over /dev/dri/cardx
There is a small window of time where it's all black, and that really appears to be weston itself, as when I start Weston under Weston it's all black too.
Maybe the root surface can be all alpha or something, or hidden, but I don't know if that would really work.
If it's not possible, and takes too much work, it's not pressing, but it would be cool for flicker free boot...
Thankshttps://gitlab.freedesktop.org/wayland/wayland/-/issues/304Validate reference counts using asserts2022-07-04T07:15:48ZDemi Marie Obenourdemiobenour@gmail.comValidate reference counts using assertsReference counts in e.g. wl_shm should be validated with assertions, so that overflows and underflows result in a clean crash instead of a use-after-free. The only known way for a client to trigger this was fixed by capping the size of ...Reference counts in e.g. wl_shm should be validated with assertions, so that overflows and underflows result in a clean crash instead of a use-after-free. The only known way for a client to trigger this was fixed by capping the size of wl_map, so this is purely to guard against buggy compositors that leak references.https://gitlab.freedesktop.org/wayland/weston/-/issues/634Deprecate and remove cms-static and cms-colord Weston plugins2023-10-05T14:02:14ZPekka Paalanenppaalanen@gmail.comDeprecate and remove cms-static and cms-colord Weston pluginsWeston (not libweston) has two legacy color management related plugins: cms-static and cms-colord.
These two plugins are for supporting the X11 style of color management: the job of the display server is to program the gamma LUT into ha...Weston (not libweston) has two legacy color management related plugins: cms-static and cms-colord.
These two plugins are for supporting the X11 style of color management: the job of the display server is to program the gamma LUT into hardware, and all actual color processing happens in applications (if at all). cms-static loads the ICC file named in `weston.ini` and cms-colord finds an ICC file through colord D-Bus API. They both extract only the VCGT tag from the profile, and tell libweston to load that table into hardware.
This mode of operation is incompatible with the new Wayland color management being planned in wayland/wayland-protocols!14. In the new design, a Wayland compositor loads the output ICC profile and is also responsible for the actual color processing which depends on what Wayland clients say about how they use color (Wayland clients still have the option to do the color processing themselves, too). The VCGT tag, when it exists, is still used by the compositor, but the compositor also does more.
The incompatibility arises from implementation details. Libweston's new color manager, color-lcms, already supports loading ICC files for outputs. The color manager architecture defines APIs for how hardware color pipeline is programmed through KMS. The new API conflicts with the old set_gamma API. The old API needs to be removed, which will break cms-static and cms-colord.
One option would be to change cms-static and cms-colord to use the color manager API to load the ICC files they discover. However, this will likely be a change in behavior because as said, in the new design the compositor does more than just VCGT. That could be seen as a breaking change too. Furthermore, color-lcms has higher requirements (OpenGL features and renderer performance) than the old set_gamma.
When color-lcms is in use, a compatible way of loading ICC files through `weston.ini` is already implemented. Furthermore it is unclear what role colord will have in the new color management architecture, so fetching monitor ICC profiles from colord may not be useful.
Therefore I propose to deprecate right now, and immediately after the release of libweston 11 to remove cms-static and cms-colord plugins. This allows to garbage-collect the old set_gamma API.
My assumption is that these two plugins have no users, and the deprecation process is the way to find out if that's true.
If these plugins have users who cannot migrate to the new color management design e.g. due to performance reasons or because the new color management architecture is not fully implemented yet, I believe it would be possible to find a way to keep these plugins working as long as color-lcms is not in use.14.0.0Pekka Paalanenppaalanen@gmail.comPekka Paalanenppaalanen@gmail.comhttps://gitlab.freedesktop.org/wayland/weston/-/issues/632Chop parts of libweston/compositor.c into new files2023-10-05T14:00:52ZPekka Paalanenppaalanen@gmail.comChop parts of libweston/compositor.c into new files`libweston/compositor.c` file is too long to be manageable.
Split at least some pieces out of it into new files, verbatim.
Potential candidates: `head.c`, `output.c`, `surface.c`
This will be a mechanical and disruptive change, so it ...`libweston/compositor.c` file is too long to be manageable.
Split at least some pieces out of it into new files, verbatim.
Potential candidates: `head.c`, `output.c`, `surface.c`
This will be a mechanical and disruptive change, so it should be done immediately when a development cycle opens after a release.14.0.0https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/97Receive feedback about xdg_toplevel_move2022-08-30T12:05:26ZFinaReceive feedback about xdg_toplevel_moveAs far as I understand, there currently is no way to determine whether `xdg_toplevel_move` is actually performing an action or if the request is being ignored. It could be ignored for several reasons (compositor does not allow for freefo...As far as I understand, there currently is no way to determine whether `xdg_toplevel_move` is actually performing an action or if the request is being ignored. It could be ignored for several reasons (compositor does not allow for freeform surface positioning like on many mobile compositors, surface is maximized, etc).
This information would be useful to determine further steps after initiating the move (show a different cursor when move is not possible, pass the movement information further along etc).
When resizing the surface will get the `resizing` state, could this be expanded to also have a `moving` state that would be set when the toplevel is currently in the process of being moved? To make this more useful and actually do something with the events, this would probably need the added requirement on `xdg_toplevel_move` to not lose focus of the device when a move is not actually taking place.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/96Allow contributions from GitLab private e-mail2023-05-14T05:59:11Zwb9688Allow contributions from GitLab private e-mailWhen I made !155 and !156 I noticed that CI does not like using the GitLab private e-mail. It looks like that was intentional: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/blob/master/tools/ci_fairy.py#L193 . In my opinion c...When I made !155 and !156 I noticed that CI does not like using the GitLab private e-mail. It looks like that was intentional: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/blob/master/tools/ci_fairy.py#L193 . In my opinion contributions from a GitLab private e-mail should be allowed, so that you do not have to publicly share your real e-mail. I also think that a GitLab user would still be enough to identify who made it and it is also still possible to contact the person on GitLab by mentioning that username.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/95Support for Private Windows2024-02-26T18:52:58Z-Support for Private WindowsInspired by the following [post](https://gitlab.gnome.org/GNOME/mutter/-/issues/2186).
The Chromium team has an existing protocol as found on the Chrome Git repository [post](https://chromium.googlesource.com/chromium/src/+/main/third_p...Inspired by the following [post](https://gitlab.gnome.org/GNOME/mutter/-/issues/2186).
The Chromium team has an existing protocol as found on the Chrome Git repository [post](https://chromium.googlesource.com/chromium/src/+/main/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml).
I'm looking for the possibility to tag specific surfaces with a "private" or "secure" tag. This tag would prevent screencasting applications the ability to capture the app's graphics. This could be useful when the entire screen is being captured and an application like a password manager gets opened, where a leak could be disastrous.
I'm unsure if wayland, the x-d-p permission store, or both would be the right place for this, as it would be preferred for apps to hint this themselves while also allowing users the option to forcefully disable (or enable) this hint on a per-app basis.
I know Windows does this already in some way to prevent videos with DRM from being captured. It blocks the capturing and replaces it with a complete black screen. This seems to be done with the parameter found [here](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowdisplayaffinity).
Edit: OBS has implemented [something like this](https://github.com/obsproject/obs-studio/pull/8623) for Mac. It gives an option to hide to OBS window from being recorded, to hide stream settings being changed or to hide the mirror effect.
Discord also has implemented a similar option in their software when Streamer Mode is enabled: "Hides most Discord windows from most screen capturing software."https://gitlab.freedesktop.org/wayland/weston/-/issues/629weston's xwayland window manager does not support _NET_REQUEST_FRAME_EXTENTS2022-06-22T13:39:28ZDerek Foremanweston's xwayland window manager does not support _NET_REQUEST_FRAME_EXTENTSAs mentioned on !919, we don't yet support [_NET_REQUEST_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm46400537402896), which is useful for letting some clients render their first frame properly.As mentioned on !919, we don't yet support [_NET_REQUEST_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm46400537402896), which is useful for letting some clients render their first frame properly.https://gitlab.freedesktop.org/wayland/weston/-/issues/628Weston is not receiving touch input (regarding touch input as mouse input)2024-01-29T10:12:42ZUlysses Zhanulysseszhan@gmail.comWeston is not receiving touch input (regarding touch input as mouse input)I connected my computer with a touchscreen. My GNOME applications handles the touch events expectedly except Weston, which regards my touch input as mouse input. I tested touch using `weston-simple-touch`, but nothing is drawn on the int...I connected my computer with a touchscreen. My GNOME applications handles the touch events expectedly except Weston, which regards my touch input as mouse input. I tested touch using `weston-simple-touch`, but nothing is drawn on the interface if I use touchscreen to touch on it.
- OS Name: Ubuntu 20.04.4 LTS
- GNOME version: 3.36.8
- Windowing System: X11
- Weston version: 8.0.0
- `cat ~/.config/weston.ini`:
```
[core]
idle-time=0
require-input=false
xwayland=true
[libinput]
touchscreen_calibrator=true
calibration_helper=/usr/bin/save-calibration.sh
enable-tap=true
tap-and-drag=true
tap-and-drag-lock=true
[shell]
binding-modifier=ctrl
panel-position=none
locking=false
animation=none
close-animation=none
startup-animation=none
auto-zap=true
[terminal]
font=JetBrains Mono
```
- `xinput` (the device with `id=24` is my touchscreen input device):
```
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ MSFT0001:00 06CB:CE2D Mouse id=28 [slave pointer (2)]
⎜ ↳ MSFT0001:00 06CB:CE2D Touchpad id=29 [slave pointer (2)]
⎜ ↳ SEMICO USB Keyboard Consumer Control id=11 [slave pointer (2)]
⎜ ↳ Wacom Intuos P M 2 Pen stylus id=25 [slave pointer (2)]
⎜ ↳ deltainno Smartisan TNT go Touchpad id=21 [slave pointer (2)]
⎜ ↳ Wacom Intuos P M 2 Pad pad id=26 [slave pointer (2)]
⎜ ↳ ITE Tech. Inc. ITE Device(8910) Keyboard id=17 [slave pointer (2)]
⎜ ↳ USB OPTICAL MOUSE id=14 [slave pointer (2)]
⎜ ↳ deltainno Smartisan TNT go id=24 [slave pointer (2)]
⎜ ↳ deltainno Smartisan TNT go Keyboard id=20 [slave pointer (2)]
⎜ ↳ deltainno Smartisan TNT go Mouse id=23 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Ideapad extra buttons id=27 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ deltainno Smartisan TNT go Wireless Radio Control id=22 [slave keyboard (3)]
↳ SEMICO USB Keyboard Consumer Control id=31 [slave keyboard (3)]
↳ SEMICO USB Keyboard id=10 [slave keyboard (3)]
↳ SEMICO USB Keyboard System Control id=12 [slave keyboard (3)]
↳ SEMICO USB Keyboard id=13 [slave keyboard (3)]
↳ Power Button id=9 [slave keyboard (3)]
↳ ITE Tech. Inc. ITE Device(8910) Wireless Radio Control id=18 [slave keyboard (3)]
↳ ITE Tech. Inc. ITE Device(8910) Keyboard id=32 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ ICT Camera: ICT Camera id=19 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=30 [slave keyboard (3)]
↳ Integrated Camera: Integrated C id=16 [slave keyboard (3)]
↳ Generic USB Condenser Microphone id=15 [slave keyboard (3)]
↳ deltainno Smartisan TNT go Keyboard id=33 [slave keyboard (3)]
```https://gitlab.freedesktop.org/wayland/weston/-/issues/627touch event received with 3 points down but no surface focused2023-11-09T10:03:42ZSören Meiersoerenmeier@livgood.chtouch event received with 3 points down but no surface focusedWell this is another weird one but on other hardware than #625.
## Setup
Weston version 10.0.0 with a protocol addition (to kiosk-shell) which triggers `weston_compositor_sleep` or `weston_compositor_wake` via a motion sensor. For refer...Well this is another weird one but on other hardware than #625.
## Setup
Weston version 10.0.0 with a protocol addition (to kiosk-shell) which triggers `weston_compositor_sleep` or `weston_compositor_wake` via a motion sensor. For reference (https://gitlab.freedesktop.org/soerenmeier/weston/-/commit/6ddfbd67a20fb60ff84bde423749d1eaa4c09b74) don't think it matters particularly.
The application that is run is chromium.
## Device
Touchscreen: eGalax Inc. eGalaxTouch P80H100 2700 vW50-T6 k07_117
[weston_startup.txt](/uploads/b86f794d5cc68e21d6d177e9f2f95c24/weston_startup.txt)
## Problem
The problem occurred only twice in the last 2 weeks and in the previous 3 months i never observed it, weston was never updated in that time but the os (buildroot) was but just bugfixes (systemd, linux...).
At some point the touch just stops working and weston outputs the following `touch event received with 3 points down but no surface focused`. Launching weston-flower or restarting chromium does not fix the problem.
Is this a hardware bug or driver bug? Since there is already this message that is printed, maybe weston could recover from it?
https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/input.c#L2405-2415
## Edit
Running weston-debug timeline or proto shows that its always updating the screen [weston_debug_proto.txt](/uploads/32c1d7bbffb7e8f612712fa6d4bd393d/weston_debug_proto.txt).
Will keep the device in this state if i should run some more tests or get some more data.https://gitlab.freedesktop.org/wayland/wayland/-/issues/300Clarify behavior of client-side buffer storage destruction before wl_buffer.r...2023-06-09T13:25:14ZAlexandros FrantzisClarify behavior of client-side buffer storage destruction before wl_buffer.releaseAfter https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/141, the spec says on this matter:
> Destroying the wl_buffer before wl_buffer.release is allowed as long as the underlying buffer storage isn't re-used (this can hap...After https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/141, the spec says on this matter:
> Destroying the wl_buffer before wl_buffer.release is allowed as long as the underlying buffer storage isn't re-used (this can happen e.g. on client process termination). However, if the client destroys the wl_buffer before receiving the wl_buffer.release event and mutates the underlying buffer storage, the surface contents become undefined immediately.
This wording seems to me to allow (or I am misunderstanding the concepts of buffer storage not being re-used or mutated?) for one-shot buffer commit scenarios at points other than client process termination (which is used only as an example):
1. client: attach wl_buffer A to wl_surface S
2. client: commit wl_surface S
3. client: destroy wl_buffer A and backing buffer storage (e.g., SHM memory).
4. compositor: wl_surface S is presented with wl_buffer A contents until the next attach/commit
Some clients (e.g, Wine Wayland) currently use this one-shot feature, misbehaving under, e.g., Weston which doesn't fully support this (see https://gitlab.freedesktop.org/wayland/weston/-/issues/604). If this not a supported scenario, perhaps we can update the spec wording to further clarify this?https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/94Tray icon protocol2022-05-12T18:21:31ZDemi Marie Obenourdemiobenour@gmail.comTray icon protocolThe StatusNotifierIcon standard works for clients running on the same kernel, but as it is based on D-Bus, it doesn’t work for clients running in guests using virtio-wl. The X11 solution (XEmbed) is obviously not available under Wayland.The StatusNotifierIcon standard works for clients running on the same kernel, but as it is based on D-Bus, it doesn’t work for clients running in guests using virtio-wl. The X11 solution (XEmbed) is obviously not available under Wayland.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/93Problems related to the lack of GPU preemption2022-05-17T17:01:16ZDemi Marie Obenourdemiobenour@gmail.comProblems related to the lack of GPU preemptionhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/92#note_1379786 pointed out a denial of service attack on compositors that use dma-bufs. However, I think there is actually a broader class of problems: the lack of effec...https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/92#note_1379786 pointed out a denial of service attack on compositors that use dma-bufs. However, I think there is actually a broader class of problems: the lack of effective GPU preemption means that a rogue client can hog the GPU for an unpredictable amount of time. This is a nasty problem for any GPU use with untrusted tenants, not just Wayland.
There are two solutions I can think of:
1. Partition the GPU (either in software or hardware) such that each tenant has access to a disjoint subset of GPU resources. That tenant can lock up the resources it has been assigned, but is not able to interfere with other tenants.
2. Ensure that on-GPU computations can be involuntarily preempted in a small and bounded amount of time.
In either case, enforcement must be by means of the kernel driver and/or the compositor, even if the other parts of the system are malicious. While local DoS from a userspace process is typically not considered very serious, the same problems arise with any form of GPU virtualization that works on ordinary hardware with FLOSS drivers (read: does not rely on hardware SR-IOV).https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/92Todo article: Caveats of sending file descriptors over a security boundary2023-06-14T16:45:01ZPekka Paalanenppaalanen@gmail.comTodo article: Caveats of sending file descriptors over a security boundaryI couldn't think of a good place where to file this idea, but since Wayland is a security boundary and the most familiar to me, this is here for starters.
We should have a peer reviewed article somewhere explaining the security problems...I couldn't think of a good place where to file this idea, but since Wayland is a security boundary and the most familiar to me, this is here for starters.
We should have a peer reviewed article somewhere explaining the security problems around sharing file descriptors between processes which have a security boundary between them. Wayland and DBus come to mind.
This write-up was inspired by https://gitlab.freedesktop.org/wayland/wayland/-/issues/296.
----
# Caveats of sending file descriptors over a security boundary
Most problems stem from the fact that while sharing a *file descriptor* to another process creates a new independent file descriptor in that other process, both the original and the new file descriptor still point to the same *file description*. The file description, not the file descriptor, holds important metadata that you might not expect to change from under you.
The only way to create a new file description is the `open()` syscall. `dup()` and all other fd dupping functions only create a new file descriptor pointing to the original file description.
Here are some problems when you have a file descriptor pointing to a shared file description:
- **Regular file contents:** The remote party can modify the file contents at any time. Opening a read-only file description and sending that may not be a reliable way to stop the remote side from writing, and only if the local side is the one opening the file.
- **Regular file size:** The remote party can change the file size at any time with e.g. `ftruncate()` call. This is particularly hazardous when you `mmap()` the fd, as it exposes you to getting `SIGBUS` signals.
- **File offset:** The classic file read and write operations use *the file offset* as the position in the file to read from or write to. File offset is stored in file description, and therefore the remote side can change it at any time. Using `pread()` and `pwrite()` avoids this problem.
- **Open file flags:** Flags are stored in the file descriptor, including `O_NONBLOCK`. The remote side can change the flags at any time. E.g. removing `O_NONBLOCK` can result in your program stalling unexpectedly on a read or write, as a form of denial of service.
- **Polling:** The remote side can read and write the fd at any time, making your `poll()` for readable or writable unreliable.
Furthermore, sharing DRM device file descriptors has special caveats:
- **DRM master:** DRM master status (the ability to drive KMS) is stored with the file description. If you have it, then the remote side can also program whatever it wants to KMS.
- **FB IDs:** Framebuffer and KMS property blob IDs are tied to the file description. If you have an ID, the remote side can guess that ID or simply read it out from KMS, and at least read its contents back. This can be used for e.g. spying on screen contents. This may or may not be conditional to holding DRM master status.https://gitlab.freedesktop.org/wayland/wayland/-/issues/296client-allocated clipboard-transfer buffers lead to DOS attacks on the sender2022-05-14T10:04:02ZJulian Orthclient-allocated clipboard-transfer buffers lead to DOS attacks on the senderThe core and the primary-selection protocol currently mandate that clipboard-transfer file descriptors are allocated by the recipient. Unless very careful programming is applied on the sender-side, this can lead to the sender ceasing to ...The core and the primary-selection protocol currently mandate that clipboard-transfer file descriptors are allocated by the recipient. Unless very careful programming is applied on the sender-side, this can lead to the sender ceasing to operate normally. I have confirmed that a malicious but unprivileged client can completely lock up sway, plasma, and gnome using this vulnerability.
---
Let's assume that the attacker has allocated a pipe for the data transfer. At some point the sender has to perform a `write`-like operation on the write-end of the pipe. If the classic `write(2)` system call is used, then the sender must do one of two things to prevent this call from blocking indefinitely:
1. Call `poll(2)` before the write call to ensure that at least 1 byte can be written.
2. Set the file descriptor to `O_NONBLOCK` before calling `write(2)`.
Neither of those are sufficient. If 2 is applied, then the attacker can remove the `O_NONBLOCK` flag in a loop so that the `write(2)` call in the sender operates on a blocking file description.
If 1 is applied, then the attacker can call `read(2)` and `write(2)` themselves in a loop so that the `write(2)` in the sender will likely operate on a full pipe.
---
sway, plasma, and gnome are currently vulnerable to this attack in their xwayland code. If a selection was performed in an xwayland client, an unprivileged pure-wayland attacker that gains the keyboard focus can request this selection to be transferred to it. In this case the sender is the compositor itself and the compositor locks up because it is blocked in a `write(2)` call.
---
I know of two ways to work around this attack:
1. Fork a new process to perform the transfer, this process can be killed after a timeout if it becomes unresponsive.
2. Use the linux-specific io_uring set of system calls. These system calls can perform asynchronous operations even on blocking file descriptors and such operations can be cancelled.
---
As even the compositors themselves are vulnerable, clients cannot be expected to deal with this. In a future protocol version, these pipes should be allocated by the compositor itself to ensure that neither side can gain access to the other end of the pipe.
---
The following rust code demonstrates the attack:
```rust
eprintln!("got selection");
let (rx, tx) = uapi::pipe().unwrap();
unsafe {
c::fcntl(tx.raw(), c::F_SETPIPE_SZ, 4096);
}
let mut buf = [0u8; 4096];
uapi::write(tx.raw(), &mut buf[..]).unwrap();
offer.receive(connhandle, "text/plain".to_string(), tx.raw());
thread::spawn(move || {
loop {
let n = uapi::read(rx.raw(), &mut buf[..]).unwrap();
eprintln!("read {} bytes", n.len());
uapi::write(tx.raw(), &mut buf[..1]).unwrap();
let fl = uapi::fcntl_getfl(tx.raw()).unwrap();
if fl != c::O_WRONLY {
uapi::fcntl_setfl(tx.raw(), c::O_WRONLY).unwrap();
}
}
});
```
In your X application you might have to copy a significant chunk of data to trigger the lockup. Using a slightly modified program, the lockup can be triggered in sway and plasma even if only a single byte has been copied.