wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2023-12-04T14:30:55Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/846ivi-shell: setting surface visibility to 0 does not prevent the content from ...2023-12-04T14:30:55ZAlexandru N. Oneaivi-shell: setting surface visibility to 0 does not prevent the content from being renderedI am implementing a custom controller for the `ivi-shell` together with a custom protocol. The protocol defines a request that a client can make to the controller to remove an `ivi_surface` from a certain output. The implementation of th...I am implementing a custom controller for the `ivi-shell` together with a custom protocol. The protocol defines a request that a client can make to the controller to remove an `ivi_surface` from a certain output. The implementation of this request on the controller side, for the moment, just sets the visibility of the respective `ivi_layout_surface` to `0` and calls `commit_changes`. I was expecting that after that, the content of the surface is no longer visible on the screen, but it is.
Am I missing something?https://gitlab.freedesktop.org/wayland/wayland/-/issues/425Monitor detection (multiple variable refresh rate monitors) causing AMDGPU cr...2023-11-27T11:44:07ZW olfickMonitor detection (multiple variable refresh rate monitors) causing AMDGPU crashesI believe this is a wayland specific bug as it occurs in both Gnome and KDE when running a Wayland session. If you still believe this is the compositor/arch, please let me know and help link the issue and/or redirect me. Apologies if thi...I believe this is a wayland specific bug as it occurs in both Gnome and KDE when running a Wayland session. If you still believe this is the compositor/arch, please let me know and help link the issue and/or redirect me. Apologies if this is a bit long winded (it's the only way I know). This has been an issue many times in the past I believe, but that was solved and this is now caused by something recent.
<details><summary>System info</summary>
---------------------------------<br/>
Most of this is not overly relevant, as I replicated the issue on live installations that do not have my settings/themes etc<br/><br/>
OS: Arch Linux<br/>
Kernel: x86_64 Linux 6.6.2-arch1-1<br/>
Uptime: 53m<br/>
Packages: 1287<br/>
Shell: zsh 5.9<br/>
Resolution: No X Server<br/>
DE: GNOME 45.1<br/>
WM: Mutter<br/>
WM Theme: Orchis-Green-Dark<br/>
GTK Theme: Orchis-Orange-Light [GTK2/3]<br/>
Icon Theme: BeautyLine<br/>
Font: Cantarell 11<br/>
Disk: 1.2T / 27T (5%)<br/>
CPU: AMD Ryzen 7 5800X3D 8-Core @ 16x 3.4GHz<br/>
GPU: AMD Radeon RX 7900 XT (gfx1100, LLVM 16.0.6, DRM 3.54, 6.6.2-arch1-1)<br/>
RAM: 4759MiB / 32019MiB<br/>
<br/>
Monitor 1:<br/>
ASUS TUF Gaming VG27AQL1A<br/>
Size: 27"<br/>
Refresh rate: 170Hz<br/>
<br/>
Monitor 2:<br/>
ASUS TUF Gaming VG35VQ<br/>
Size: 35"<br/>
Refresh rate: 100Hz<br/><br/>
---------------------------------<br/>
</details>
The detection of multiple variable-refresh-rate monitors is causing amdgpu, and subsequently the displays, to crash. It also struggles at the end of a session? It only occurs with multiple monitors and on a wayland session.
**Triggers that cause it**
- Turning the monitors off, then back on again.
- Changing refresh rate of the monitors.
- Booting the pc from sleep/hibernation.
- Logging out.
- Restarting
- Shutting down (Minor effect. The display just hangs for 5+ seconds after sending poweroff command before shutting down)
**Bug replications**
In order to ensure this was not a bug introduced by anything I had installed or customized incorrectly, I replicated this bug using live installation media. I only used Manjaro live media as I could not start an Ubuntu session in wayland from the live media. Of note, this does not occur in the Manjaro release from earlier this year (or before that), it has only appeared in the last couple of months.
- Manjaro-gnome release 22.0.4-230222 (Feb 22) : Does not occur
- Manjaro-gnome release 23.0.4-231015 (Oct 15) : Does occur
- Manjaro-kde release 23.0.4-231015 (Oct 15) : Does occur
- Arch Linux latest firmware/kernel as of Nov 27 : Does occur
**Other effects/notes of the bug**
I haven't been able to stably replicate the below, or they have occured on my system which I haven't been able to isolate from everything else.
- During a long session, the screen can start to lag and pause momentarily, especially using Brave (or other browsers?)
- After a long session, the shutdown script is spammed with [drm:dc_dmub_srv_cmd_run_list [amdgpu]] *ERROR* Error queueing DMUB command: status=2
- Dmesg also has the above amdgpu error consistently within it (I have attached the dmesg output)
- journalctl also displays how severe this amdgpu error is spamming (also attached. format: `journalctl -r | grep amdgpu`)
- After restoring from sleep (when it does succeed) and maybe logout+login again, moving the mouse over the border of the gnome screenshot frame box (into the box or out of it) will cause the display to have a 1 second delay with 100% consistency.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/166Pointer confinement: wrapping2024-03-24T16:28:41ZDallas StrousePointer confinement: wrappingCurrently, with pointer confinement, you can lock it to a specific position or set it to stay within a certain region. I'd like to propose that the region confinement portion be extended to be able to specify "wrapping" behavior.
zwp_c...Currently, with pointer confinement, you can lock it to a specific position or set it to stay within a certain region. I'd like to propose that the region confinement portion be extended to be able to specify "wrapping" behavior.
zwp_confined_pointer_v1 would gain two new requests, and two new events:
Requests:
- zwp_confined_pointer_v1::set_wrapping
- zwp_confined_pointer_v1::unset_wrapping
Events:
- zwp_confined_pointer_v1::wrapping
- zwp_confined_pointer_v1::not_wrapping
To explain how this would work, imagine you have a 10x10 window. You have a cursor at (0, 5), dead on the west side. You move it along the X axis, all the way to (10, 5), and the cursor *would* keep on going to be outside of that 10x10 window. Instead, if you set `set_wrapping`, you'd be able to define the behavior that it *should* end up at (0, 5) again, and it would wrap indefinitely.
Imagine if you had a grid of that 10x10 window, and wherever you went outside, you'd instead step right into the next window in that position. Here's some relevent example from a manga I was reading that used the same idea :)
![image](/uploads/4fb6d85966a06f710fce2eb02ba6a0aa/image.png) ![image](/uploads/9eef63dc6a733b559e6508c868a65da2/image.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/424Document that wl_display_connect() is not thread safe2023-11-26T02:56:33ZM. StoecklDocument that wl_display_connect() is not thread safeIf the environment variable WAYLAND_SOCKET is defined, `wl_display_connect()` can call the non-threadsafe `unsetenv()` and interfere with other threads calling `getenv()` at the same time.
The documentation for the function should warn ...If the environment variable WAYLAND_SOCKET is defined, `wl_display_connect()` can call the non-threadsafe `unsetenv()` and interfere with other threads calling `getenv()` at the same time.
The documentation for the function should warn about this.https://gitlab.freedesktop.org/wayland/wayland/-/issues/423protocol: Introduce a transparent region (proposal)2024-02-12T18:01:42ZRobert Maderprotocol: Introduce a transparent region (proposal)Just an idea I had in a feverish moment but I think is worthy discussing:
## Idea
Analogous to the opaque region: a hint about a region of a surface that's fully transparent and thus never needs to get drawn. Crucially: it never needs ...Just an idea I had in a feverish moment but I think is worthy discussing:
## Idea
Analogous to the opaque region: a hint about a region of a surface that's fully transparent and thus never needs to get drawn. Crucially: it never needs to get blended with underlying content.
The transparent region and the opaque region must not overlap, otherwise -> protocol error.
Setting a transparent region for a surface with an opaque / alpha-less format -> protocol error (or ignore?).
## Motivation
Opaque regions have proven to be crucial for good compositor performance, especially floating window desktop use-cases. Transparency has traditionally been less important as usually it's not expected that apps leave big parts of surfaces unused. There is, however, at least one class of increasingly popular patterns where this is the case: overlays or "hole punching". I.e. a subsurface with (usually imported) content below a rendered overlay surface.
From https://blog.gtk.org/2023/11/15/introducing-graphics-offload/ for visualization:
![bbb-below](/uploads/a05350c2ea5fcd96cd40a507565172a6/bbb-below.png)
So far this is mostly done in embedded environments where it's unlikely that the compositor would ever have to pay the price of blending on the GPU (using hw planes instead). Which maybe explains why this issue wasn't brought up before (at least I couldn't find any issue).
There are several recent developments that IMO make it worth to optimize the composited case more:
1. desktop environments are picking up the approach:
- way more cases where the GPU fallback is required
- current situation forcing implementations to add complex workarounds is tiresome (see further below)
2. color mangement / HDR:
- blending will become (potentially much) more expensive
- apps/toolkits will likely pick up the approach in order to show HDR content while keeping their rendering engines SDR (as previously seen on MacOS).
A transparent region hint would allow compositors to massively reduce or completely skip blending. In cases where surface is fully transparent compositors could skip a hw plane assignment (important in cases planes are rare, from the hardware or software side).
WDYT?
## Notes
Coincidentally such a hint would also provide solution(s) for https://gitlab.freedesktop.org/wayland/wayland/-/issues/266:
- apps like the video player example above wouldn't need to care about bringing the video surface to the foreground, the "main" surface that receives the frame callbacks would always stay on top.
- similarly, complex clients consisting of many subsurfaces could have an invisible "cover" surfaces for callback and input handling. Even the Firefox Wayland backend as shipped today could use this approach, putting the "content" subsurface below the toplevel one. The only reason it doesn't do so today is the blending overhead.
---
cc @mclasen @pq @daniels @swick @jadahlhttps://gitlab.freedesktop.org/wayland/weston/-/issues/844Mouse click event issue on rdp + chromium2023-11-23T09:16:13ZHimanshu BhavaniMouse click event issue on rdp + chromiumHi @mvlad weston rdp working fine at client and server side but when I run chromium browser I am not able to access chromium from client rdp desktop.
It is looks like mouse is hiding behind the chromium on rdp windows.
I have found this ...Hi @mvlad weston rdp working fine at client and server side but when I run chromium browser I am not able to access chromium from client rdp desktop.
It is looks like mouse is hiding behind the chromium on rdp windows.
I have found this type of issue is already open in here https://monorail-prod.appspot.com/p/chromium/issues/detail?id=1284377
Is there any solution for this ?
I am using weston version 10.https://gitlab.freedesktop.org/wayland/weston/-/issues/843Gstreamer waylandsink sometimes not showing.2024-03-26T09:22:33ZRob KramerGstreamer waylandsink sometimes not showing.My application (signage software) plays video using Gstreamer and waylandsink. For unknown reason, sometimes the waylandsink overlay does not show at all when the video starts, meaning that only whatever the application drew underneath t...My application (signage software) plays video using Gstreamer and waylandsink. For unknown reason, sometimes the waylandsink overlay does not show at all when the video starts, meaning that only whatever the application drew underneath the video area is visible. This happens in any Weston I have access to (weston 10 on drm, weston 12 nested on mutter/gnome), but not when the application directly runs on mutter or sway. To the software and logs it is completely invisible that the video overlay didn't show; from the logging it looks like gstreamer happily plays the video the same way.
The chance that a video starts with a missing overlay is high when the file is large, such as a 4k mp4 video. The host PC's performance probably also affects it. This very likely points to some race condition in my application that triggers this behaviour on Weston, but I can't find anything significant after being on this issue for days..
I found that when the issue occurs and the overlay is missing, any movement of the mouse will suddenly rectify the situation. I've tried adding gstreamer calls to force redraws (gst_overlay_video_expose), but that doesn't help and could be at the wrong layer to start with.
- How could I go about debugging this issue?
- What does a single pixel mouse move do to Weston that completely fixes the overlay?
- Is there a 'refresh' call that I can make that has the same effect?
I've distilled sections from two weston logs that do 'proto' logging of a good video start and a bad video start, and tried to compare them with meld. Unfortunately, I can't make much sense of the result, and am not even sure if wayland protocol logging would be useful at all.. I someone wants to have a look at those logs, I can attach them.https://gitlab.freedesktop.org/wayland/weston/-/issues/842Weston (Kiosk Mode) Launches Black Screen in X112023-11-21T17:23:01ZVehementHamWeston (Kiosk Mode) Launches Black Screen in X11The normal mode works fine. Whin I add `client=` to the config, things get messy. Here is the conig
```ini
[launcher]
icon=/usr/share/icons/Adwaita/32x32/ui/checkbox-symbolic.symbolic.png
path=/usr/bin/foot
[core]
idle-time=0
seat=seat-...The normal mode works fine. Whin I add `client=` to the config, things get messy. Here is the conig
```ini
[launcher]
icon=/usr/share/icons/Adwaita/32x32/ui/checkbox-symbolic.symbolic.png
path=/usr/bin/foot
[core]
idle-time=0
seat=seat-0
[shell]
background-image=/home/vehementham/.local/share/wallpapers/wallpaper.JPG
client=/usr/bin/foot
```
Here is the output of `weston --shell=kiosk-shell.so`
```
Date: 2023-11-15 CST
[14:39:18.619] weston 11.0.1
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 11.0.1
[14:39:18.619] Command line: weston --shell=kiosk-shell.so
[14:39:18.619] OS: Linux, 6.1.60-gentoo-dist-hardened, #1 SMP PREEMPT_DYNAMIC Sun Nov 12 08:36:48 CST 2023, x86_64
[14:39:18.619] Flight recorder: enabled
[14:39:18.619] Using config file '/home/vehementham/.config/weston.ini'
[14:39:18.619] Output repaint window is 7 ms maximum.
[14:39:18.619] Loading module '/usr/lib64/libweston-11/x11-backend.so'
[14:39:18.627] Loading module '/usr/lib64/libweston-11/gl-renderer.so'
libEGL warning: DRI2: failed to authenticate
[14:39:18.649] warning: failed to query rendering device from EGL
[14:39:18.649] EGL version: 1.5
[14:39:18.649] EGL vendor: Mesa Project
[14:39:18.649] EGL client APIs: OpenGL OpenGL_ES
[14:39:18.649] warning: Disabling render GPU timeline and explicit synchronization due to missing EGL_ANDROID_native_fence_sync extension
[14:39:18.649] EGL features:
EGL Wayland extension: no
context priority: no
buffer age: no
partial update: no
swap buffers with damage: no
configless context: yes
surfaceless context: yes
dmabuf support: no
[14:39:18.658] GL version: OpenGL ES 3.2 Mesa 23.1.8
[14:39:18.659] GLSL version: OpenGL ES GLSL ES 3.20
[14:39:18.659] GL vendor: Mesa
[14:39:18.659] GL renderer: llvmpipe (LLVM 16.0.6, 256 bits)
[14:39:18.668] GL ES 3.2 - renderer features:
read-back format: ARGB8888
wl_shm 10 bpc formats: yes
wl_shm 16 bpc formats: yes
wl_shm half-float formats: yes
internal R and RG formats: yes
OES_EGL_image_external: yes
[14:39:18.668] Using gl renderer
[14:39:18.675] Registered plugin API 'weston_windowed_output_api_v1' of size 16
[14:39:18.675] Color manager: no-op
[14:39:18.675] Output 'screen0' attempts EOTF mode: SDR
[14:39:18.675] Output 'screen0' using color profile: built-in default sRGB SDR profile
[14:39:18.676] Chosen EGL config details: id: 11 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win|pix|pbf|swap_preserved vis_id: 0x21
[14:39:18.676] x11 output 1024x600, window id 27262981
[14:39:18.676] Output 'screen0' enabled with head(s) screen0
[14:39:18.676] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
cursor planes: no
arbitrary resolutions: no
view mask clipping: yes
explicit sync: no
color operations: yes
presentation clock: CLOCK_MONOTONIC_RAW, id 4
presentation clock resolution: 0.000000001 s
[14:39:18.677] libwayland: unable to lock lockfile /run/user/1000/wayland-1.lock, maybe another compositor is running
[14:39:18.677] Loading module '/usr/lib64/weston/kiosk-shell.so'
[14:39:18.730] Chosen EGL config details: id: 11 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win|pix|pbf|swap_preserved vis_id: 0x21
[14:39:20.267] Chosen EGL config details: id: 11 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win|pix|pbf|swap_preserved vis_id: 0x21
[14:39:21.906] Chosen EGL config details: id: 11 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win|pix|pbf|swap_preserved vis_id: 0x21
```
I compiled Weston on Gentoo
```
USE="X desktop drm fullscreen gles2 jpeg* kiosk pipewire resize-optimization seatd suid -editor -examples -headless -ivi -lcms -rdp -remoting -screen-sharing -systemd -test -wayland-compositor -webp -xwayland"
```https://gitlab.freedesktop.org/wayland/wayland/-/issues/422wl_connection_demarshal may legit not have enough fds2024-01-10T19:45:16ZJonathan Leiventwl_connection_demarshal may legit not have enough fdsThe `case 'h'` part of `wl_connection_demarshal` may see an empty `fds_in` buffer even when it legitimately needs an fd (_legitimately_ = not because some previous message wasn't demarshalled properly). This can happen because a single ...The `case 'h'` part of `wl_connection_demarshal` may see an empty `fds_in` buffer even when it legitimately needs an fd (_legitimately_ = not because some previous message wasn't demarshalled properly). This can happen because a single `wl_connection_read` will fetch a max of 28 (`MAX_FDS_OUT`) fds, but possibly more message content than what corresponds to those fds. As the max number of message args is 20 (`WL_CLOSURE_MAX_ARGS`) \< 28, the first message demarshalled after a `wl_connection_read` will always have enough fds, but latter ones may not. Perhaps there was an assumption that because `wl_connection_flush` flushes a max of 28 fds with only the message contents that correspond to them, that there would never be a need for more than 28 at the receiving end - but that assumption would only be the case if reads and flushes were sufficiently synchronized such that the kernel never buffers and delivers more than a single flush payload of data for the stream.
Suggest adding the following function to connection.c and calling it from the `case 'h'` part of `wl_connection_demarshal` in the obvious way:
```plaintext
int
wl_connection_pop_fd(struct wl_connection *connection)
{
uint32_t fd;
if (ring_buffer_size(&connection->fds_in) == 0) {
if (wl_connection_read(connection) < 0)
return -1;
if (ring_buffer_size(&connection->fds_in) == 0) {
errno = EINVAL;
return -1;
}
}
ring_buffer_copy(&connection->fds_in, &fd, sizeof fd);
connection->fds_in.tail += sizeof fd;
return fd;
}
```https://gitlab.freedesktop.org/wayland/weston/-/issues/840simple-dmabuf-egl: screen tearing2024-01-19T17:02:56ZAlbert Ladislasimple-dmabuf-egl: screen tearingWe're tried running simple-dmabuf-egl on our system (weston 8.0.0, 1024x600, 60Hz, Vivante GC400, etnaviv/mesa 21.2.5) and got tearing on the animated box (pls see attached video and wesgr plot). What could be causing this?
![simple-dma...We're tried running simple-dmabuf-egl on our system (weston 8.0.0, 1024x600, 60Hz, Vivante GC400, etnaviv/mesa 21.2.5) and got tearing on the animated box (pls see attached video and wesgr plot). What could be causing this?
![simple-dmabuf-egl-tearing](/uploads/222e8b63abb5f9d0586f98f452f81f5d/simple-dmabuf-egl-tearing.mp4)
![weston-simple-dmabuf-egl-3-explicit-sync-1024.svg](/uploads/85d37d7c5a6d759105446a497cc65d4c/weston-simple-dmabuf-egl-3-explicit-sync-1024.svg)
Thanks.https://gitlab.freedesktop.org/wayland/weston/-/issues/839Panfrost (rk3399) NV12 sampling broken2023-12-14T12:50:04ZRobert MaderPanfrost (rk3399) NV12 sampling brokenWhen using the [external image import](https://gitlab.freedesktop.org/wayland/weston/-/blob/f2f7560fac57af7f97916129ca053920bcaab195/libweston/renderer-gl/gl-renderer.c#L2869) path (instead of the [component/fallback one](https://gitlab....When using the [external image import](https://gitlab.freedesktop.org/wayland/weston/-/blob/f2f7560fac57af7f97916129ca053920bcaab195/libweston/renderer-gl/gl-renderer.c#L2869) path (instead of the [component/fallback one](https://gitlab.freedesktop.org/wayland/weston/-/blob/f2f7560fac57af7f97916129ca053920bcaab195/libweston/renderer-gl/gl-renderer.c#L2889)), colors are broken. While this is likely a Mesa bug, it's noteworthy that the same is not true for Sway, which (if I'm not mistaken) also only uses external images (instead of custom shaders, like the mentioned fallback path in Weston and Mutter).
A possible reason could be that the Panfrost shaders are not compatible with Westons - possibly only working with more recent GLSL version (`300` instead of `100`)? Needs more investigation.
Tested on a PineBook Pro (rk3399), Weston f2f7560f, Mesa 23.2, 23.3rc, main.
Reproducer (on all mentioned compositors):
```
gst-launch-1.0 filesrc location=~/Videos/BigBuckBunnyFullHD60fpsVP9.mp4 ! qtdemux ! vp9parse ! v4l2slvp9dec ! glupload ! gldownload ! "video/x-raw(memory:DMABuf)" ! waylandsink fullscreen=1
```
or alternatively, only on Weston,
```
gst-launch-1.0 filesrc location=~/Videos/BigBuckBunnyFullHD60fpsVP9.mp4 ! qtdemux ! vp9parse ! v4l2slvp9dec ! waylandsink fullscreen=1
```
Weston:
![Screenshot_from_2023-11-09_13-14-40](/uploads/3818d7ab262631266e1a53b4edc88cc3/Screenshot_from_2023-11-09_13-14-40.png)
Weston (fallback):
![Screenshot_from_2023-11-09_13-06-24](/uploads/1e92e3530ce38222f1d790711298f1e5/Screenshot_from_2023-11-09_13-06-24.png)
Sway:
![Screenshot_from_2023-11-09_13-05-13](/uploads/e418256b02c2ff46adf48fcbbca76a5a/Screenshot_from_2023-11-09_13-05-13.png)
Mutter:
![Screenshot_from_2023-11-09_13-04-44](/uploads/6a5ac46b6f68dd50488f026910c1d262/Screenshot_from_2023-11-09_13-04-44.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/421Touch gestures disallow 10-finger touch scenarios2023-11-10T12:08:17ZSamuel AllenTouch gestures disallow 10-finger touch scenariosHi there. I don't think this is a bug, but a design decision that makes it impossible to use Wayland with--in my case--audio production software like Bitwig Studio with a touch screen. When attempting to control multiple mixer faders a...Hi there. I don't think this is a bug, but a design decision that makes it impossible to use Wayland with--in my case--audio production software like Bitwig Studio with a touch screen. When attempting to control multiple mixer faders at once, as soon as more than two touches are detected, the three-finger gesture activates and cancels the first two touches.
Using X11, I can use all 10 fingers simultaneously to control elements in Bitwig. Wayland has come a really long way, and using it in Ubuntu 23.10 makes me really want to try to find a solution to this problem so I don't have to revert back.
I am unable to find any documentation around how to disable gesture recognition, so I presume it's not a supported feature at this time.
If it could be implemented, I would be grateful.
Samhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/420How to bind a wanylandsink in gstreamer with wayland Windows in FLTK?2023-11-07T03:38:05Zchad-caoHow to bind a wanylandsink in gstreamer with wayland Windows in FLTK?Dear all,
Now I am trying to use FLTK1.4 to develop a video player with GStreamer.
I can play the mp4 with the waylandsink in gstreamer, and I also could create a FLTK1.4 wayland window.
I know I should use gst_video_overlay_set_window_h...Dear all,
Now I am trying to use FLTK1.4 to develop a video player with GStreamer.
I can play the mp4 with the waylandsink in gstreamer, and I also could create a FLTK1.4 wayland window.
I know I should use gst_video_overlay_set_window_handle(GstVideoOverlay * overlay, guintptr handle) to combine the waylandsink with the window, but it is failed.
I am not sure which parameters should I use for handle, wl_surface or something?
Thanks
Chadhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/419black window contagion2023-11-05T22:04:54ZTom Turkeyblack window contagionI have been experiencing issues with tcl/tk (in particular in tkcon, especially when it trys to put up a window that expands an error) which I am relatively certain are from some sort of 'wayland' issue and or incompatibility, i.e. they ...I have been experiencing issues with tcl/tk (in particular in tkcon, especially when it trys to put up a window that expands an error) which I am relatively certain are from some sort of 'wayland' issue and or incompatibility, i.e. they all went away when I went back to X11. Prime symptoms were very slow response to the raising the tkcon console window, completely black screen for the tkcon window with occasional fill in when moving the mouse over the window, some times this spreads to all the tkcon windows and even to emacs. Once this happens even the simple 'wish' command puts up a black window (normal window background is gray85). I am not sure this is related but wayland (as opposed to X11) seems to flash a lot of jittery windows when moving the mouse over the task bar.
Running Fedora 38, with KDE (which allows X11 or wayland at login).
Emacs 28.3
tcl/tk 8.6.12https://gitlab.freedesktop.org/wayland/weston/-/issues/838Launching application in Weston Kiosk from systemd service2023-12-06T10:55:58ZJean-Francois BETTELaunching application in Weston Kiosk from systemd serviceHi,
I am trying to launch an application in a Weston Kiosk using a Linux service (systemd or whatever).
The purpose is to control the application from outside Weston (for example start and stop the application).
Without the kiosk mode...Hi,
I am trying to launch an application in a Weston Kiosk using a Linux service (systemd or whatever).
The purpose is to control the application from outside Weston (for example start and stop the application).
Without the kiosk mode, i launch the application using WAYLAND_DISPLAY env variable using a dedicated socket for my Weston instance => The application shows in Weston well.
command example: `WAYLAND_DISPLAY=/some/path/wayland-1 /some/command`
With the kiosk mode enable, the application is started but not showing inside the Weston screen.
Here is how I launch weston : `weston --socket=/some/path/wayland-1 --shell=kiosk-shell.so`
What am i doing wrong?
The weston version is 11.0.1.https://gitlab.freedesktop.org/wayland/weston/-/issues/837xdg_popup.grab in combination with wl_data_device.start_drag can lead to visu...2023-11-01T16:52:02ZKirill Primakvyivel@eclair.cafexdg_popup.grab in combination with wl_data_device.start_drag can lead to visual artifacts(tested with 47d58f7f129649f45ff20efc12d060fe268af47f)
---
Tested with https://gitlab.freedesktop.org/vyivel/randfall/-/blob/main/cases/xdg_popup_interactive_grab_with_dnd.c
Sending `wl_data_device.start_drag` followed by `xdg_popup.g...(tested with 47d58f7f129649f45ff20efc12d060fe268af47f)
---
Tested with https://gitlab.freedesktop.org/vyivel/randfall/-/blob/main/cases/xdg_popup_interactive_grab_with_dnd.c
Sending `wl_data_device.start_drag` followed by `xdg_popup.grab` (done by pressing the middle mouse button on the toplevel surface) results in opening a grabbing `xdg_popup` and starting a DnD operation; however, the drag icon doesn't follow the cursor and stays on the screen until the client is closed:
![image](/uploads/3f0a3080e2713d93399c3a2f550ce33b/image.png)https://gitlab.freedesktop.org/wayland/weston/-/issues/836If an xdg_popup isn't destroyed in response to xdg_popup.popup_done, switchin...2024-02-20T14:28:37ZKirill Primakvyivel@eclair.cafeIf an xdg_popup isn't destroyed in response to xdg_popup.popup_done, switching focus leads to NULL dereference(tested with 47d58f7f129649f45ff20efc12d060fe268af47f)
---
Tested with https://gitlab.freedesktop.org/vyivel/randfall/-/blob/main/cases/xdg_popup_interactive_ignore_popup_done.c
1) Open an popup by clicking on the toplevel surface
2) ...(tested with 47d58f7f129649f45ff20efc12d060fe268af47f)
---
Tested with https://gitlab.freedesktop.org/vyivel/randfall/-/blob/main/cases/xdg_popup_interactive_ignore_popup_done.c
1) Open an popup by clicking on the toplevel surface
2) Dismiss the popup by clicking anywhere else
3) Try to switch focus by clicking on another window or opening a new one
```
../desktop-shell/shell.c:1565:12: runtime error: member access within null pointer of type 'struct shell_surface'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==55003==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000178 (pc 0x7fbe6dee4034 bp 0x7ffe5c9fe300 sp 0x7ffe5c9fe280 T0)
==55003==The signal is caused by a READ memory access.
==55003==Hint: address points to the zero page.
#0 0x7fbe6dee4034 in has_keyboard_focused_child_callback ../desktop-shell/shell.c:1565
#1 0x7fbe8414c16e in weston_desktop_surface_foreach_child ../libweston/desktop/surface.c:896
#2 0x7fbe6dee4342 in has_keyboard_focused_child ../desktop-shell/shell.c:1583
#3 0x7fbe6dee44b6 in sync_surface_activated_state ../desktop-shell/shell.c:1604
#4 0x7fbe6dee4803 in shell_surface_deactivate ../desktop-shell/shell.c:1634
#5 0x7fbe6defb198 in activate ../desktop-shell/shell.c:3637
#6 0x7fbe6deec6a7 in map ../desktop-shell/shell.c:2277
#7 0x7fbe6deed129 in desktop_surface_committed ../desktop-shell/shell.c:2331
#8 0x7fbe8413ab84 in weston_desktop_api_committed ../libweston/desktop/libweston-desktop.c:159
#9 0x7fbe84156fb8 in weston_desktop_xdg_toplevel_committed ../libweston/desktop/xdg-shell.c:793
#10 0x7fbe8415cfb4 in weston_desktop_xdg_surface_committed ../libweston/desktop/xdg-shell.c:1505
#11 0x7fbe84144471 in weston_desktop_surface_surface_committed ../libweston/desktop/surface.c:193
#12 0x7fbe8403f7ca in wl_signal_emit /usr/include/wayland-server-core.h:496
#13 0x7fbe8407cbd9 in weston_surface_commit_state ../libweston/compositor.c:4536
#14 0x7fbe8407ce75 in weston_surface_commit ../libweston/compositor.c:4551
#15 0x7fbe8407dc1b in surface_commit ../libweston/compositor.c:4636
#16 0x7fbe84505be5 in ffi_call_unix64 (/lib64/libffi.so.8+0x7be5) (BuildId: f5312719df7de0c6ae9d42ed18680d8016bb59d4)
#17 0x7fbe845024be in ffi_call_int.lto_priv.0 (/lib64/libffi.so.8+0x44be) (BuildId: f5312719df7de0c6ae9d42ed18680d8016bb59d4)
#18 0x7fbe8450518d in ffi_call (/lib64/libffi.so.8+0x718d) (BuildId: f5312719df7de0c6ae9d42ed18680d8016bb59d4)
#19 0x7fbe848fe842 in wl_closure_invoke.constprop.0 (/lib64/libwayland-server.so.0+0x9842) (BuildId: 5ba1da00efc72d602197f31c66d7d6516a9a62a3)
#20 0x7fbe849030b3 in wl_client_connection_data (/lib64/libwayland-server.so.0+0xe0b3) (BuildId: 5ba1da00efc72d602197f31c66d7d6516a9a62a3)
#21 0x7fbe849018e1 in wl_event_loop_dispatch (/lib64/libwayland-server.so.0+0xc8e1) (BuildId: 5ba1da00efc72d602197f31c66d7d6516a9a62a3)
#22 0x7fbe84902124 in wl_display_run (/lib64/libwayland-server.so.0+0xd124) (BuildId: 5ba1da00efc72d602197f31c66d7d6516a9a62a3)
#23 0x7fbe8531d468 in wet_main ../compositor/main.c:4369
#24 0x40116a in main ../compositor/executable.c:33
#25 0x7fbe84a49b89 in __libc_start_call_main (/lib64/libc.so.6+0x27b89) (BuildId: 7026fe8c129a523e07856d7c96306663ceab6e24)
#26 0x7fbe84a49c4a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c4a) (BuildId: 7026fe8c129a523e07856d7c96306663ceab6e24)
#27 0x401084 in _start (/home/kira/opt/gfx/weston/build/compositor/weston+0x401084) (BuildId: d26bc6c92ffae07235b0fdfd3751e19b87681589)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../desktop-shell/shell.c:1565 in has_keyboard_focused_child_callback
==55003==ABORTING
```https://gitlab.freedesktop.org/wayland/weston/-/issues/835Improve logging of required GL driver features, particularly missing ones2023-11-02T09:49:04ZMichael KarleskyImprove logging of required GL driver features, particularly missing onesEdit: old title was _“error: color operations capability missing. Is GL-renderer not in use?” when GL-renderer is in use._
I realize that color management is experimental. Nevertheless, I'm interested to try it out and am hitting a perp...Edit: old title was _“error: color operations capability missing. Is GL-renderer not in use?” when GL-renderer is in use._
I realize that color management is experimental. Nevertheless, I'm interested to try it out and am hitting a perplexing error.
When color-management is enable in Weston 12.0.92, it errors out on startup and seems to indicate that GL-renderer may not be in use. In fact, GL-renderer is in use. Weston configuration file and log below. What might be causing this failure? How can I troubleshoot and correct the problem?
_weston.ini_
```plaintext
[core]
idle_time=0
renderer=gl
color-management=true
backend=drm
[output]
eotf-mode=st2084
icc_profile=test-icc-profile.icm
```
<details><summary>_weston.log_</summary>
```plaintext
weston 12.0.92
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 12.0.92+
Command line: weston -c /home/osmc/weston.ini --log=weston.log
OS: Linux, 5.15.92-1-osmc, #1 SMP PREEMPT Tue Jul 25 00:03:42 UTC 2023, aarch64
Flight recorder: enabled
Using config file '/home/osmc/weston.ini'
Output repaint window is 7 ms maximum.
Loading module '/usr/lib/libweston-13/color-lcms.so'
Loading module '/usr/lib/libweston-13/drm-backend.so'
initializing drm backend
Trying libseat launcher...
[libseat/libseat.c:73] Seat opened with backend 'seatd'
[libseat/backend/seatd.c:212] Enabling seat
libseat: session control granted
using /dev/dri/card1
DRM: supports atomic modesetting
DRM: supports GBM modifiers
DRM: does not support async page flipping
DRM: supports picture aspect ratio
Loading module '/usr/lib/libweston-13/gl-renderer.so'
Using rendering device: /dev/dri/card1
EGL version: 1.4
EGL vendor: Mesa Project
EGL client APIs: OpenGL OpenGL_ES
warning: Disabling render GPU timeline and explicit synchronization due to missing EGL_ANDROID_native_fence_sync extension
EGL features:
EGL Wayland extension: yes
context priority: no
buffer age: yes
partial update: no
swap buffers with damage: no
configless context: yes
surfaceless context: yes
dmabuf support: modifiers
GL version: OpenGL ES 3.1 Mesa 23.2.1
GLSL version: OpenGL ES GLSL ES 3.10
GL vendor: Broadcom
GL renderer: V3D 4.2
GL ES 3.1 - renderer features:
read-back format: ARGB8888
glReadPixels supports y-flip: yes
wl_shm 10 bpc formats: yes
wl_shm 16 bpc formats: no
wl_shm half-float formats: no
internal R and RG formats: yes
OES_EGL_image_external: yes
Using GL renderer
event0 - Logitech Wireless Keyboard PID:4023: is tagged by udev as: Keyboard
event0 - Logitech Wireless Keyboard PID:4023: device is a keyboard
event1 - Logitech Wireless Mouse: is tagged by udev as: Mouse
event1 - Logitech Wireless Mouse: device is a pointer
libinput: configuring device "Logitech Wireless Keyboard PID:4023".
EGL client APIs: OpenGL OpenGL_ES
warning: Disabling render GPU timeline and explicit synchronization due to missing EGL_ANDROID_native_fence_sync extension
EGL features:
EGL Wayland extension: yes
context priority: no
buffer age: yes
partial update: no
swap buffers with damage: no
configless context: yes
surfaceless context: yes
dmabuf support: modifiers
GL version: OpenGL ES 3.1 Mesa 23.2.1
GLSL version: OpenGL ES GLSL ES 3.10
GL vendor: Broadcom
GL renderer: V3D 4.2
GL ES 3.1 - renderer features:
read-back format: ARGB8888
glReadPixels supports y-flip: yes
wl_shm 10 bpc formats: yes
wl_shm 16 bpc formats: no
wl_shm half-float formats: no
internal R and RG formats: yes
OES_EGL_image_external: yes
Using GL renderer
event0 - Logitech Wireless Keyboard PID:4023: is tagged by udev as: Keyboard
event0 - Logitech Wireless Keyboard PID:4023: device is a keyboard
event1 - Logitech Wireless Mouse: is tagged by udev as: Mouse
event1 - Logitech Wireless Mouse: device is a pointer
libinput: configuring device "Logitech Wireless Keyboard PID:4023".
libinput: configuring device "Logitech Wireless Mouse".
DRM: EDID for the following head fails conformity:
Block 1, CTA-861 Extension Block:
Video Capability Data Block: IT video formats are always underscanned, but bit 7 of Byte 3 of the CTA-861 Extension header is set to overscanned.
DRM: head 'HDMI-A-1' found, connector 32 is connected, EDID make 'LG Electronics', model 'LG HDR 4K', serial 'XXXXXXXXXXXX'
Supported EOTF modes: SDR, traditional gamma HDR, ST2084, HLG
DRM: head 'HDMI-A-2' found, connector 42 is disconnected.
Registered plugin API 'weston_drm_output_api_v1' of size 20
color-lcms: error: color operations capability missing. Is GL-renderer not in use?
event0 - Logitech Wireless Keyboard PID:4023: device removed
event1 - Logitech Wireless Mouse: device removed
```
</details>https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/165xdg_activation: token reuse is not clear2023-10-30T15:58:11ZKirill Chibisovxdg_activation: token reuse is not clear`xdg_activation_v1::get_token` says the following
>Creates an xdg_activation_token_v1 object that will provide the initiating client with a unique token for this activation. This token should be offered to the clients to be activated.
...`xdg_activation_v1::get_token` says the following
>Creates an xdg_activation_token_v1 object that will provide the initiating client with a unique token for this activation. This token should be offered to the clients to be activated.
Where the key point is that _token passed to client**s .**_
However in reality it seems like that implementations mark the token as _no longer valide_ once the `xdg_activation_v1::activate` is called.
Should the `activate` just say that the token will be considered `invalid`, so the clients instead of creating 1 token and passing to 2 clients, will just create 2 tokens for each client being activated?https://gitlab.freedesktop.org/wayland/wayland/-/issues/418xdg_activation: token reuse is not clear2023-10-30T15:57:40ZKirill Chibisovxdg_activation: token reuse is not clear`xdg_activation_v1::get_token` says the following
\\>Creates an xdg_activation_token_v1 object that will provide the initiating client with a unique token for this activation. This token should be offered to the clients to be activated....`xdg_activation_v1::get_token` says the following
\\>Creates an xdg_activation_token_v1 object that will provide the initiating client with a unique token for this activation. This token should be offered to the clients to be activated.
Where the key point is that _token passed to client**s .**_
However in reality it seems like that implementations mark the token as _no longer valide_ once the `xdg_activation_v1::activate` is called.
Should the `activate` just say that the token will be considered `invalid`, so the clients instead of creating 1 token and passing to 2 clients, will just create 2 tokens for each client being activated?