weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2022-09-14T13:45:41Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/644weston segfault wslg2022-09-14T13:45:41ZAhmed ABOUZIDweston segfault wslghello,
I have an issue on weston that I reported on wslg github please could someone help resolve it?
https://github.com/microsoft/wslg/issues/802
Thanks a lothello,
I have an issue on weston that I reported on wslg github please could someone help resolve it?
https://github.com/microsoft/wslg/issues/802
Thanks a lothttps://gitlab.freedesktop.org/wayland/weston/-/issues/638Pattern weston_head_from_resource(output_resource)->output is not safe2024-02-06T10:29:12ZPekka Paalanenppaalanen@gmail.comPattern weston_head_from_resource(output_resource)->output is not safeThere are many instances of `weston_head_from_resource(output_resource)->output` in the code base, literally. This construct is not safe, because the `weston_head` can be `NULL`.
If a client is sending a request with a `wl_output` argum...There are many instances of `weston_head_from_resource(output_resource)->output` in the code base, literally. This construct is not safe, because the `weston_head` can be `NULL`.
If a client is sending a request with a `wl_output` argument at the same time as the compositor is disabling the corresponding `weston_output`, the user data of `wl_resource` for the `wl_output`s is set to `NULL`.
These would need to be fixed. Found by code inspection.https://gitlab.freedesktop.org/wayland/weston/-/issues/637[regression] NV12 dmabuf renders all red2023-10-26T13:11:53ZLink Mauve[regression] NV12 dmabuf renders all redOriginally found using the new vaapi-wayland video output from mpv: https://github.com/mpv-player/mpv/issues/10341
I bisected this issue to f36d77a199a6398444f7ae6d1002dad2f65ca679.
Reverting this commit or changing line 2573 to `SHADE...Originally found using the new vaapi-wayland video output from mpv: https://github.com/mpv-player/mpv/issues/10341
I bisected this issue to f36d77a199a6398444f7ae6d1002dad2f65ca679.
Reverting this commit or changing line 2573 to `SHADER_VARIANT_EXTERNAL` fixes this issue.
I’m not sure whether this is a bug in Weston or in Mesa/iris, which is the GL stack I’m using.
I’m also surprised Weston doesn’t try to put this buffer in a plane, as my hardware (gen9) supports everything needed here I think.
![](https://user-images.githubusercontent.com/7755816/175996910-d97ca72a-13e7-474e-91af-73ec4347dcbd.png)https://gitlab.freedesktop.org/wayland/weston/-/issues/636Xwayland client pop-ups don't receive input appropriately2022-07-28T20:53:20ZDerek ForemanXwayland client pop-ups don't receive input appropriatelyApparently since commit b18f788e2e7476840eac54b0e7ac30a0244e4528 some programs don't properly receive input on their menus.
This is known to affect the steam client, as well as old motif programs such as nedit.
The problem appears to b...Apparently since commit b18f788e2e7476840eac54b0e7ac30a0244e4528 some programs don't properly receive input on their menus.
This is known to affect the steam client, as well as old motif programs such as nedit.
The problem appears to be that a client attempts to focus one of its own windows, but the compositor undoes this and the input goes to the wrong place.https://gitlab.freedesktop.org/wayland/weston/-/issues/63510.0.1: build fails2022-08-10T09:44:24ZTomasz Kłoczko10.0.1: build failsLooks like sometning is wrong with missing symbol on linking test progtraam.
```
[tkloczko@devel-g2v x86_64-redhat-linux-gnu]$ ninja
[2/2] Linking target tests/test-ivi-layout.so
FAILED: tests/test-ivi-layout.so
/usr/bin/gcc -o tests/te...Looks like sometning is wrong with missing symbol on linking test progtraam.
```
[tkloczko@devel-g2v x86_64-redhat-linux-gnu]$ ninja
[2/2] Linking target tests/test-ivi-layout.so
FAILED: tests/test-ivi-layout.so
/usr/bin/gcc -o tests/test-ivi-layout.so tests/test-ivi-layout.so.p/meson-generated_.._.._protocol_weston-test-protocol.c.o tests/test-ivi-layout.so.p/ivi-layout-test-plugin.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,test-ivi-layout.so -Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--build-id=sha1 -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none '-Wl,-rpath,$ORIGIN/../libweston:$ORIGIN/../compositor' -Wl,-rpath-link,/home/tkloczko/rpmbuild/BUILD/weston-10.0.1/x86_64-redhat-linux-gnu/libweston -Wl,-rpath-link,/home/tkloczko/rpmbuild/BUILD/weston-10.0.1/x86_64-redhat-linux-gnu/compositor libweston/libweston-10.so.0.0.1 compositor/libexec_weston.so.0.0.0 /usr/lib64/libwayland-server.so /usr/lib64/libpixman-1.so /usr/lib64/libxkbcommon.so -Wl,--end-group
/usr/bin/ld: /tmp/cciadncK.lto.o: in function `runner_run_handler':
/home/tkloczko/rpmbuild/BUILD/weston-10.0.1/x86_64-redhat-linux-gnu/../tests/ivi-layout-test-plugin.c:72: undefined reference to `__start_plugin_test_section'
/usr/bin/ld: /tmp/cciadncK.lto.o:/home/tkloczko/rpmbuild/BUILD/weston-10.0.1/x86_64-redhat-linux-gnu/../tests/ivi-layout-test-plugin.c:72: undefined reference to `__stop_plugin_test_section'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
```
```console
[tkloczko@devel-g2v SPECS]$ rpm -qf /usr/lib64/libwayland-server.so /usr/lib64/libpixman-1.so /usr/lib64/libxkbcommon.so
wayland-devel-1.20.0-5.fc35.x86_64
pixman-devel-0.40.0-6.fc35.x86_64
libxkbcommon-devel-1.4.1-2.fc35.x86_64
```https://gitlab.freedesktop.org/wayland/weston/-/issues/631Policy: not recovering from memory allocation failures2022-08-28T14:19:16ZPekka Paalanenppaalanen@gmail.comPolicy: not recovering from memory allocation failures# In libweston, should every `malloc()` and similar call be checked and some recovery path exist if it fails, or should we just `abort()` if any memory allocation fails?
This is a question me and @daniels have been debating perhaps ever...# In libweston, should every `malloc()` and similar call be checked and some recovery path exist if it fails, or should we just `abort()` if any memory allocation fails?
This is a question me and @daniels have been debating perhaps every year. I have been thinking it's better to try to handle such failures, while Daniel sees the basically untestable failure paths as a burden of developing and carrying code that is likely broken.
My opinion has started to shift. Here's a summary of the two sides, mostly to convince myself that recovering from allocation failures is futile in the context of libweston.
## Disadvantages of trying to recover from memory allocation failures
- Trying to recover from every allocation failure everywhere creates a huge number of code paths that cannot realistically ever be tested. Hence we cannot be sure they work, or what the effect will actually be.
- These failure paths clutter the code and add a lot of divergent code paths.
- Some compositor steady-state operations routinely do allocations, like allocating internal state structures for a simple screen update, or even log messages. If these allocations fail, then even in the best case the compositor appears to freeze with no explanation in the logs.
- Wayland client request processing often allocates. If that fails, Weston could disconnect the client and continue. This probably does not fix the out-of-memory situation, so Weston ends up disconnecting client after client until almost none is left. In that case, what is the point of keeping Weston limping along? The client state is lost anyway. Also the client chosen to be disconnected is arbitrary and likely not the client that caused Weston to allocate lots of memory.
- Memory overcommit in the kernel, which is usually on, makes allocation failures never happen. The process just segfaults when a paging request suddenly cannot be serviced. So why bother.
## Advantages of recovering from memory allocation failures
- Weston can keep on running as much as it can even if bad things happen in the system. When memory becomes available again, Weston automatically resumes normal operation.
- `malloc()` can fail even if the system as a whole uses overcommit: Weston might be running in a container or cgroup with deliberately limited resources.
- Being able to operate "reliably" in memory constrained environments might be a relatively unique selling point for Weston among compositors or compositor libraries.
- Weston allocates memory on behalf of Wayland clients. A broken or malicious client can make Weston allocate practically unlimited amounts of memory. If memory allocation can be traced back to a client, disconnecting the client on allocation failure might help, with luck. (Of course, this doesn't actually work without tracking allocations per client and targeting the client causing too much allocations, preferably already before any allocation actually fails.)
- The recovery code paths may not be reliable now, but if someone wanted to really make libweston "safe" against allocation failures, having the existing recovery paths would lessen the amount of work needed.
To me, the advantages are starting to feel pretty weak, more like excuses for sticking to the habit.
## Giving up on recovering from allocation failures
We can start using the `x*alloc()` helpers everywhere. These functions either return memory, or abort the process. This means that we will be able to garbage-collect a huge number of failure paths that simply cannot happen anymore. Many functions no longer need failure return codes. This will also improve our code branch test coverage percentage.
It becomes much easier to reason about libweston behavior. Failures happen for more interesting reasons than simple out-of-memory.
There will likely still be cases where it is justified to recover from memory allocation failure, especially when allocating special memory like device memory (graphics, KMS dumb buffers). Also if a single protocol request could allocate a massive chunk of memory, that's probably best checked still - we know which client to blame.
----
If you don't want libweston to give up on pretending it might recover from allocation failures, please comment here and explain why.
Otherwise, I propose to record this design decision in libweston documentation, which means changes to how merge requests are reviewed, and gives the green light for the gradual migration to abort-on-failure memory allocation routines.https://gitlab.freedesktop.org/wayland/weston/-/issues/630Xdg-shell surface doesn't become keyboard active in ivi-shell.2022-09-29T07:51:20ZTomohito EsakiXdg-shell surface doesn't become keyboard active in ivi-shell.In ivi-shell, keyboard is not active for surfaces created with xdg-shell.
I confirmed with hmi-controller and [wayland-ivi-extension](https://github.com/COVESA/wayland-ivi-extension).
I seems that this is because whether the surface was...In ivi-shell, keyboard is not active for surfaces created with xdg-shell.
I confirmed with hmi-controller and [wayland-ivi-extension](https://github.com/COVESA/wayland-ivi-extension).
I seems that this is because whether the surface was created with the ivi-application protocol is checked in activate_binding().
```C
static struct ivi_shell_surface *
get_ivi_shell_surface(struct weston_surface *surface)
{
struct ivi_shell_surface *shsurf;
if (surface->committed != ivi_shell_surface_committed) //<-- here
return NULL;
shsurf = surface->committed_private;
assert(shsurf);
assert(shsurf->surface == surface);
return shsurf;
}
...
static void
activate_binding(struct weston_seat *seat,
struct weston_view *focus_view)
{
struct weston_surface *focus = focus_view->surface;
struct weston_surface *main_surface =
weston_surface_get_main_surface(focus);
if (get_ivi_shell_surface(main_surface) == NULL) //<-- here
return;
weston_seat_set_keyboard_focus(seat, focus);
}
```
Is there a reason for this?https://gitlab.freedesktop.org/wayland/weston/-/issues/626Screen capturing2023-06-26T11:22:25ZpiegamesScreen capturingHello, is there any good way to do some screen shots or capturing the entire output of Weston programatically? I've seen that there is `weston-screenshooter`, but it feels more like a tech demo to me and also I don't think it can take vi...Hello, is there any good way to do some screen shots or capturing the entire output of Weston programatically? I've seen that there is `weston-screenshooter`, but it feels more like a tech demo to me and also I don't think it can take video recordings.
What is the easiest way to capture the output of Weston? FWIW, I am fine with controlling my own Weston session for this purpose (I plan on running a headless nested session in the end).https://gitlab.freedesktop.org/wayland/weston/-/issues/625Display / surface freeze2022-07-05T04:57:21ZSören Meiersoerenmeier@livgood.chDisplay / surface freezeSo this is a really weird bug.
## 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....So this is a really weird bug.
## 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.
## Problem
So on most devices / hardware I tested everything works great, the display turns on and off chromium is always responding.
But there is one device
CPU: Intel 4205U
Display: ELO ET2796L (with touch)
[weston_startup.txt](/uploads/2e936b1104ca10d1f0e3bb0c48d1d710/weston_startup.txt)
Which sometimes just freezes, turning the display on and off still works (dpms). But the view/chromium does not get updated so if i press somewhere or use the mouse nothing happens. After debugging a bit I found out that chromium still receives the inputs and processes them correctly on my website (click events are fired). So it seems chromium or my website are still working correctly.
After adding WAYLAND_DEBUG=1 when everything works great i see after clicking, `wl_surface@25.commit()` and alot more see `working.txt`.
But after the freeze occurres only the following lines get outputed:
```
May 31 03:12:13 iron-os weston[201]: [1987568.506] -> wl_touch@3.motion(605792, 0, 225.000000, 590.359375)
May 31 03:12:13 iron-os weston[201]: [1987568.573] -> wl_touch@3.frame()
May 31 03:12:13 iron-os weston[201]: [1987578.532] -> wl_touch@3.motion(605802, 0, 229.218750, 578.496094)
May 31 03:12:13 iron-os weston[201]: [1987578.604] -> wl_touch@3.frame()
May 31 03:12:13 iron-os weston[201]: [1987588.535] -> wl_touch@3.motion(605812, 0, 230.625000, 574.277344)
May 31 03:12:13 iron-os weston[201]: [1987588.609] -> wl_touch@3.frame()
May 31 03:12:13 iron-os weston[201]: [1987598.458] -> wl_touch@3.motion(605822, 0, 233.437500, 567.687500)
May 31 03:12:13 iron-os weston[201]: [1987598.539] -> wl_touch@3.frame()
```
[working.txt](/uploads/af97f7d63515aa5257628991729c9513/working.txt) [failure.txt](/uploads/0870e1dc95e4ed331427a824209a2e86/failure.txt)
What makes this hard for me to reproduce consistently is, that it doesnt always happen, there might be no problem one day but suddenly it doesn't work, after a restart of chromium or weston everything works again.
I'm not sure this is important but the display/monitor is quit slow on startup, so if the dpms signal gets sent the display takes around 5s until something is showed. But that is hardware dependent.
I tried to debug it a bit but I'm not sure where to look for or even if it is weston's fault maybe its a chromium bug. Please let me know what i can do or look for, maybe you already have an idea what the problem could be.
Thanks a lot.
### Edit
So i just ran weston-debug timeline and was lucky enough that the error occured again.
Here it seems that repaints still happen: [timeline.txt](/uploads/357153246f05179e755a571f1d1ca57b/timeline.txt)https://gitlab.freedesktop.org/wayland/weston/-/issues/624weird resize behavior2022-06-02T15:06:38ZMike Blumenkrantzweird resize behaviorI'll preface by saying I don't know whether this is an app bug or a compositor bug, but definitely on one side there is a bug.
* run weston
* run [kitty](https://sw.kovidgoyal.net/kitty/)
* resize kitty
During resize, the window gets d...I'll preface by saying I don't know whether this is an app bug or a compositor bug, but definitely on one side there is a bug.
* run weston
* run [kitty](https://sw.kovidgoyal.net/kitty/)
* resize kitty
During resize, the window gets drawn as a black rect because it hits the fallback texture path in mesa due to being an incomplete texture. Essentially there is no dmabuf attached when the resized repaint happens.
This can be seen in action with breakpoints on `set_tex_image()` and `_mesa_get_fallback_texture()` in mesa.https://gitlab.freedesktop.org/wayland/weston/-/issues/623Weston 10.0 New Shader leads to performance drop2022-06-07T07:16:25ZMORDRET Pierre-Yvespierre-yves.mordret@foss.st.comWeston 10.0 New Shader leads to performance dropHi all,
Already discussed with Pekka Paalanen it turns out new Shader management has ended up in performance drop in out side (STM32MP1 MPU from STMicroelectronics)
The pre_mult code added, pre_curve and color mapping changes leads to e...Hi all,
Already discussed with Pekka Paalanen it turns out new Shader management has ended up in performance drop in out side (STM32MP1 MPU from STMicroelectronics)
The pre_mult code added, pre_curve and color mapping changes leads to extra GPU cycles that can't be optimized by the compiler: RCP, MUL and worse JMP
The reason pre-multiplied alpha is first undone is that otherwise it is not possible to apply anything non-identity in color_pipeline(). view-alpha is not needing that, color_pre_curve() and color_mapping() are.
For identity pipeline, the pre-mult is not required at all.
I believe some additional "if" prior to run color_pipeline is likely needed here to prevent extra GPU cycles (even more un-wanted)
Thanks in advance
Regardshttps://gitlab.freedesktop.org/wayland/weston/-/issues/622Overlay Planes not working2022-06-14T22:24:13Zbhawanpreet lakhaOverlay Planes not workingAccording to @pq Overlay should work by using weston-simple-egl -o or weston-simple-dmabuf-egl. But that doesn't seem to be happening.
I am using Build: 10.0.90
7412a014 backend-drm: Retrieve reason if dmabuf import failed
I also tried...According to @pq Overlay should work by using weston-simple-egl -o or weston-simple-dmabuf-egl. But that doesn't seem to be happening.
I am using Build: 10.0.90
7412a014 backend-drm: Retrieve reason if dmabuf import failed
I also tried Build: 10.0.0, but I see "[plane] not adding plane 60 to candidate list: invalid pixel format" for the simple-egl plane
[weston-log_10.0.0.txt](/uploads/465419c24878eff9976046635de72a8e/weston-log_10.0.0.txt)
[weston-log_10.0.90.txt](/uploads/2179fdb4dd27369968255edf775571f9/weston-log_10.0.90.txt)https://gitlab.freedesktop.org/wayland/weston/-/issues/621Crash in draw_paint_node2022-06-16T09:45:30ZAlexandros FrantzisCrash in draw_paint_nodeHow to reproduce:
1. Start latest Weston (2df71c6dd) under X11 (may work with other backends, but I haven't tested)
2. Start pavucontrol (ensuring it runs natively in the just started Weston instance).
3. Go to the "Input devices" tab.
...How to reproduce:
1. Start latest Weston (2df71c6dd) under X11 (may work with other backends, but I haven't tested)
2. Start pavucontrol (ensuring it runs natively in the just started Weston instance).
3. Go to the "Input devices" tab.
4. Click on the "Port" drop down menu of the device (only one device in my case)
5. Crash (it may take a few clicks at step 4)
The gdb log is:
```
Thread 1 "weston" received signal SIGSEGV, Segmentation fault.
0x00007ffff72aa718 in draw_paint_node (pnode=0x555555c35610, damage=0x7fffffffcf50) at ../libweston/renderer-gl/gl-renderer.c:1017
1017 if (gb->shader_variant == SHADER_VARIANT_NONE &&
(gdb) bt
#0 0x00007ffff72aa718 in draw_paint_node (pnode=0x555555c35610, damage=0x7fffffffcf50) at ../libweston/renderer-gl/gl-renderer.c:1017
#1 0x00007ffff72aabf1 in repaint_views (output=0x555555c14f60, damage=0x7fffffffcf50) at ../libweston/renderer-gl/gl-renderer.c:1108
#2 0x00007ffff72ac6b8 in gl_renderer_repaint_output (output=0x555555c14f60, output_damage=0x7fffffffd020) at ../libweston/renderer-gl/gl-renderer.c:1702
#3 0x00007ffff7f9c73a in x11_output_repaint_gl (output_base=0x555555c14f60, damage=0x7fffffffd020) at ../libweston/backend-x11/x11.c:425
#4 0x00007ffff7d58e51 in weston_output_repaint (output=0x555555c14f60) at ../libweston/compositor.c:3117
#5 0x00007ffff7d59110 in weston_output_maybe_repaint (output=0x555555c14f60, now=0x7fffffffd100) at ../libweston/compositor.c:3183
#6 0x00007ffff7d592e8 in output_repaint_timer_handler (data=0x55555556b380) at ../libweston/compositor.c:3250
#7 0x00007ffff7d208e2 in wl_timer_heap_dispatch (timers=0x555555562fa8) at ../src/event-loop.c:526
#8 wl_event_loop_dispatch (loop=0x555555562f60, timeout=timeout@entry=-1) at ../src/event-loop.c:1020
#9 0x00007ffff7d1e2b5 in wl_display_run (display=0x555555568e40) at ../src/wayland-server.c:1408
#10 0x00007ffff7fb5f24 in wet_main (argc=1, argv=0x7fffffffd948, test_data=0x0) at ../compositor/main.c:3589
#11 0x000055555555515e in main (argc=6, argv=0x7fffffffd948) at ../compositor/executable.c:33
(gdb) info locals
gr = 0x55555558b270
gs = 0x555555c35730
gb = 0x0
buffer = 0x0
repaint = {extents = {x1 = 0, y1 = 32, x2 = 1596, y2 = 1757}, data = 0x0}
surface_opaque = {extents = {x1 = 26, y1 = 23, x2 = 3222, y2 = 1817}, data = 0x555555c6d070}
surface_blend = {extents = {x1 = 0, y1 = 0, x2 = 3248, y2 = 1846}, data = 0x555555c0bf20}
filter = 9728
sconf = {req = {variant = 2, input_is_premult = true, green_tint = false, color_pre_curve = 0, color_mapping = 0, pad_bits_ = 0}, projection = {d = {0.00125313282, 0, 0, 0, 0, -0.00113830389, 0, 0, 0, 0, 1, 0,
-1, 1, 0, 1}, type = 3}, view_alpha = 1, unicolor = {0, 0, 0, 0}, input_tex_filter = 9728, input_tex = {5, 0, 0}, color_pre_curve_lut_tex = 0, color_pre_curve_lut_scale_offset = {0, 0}, color_mapping = {
lut3d = {tex = 0, scale_offset = {0, 0}}}}
```https://gitlab.freedesktop.org/wayland/weston/-/issues/620weston-gears missing2022-05-23T13:02:04Zdavidakweston-gears missingI want to have weston-gears, so i enabled the demo-clients in the Nix package. It added 18 demos, but gears is missing. Does it need another option enabled?
https://github.com/NixOS/nixpkgs/pull/174079/files
Build log: https://gitlab.f...I want to have weston-gears, so i enabled the demo-clients in the Nix package. It added 18 demos, but gears is missing. Does it need another option enabled?
https://github.com/NixOS/nixpkgs/pull/174079/files
Build log: https://gitlab.freedesktop.org/-/snippets/6207https://gitlab.freedesktop.org/wayland/weston/-/issues/619Update of absolute positions in Tk windows not working with Xwayland (Menu op...2022-06-29T11:48:17ZEnrico JornsUpdate of absolute positions in Tk windows not working with Xwayland (Menu opened at wrong location)When using TK applications together with weston and Xwayland, menus pop up at
the wrong location.
TK seems to use absolute positions to calculate the menu location on the screen.
I've traced this issue down to be a general issue with ob...When using TK applications together with weston and Xwayland, menus pop up at
the wrong location.
TK seems to use absolute positions to calculate the menu location on the screen.
I've traced this issue down to be a general issue with obtaining the correct
absolute root position of a widget from within TK, even for the root window.
In weston, the XWM `window-manager.c` method `send_position()` seems to be
responsible for setting the right position on Xserver/Xwayland side.
When invoked by a wayland shell, `send_position()` emits an
`xcb_configure_window()` call on the current window's *frame* with the absolute
coordinates it received.
This way the frame (handled by the weston WM) gets updated, but there is
nothing that would trigger an update of the actual *window* in which my TK
application runs in.
Thus this does not get notified about the updated coordinates.
Under pure X, this works however and I can see events in the xtrace (and Tk tracing) output of Tk like
000:>:00c5: Event (generated) ConfigureNotify(22) event=0x03e00004 window=0x03e00004 above-sibling=None(0x00000000) x=3097 y=620 width=200 height=200 border-width=0 override-redirect=false(0x00)
ConfigureEvent: . x = 3097 y = 620, width = 200, height = 200
send_event = 1, serial = 197 (win 0x1eacac0, wrapper 0x1ff0800)
. parent == 0x401d36, above (nil)
000:<:00c6: 4: Request(127): NoOperation
000:<:00c7: 16: Request(40): TranslateCoordinates src-window=0x03e00004 dst-window=0x00401d36 src-x=0 src-y=0
000:>:00c7:32: Reply to TranslateCoordinates: same-screen=true(0x01) child=0x03e00004 dst-x=2 dst-y=0
000:<:00c8: 8: Request(14): GetGeometry drawable=0x00401d36
000:>:00c8:32: Reply to GetGeometry: depth=0x18 root=0x000001a0 x=3095 y=620 width=204 height=202 border-width=0
wrapperPtr 0x1ff0800 coords 3097,620
wmPtr 0x1eac8c0 coords 3095,620, offsets 2 0
where `0x03e00004` is directly my Tk window.
Und weston, there is no such event received when moving.
The hack I tried to work around this is calling `xcb_configure_window()` on the
Tk *window* instead. However, this does not work because of multiple reasons:
1. if the position of the frame is not updated, an update of the window inside
will still not give the recent position in TK
Thus one needs to set the frame position first and then the window position.
2. The x/y position that needs to be set for the application *window* is set with coordinates relative to the frame.
But as this does not really change the X/ position, the Xwayland's dxi code simply drops the received ConfigNotify events.
3. Sending calculated absolute coordinates to the window leads to broken placement of it.
Questions that arise on my side are:
* Are my findings correct?
* Is it possible to call xcb_configure_window() with absolute coordinates?
* May I enforce Xwayland to not drop a configure event with non-changing coordinates?
* Is doing this in send_position() the actually right approach? Or should this be done somehow automatically when receiving XCB_CONFIGURE_NOTIFY from the frame?
Reproducing
===========
I can simply reproduce this behavior on any desktop with
weston --xwayland --debug --logger-scopes=xwm-wm-x11
and running this python application from an opened weston-terminal
#!/usr/bin/env python3
from tkinter import *
window=Tk()
def timer():
print( "widget pos: {},{}".format(window.winfo_rootx(), window.winfo_rooty()) )
window.after(1000, timer)
window.tk.eval("wm tracing true")
window.title('Hello Python')
window.after(1000, timer)
window.mainloop()
with
xtrace --timestamps -n ./example.py
Then you can move the window and see that the position is not updated.
Note that it will however update position when resizing or maximizing/minimizing the frame as this also generates config changes of the window (width/height) but also then the absolute position is not correct as it is not the recent one but the previous one.https://gitlab.freedesktop.org/wayland/weston/-/issues/618GStreamer getting stucks during weston sleep-wakeon2022-05-13T13:14:38ZKishan DudhatraGStreamer getting stucks during weston sleep-wakeonHi,
I am using weston(9.0.0) in IMX8MP(5.4.161 BSP).
I am facing an issue while running GStreamer video, it gets stuck on weston sleep(idle-time param).
Test Procedure:-
- Set `idle-time=15` in `weston.ini` in core section.
- Restart ...Hi,
I am using weston(9.0.0) in IMX8MP(5.4.161 BSP).
I am facing an issue while running GStreamer video, it gets stuck on weston sleep(idle-time param).
Test Procedure:-
- Set `idle-time=15` in `weston.ini` in core section.
- Restart weston services.
- Play video using GStreamer pipeline.
`gst-play-1.0 SampleVideo_1280x720_30mb.mp4 ! rtph264depay ! clockoverlay ! waylandsink`
- After idle-time reached weston going to sleep (video length is 2 mins - should be running in the backend ).
- **Now, wake-up weston using mouse/touch event and observe that video getting stuck(before sleep last frame freeze )
However in terminal video playback timer is running continuously.**https://gitlab.freedesktop.org/wayland/weston/-/issues/616logind: failed to get session seat2022-05-06T12:36:30ZJeremy Stashluklogind: failed to get session seatI want to put my board in suspend, but cannot send idle time to logind.
Weston creates a session, but has no seat for communicating with logind.
```
root@apalis-imx8-06824182:~# cat /var/log/weston.log
Date: 2022-05-06 UTC
[12:21:59.47...I want to put my board in suspend, but cannot send idle time to logind.
Weston creates a session, but has no seat for communicating with logind.
```
root@apalis-imx8-06824182:~# cat /var/log/weston.log
Date: 2022-05-06 UTC
[12:21:59.479] weston 9.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: lf-5.10.35-2.0.0-rc2+
[12:21:59.479] Command line: /usr/bin/weston --modules=xwayland.so --log=/var/log/weston.log
[12:21:59.479] OS: Linux, 5.4.154-5.6.0-devel+git.c65f1622951c, #1 SMP PREEMPT Mon Jan 3 15:58:01 UTC 2022, aarch64
[12:21:59.479] Using config file '/etc/xdg/weston/weston.ini'
[12:21:59.479] Output repaint window is 7 ms maximum.
[12:21:59.480] Loading module '/usr/lib/libweston-9/drm-backend.so'
[12:21:59.486] initializing drm backend
[12:21:59.486] logind: failed to get session seat
[12:21:59.486] logind: cannot setup systemd-logind helper (-61), using legacy fallback
[12:21:59.491] using /dev/dri/card1
```https://gitlab.freedesktop.org/wayland/weston/-/issues/615Crash when playing video with dmabuf interface2022-05-05T10:54:10ZAaron BoxerCrash when playing video with dmabuf interfaceI am working on a new MPV video output driver using the dmabuf interface.
Video playback will crash at the same spot with error message:
`wl_display@1: error 1: invalid arguments for zwp_linux_buffer_params_v1.add`
I have tested this o...I am working on a new MPV video output driver using the dmabuf interface.
Video playback will crash at the same spot with error message:
`wl_display@1: error 1: invalid arguments for zwp_linux_buffer_params_v1.add`
I have tested this on another compositor(sway) and no such problem.
What's the best way of getting more debug info for this ?
Thanks!
Note: I am using the current `main` branchhttps://gitlab.freedesktop.org/wayland/weston/-/issues/614Weston does not use scanout for weston-simple-dmabuf-feedback on AMD Gen >= 92022-05-25T06:24:20ZRobert MaderWeston does not use scanout for weston-simple-dmabuf-feedback on AMD Gen >= 9Weston doesn't use scanout/overlay planes when running `weston-simple-dmabuf-feedback` on my AMD system (with explicit modifier support).
From the default feedback it will pick the modifier `0x20000001896bb03` which is apparently not sc...Weston doesn't use scanout/overlay planes when running `weston-simple-dmabuf-feedback` on my AMD system (with explicit modifier support).
From the default feedback it will pick the modifier `0x20000001896bb03` which is apparently not scanout compatible.Other compositors will send a scanout tranche and `weston-simple-dmabuf-feedback` will switch to `0x200000018967b03`, allowing successful scanout.
Here are two logs for Weston with `--logger-scopes=log,drm-backend`:
- [weston-amd-default-new.log](/uploads/805d88b4efb95ec2fe00453717511d0c/weston-amd-default-new.log) default, no occurrence of "Using plane-only state composition"
- [weston-amd-force-0x200000018937b03-new.log](/uploads/9db618b60a71e9a959ad13d7f737b0ff/weston-amd-force-0x200000018937b03-new.log) force `0x200000018967b03` modifier -> successful scanout, lots of occurrences of "Using plane-only state composition"Robert MaderRobert Maderhttps://gitlab.freedesktop.org/wayland/weston/-/issues/613pixman-render: Keeping a weston_buffer ref alive with the underlying shm buff...2022-04-29T09:15:21ZMarius Vladpixman-render: Keeping a weston_buffer ref alive with the underlying shm buffer gone (on fade out views)With patch "weston_buffer: Hold lifetime for resource/backend usage" (7e90433079e08aafd560810817e60c46485a4bd2) `weston_buffer_destroy_handler()` which now marks `buffer->shm_buffer = NULL`, causes a side-effect
in `repaint_region()`.
...With patch "weston_buffer: Hold lifetime for resource/backend usage" (7e90433079e08aafd560810817e60c46485a4bd2) `weston_buffer_destroy_handler()` which now marks `buffer->shm_buffer = NULL`, causes a side-effect
in `repaint_region()`.
As the reference is still alive, but with its shm_buffer long gone, it will obviously fail. It doesn't appear
to be sufficient to add an additional check when accessing the shm_buffer. As the shm_buffer is no longer
available, it would fail at the next composite_* function. So ignoring the output repaint altogether seem to help,
but wonder if this is really a correct fix.
Something like the following:
```
diff --git a/libweston/pixman-renderer.c b/libweston/pixman-renderer.c
index 636d9d91..b7f54ac0 100644
--- a/libweston/pixman-renderer.c
+++ b/libweston/pixman-renderer.c
@@ -335,6 +335,9 @@ repaint_region(struct weston_view *ev, struct weston_output *output,
pixman_image_t *mask_image;
pixman_color_t mask = { 0, };
+ if (ps->buffer_ref.buffer && !ps->buffer_ref.buffer->shm_buffer)
+ return;
+
```
Haven't observed this with `close-animation=none` which might reveal why the reference is still alive but its buffer gone.