weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2024-03-08T19:52:26Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/889Drag and drop between Xwayland windows can drop onto a hidden window2024-03-08T19:52:26ZDemi Marie Obenourdemiobenour@gmail.comDrag and drop between Xwayland windows can drop onto a hidden windowIt is possible for drag and drop to drop data on a window that is currently covered by a different window. To reproduce this:
1. Open two text editor windows (such as Mousepad) using Xwayland.
2. Cover one (but not the other) with a nat...It is possible for drag and drop to drop data on a window that is currently covered by a different window. To reproduce this:
1. Open two text editor windows (such as Mousepad) using Xwayland.
2. Cover one (but not the other) with a native Wayland window, such as weston-terminal.
3. Drag and drop text from the uncovered one to where the covered one is.
This was copied from <https://gitlab.freedesktop.org/xorg/xserver/-/issues/1650>. @ofourdan wrote in <https://gitlab.freedesktop.org/xorg/xserver/-/issues/1650#note_2317612> that this is most likely a Weston bug.https://gitlab.freedesktop.org/wayland/weston/-/issues/864Flickering observed after coming out of Unigine heaven2024-02-11T18:08:21ZSriharsha P VFlickering observed after coming out of Unigine heavenIn weston, launch Unigine-heaven & after coming out of Unigine-heaven app to weston desktop could see continuous screen flickering.
Steps to reproduce issue:
1. Download linux Ungine-heaven file from link: https://benchmark.unigine.com/...In weston, launch Unigine-heaven & after coming out of Unigine-heaven app to weston desktop could see continuous screen flickering.
Steps to reproduce issue:
1. Download linux Ungine-heaven file from link: https://benchmark.unigine.com/heaven
2. Run the script it will create unigine-heaven folder with executable file.
3. Launch weston with --xwayland option using drm-backend
4. Launch terminal,go inside unigine-heaven folder & launch it giving command "./heaven"
5. select run from the unigine heaven window
6. It will start running animation window. Let it run for few secs, then press quit button & press ok
7. It will show credits window & then comes back weston desktop screen.
**Observed result:**
After coming back from Unigine-heaven to weston desktop screen flickers continuously & also when move the cursor.
**Expected result:**
After coming back from Unigine-heaven to weston desktop screen, no flickering should be seen.
Looks like issue is due to the side effect of below change:
https://gitlab.freedesktop.org/wayland/weston/-/commit/ea4700c81f03c3f3b2aeea5dfc5466b57f184ad2
Issue is not seen when I revert above change.
System details:
Ubuntu 22.04
Linux 6.5.0-rc3db-v3-uq-v5
AMD Ryzen 9 5900X
Issue video:![issue_video](/uploads/0560e3a0a8a3a948ca227478c922b83e/issue_video.mp4)
Non issue video after reverting above mentioned change:![non_issue_video](/uploads/abbef8bf00eefd60c111eb11ecb6979b/non_issue_video.mp4)https://gitlab.freedesktop.org/wayland/weston/-/issues/806Xwayland API header installation - should we always install it?2023-08-29T12:45:19ZMarius VladXwayland API header installation - should we always install it?Our shells, desktop/kiosk-shells are using `weston_xwayland_surface_api` for their transform handler
but also to verify if the underlying surface is a xwayland one or not.
This is all fine, but when XWayland is disabled, we still seem ...Our shells, desktop/kiosk-shells are using `weston_xwayland_surface_api` for their transform handler
but also to verify if the underlying surface is a xwayland one or not.
This is all fine, but when XWayland is disabled, we still seem to rely on the local header
rather than the installed one. For weston this again good, but for libweston users not so much, as that header
wouldn't be installed at all.
So I guess the question would be if we should install always the xwayland-api header and use `weston_xwayland_get_api()`
to determine if Xwayland support is built or not...?https://gitlab.freedesktop.org/wayland/weston/-/issues/796Xwayland test intermittently fails with timeout2023-08-09T11:58:14ZDaniel Stonedaniel@fooishbar.orgXwayland test intermittently fails with timeoutSometimes Xwayland fails with a timeout. It's not really clear why, but for some reason the client doesn't seem to get its `PROPERTY_NOTIFY` back, so presumably there's a race ... somewhere.
Compositor log:
```
[12:49:31.079] created w...Sometimes Xwayland fails with a timeout. It's not really clear why, but for some reason the client doesn't seem to get its `PROPERTY_NOTIFY` back, so presumably there's a race ... somewhere.
Compositor log:
```
[12:49:31.079] created wm, root 1298
[2023-08-09 12:49:31.080][xwm-wm-x11] XCB_CREATE_NOTIFY (window 2097153, at (0, 0), width 10, height 10, ours)
[2023-08-09 12:49:31.080][xwm-wm-x11] XCB_CREATE_NOTIFY (window 2097154, at (0, 0), width 8192, height 8192, ours)
[2023-08-09 12:49:31.082][xwm-wm-x11] XCB_CREATE_NOTIFY (window 2097191, at (0, 0), width 10, height 10, ours)
[2023-08-09 12:49:31.082][xwm-wm-x11] XCB_CREATE_NOTIFY (window 4194305, at (100, 100), width 100, height 100)
handle_event_set_pending: Added pending event id 28 - name PROPERTY_NOTIFY, wid 4194305
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Unsupported maximum keycode 708, clipping.
> X11 cannot support keycodes above 255.
Errors from xkbcomp are not fatal to the X server
[2023-08-09 12:49:31.099][xwm-wm-x11] XCB_MAPPING_NOTIFY
[2023-08-09 12:49:31.099][xwm-wm-x11] XCB_MAPPING_NOTIFY
[2023-08-09 12:49:31.100][xwm-wm-x11] XCB_PROPERTY_NOTIFY: window 4194305, _NET_WM_NAME: STRING/8, length 20 (value_len 20): "Xwayland Test Window"
```
Test backtrace:
```
(gdb) t a a bt
Thread 2 (Thread 0x7f44f592b6c0 (LWP 699519) "client"):
#0 0x00007f44f9af7450 in ppoll () at /lib64/libc.so.6
#1 0x00007f44fa091302 in ppoll () at /lib64/libasan.so.8
#2 0x00000000002266b0 in poll_for_event (conn=0x62a00000c200) at ../tests/xcb-client-helper.c:393
#3 0x0000000000226e0f in handle_events_x11 (window=0x60e000007120) at ../tests/xcb-client-helper.c:481
#4 0x0000000000212d64 in handle_events_and_check_flags (win=0x60e000007120, flag=PROPERTY_NAME) at ../tests/xcb-client-helper.h:193
#5 0x00000000002137cc in xwayland_client_test (_wet_suite_data=0x611000000918) at ../tests/xwayland-test.c:135
#6 0x000000000021362d in wrapxwayland_client_test (_wet_suite_data=0x611000000918, data=0x0) at ../tests/xwayland-test.c:115
#7 0x0000000000222fcd in run_test (suite_data=0x611000000918, fixture_nr=1, t=0x210e80 <testxwayland_client_test>, data=0x0, iteration=0) at ../tests/weston-test-runner.c:169
#8 0x0000000000223688 in run_case (suite_data=0x611000000918, t=0x210e80 <testxwayland_client_test>, test_data=0x0, iteration=0) at ../tests/weston-test-runner.c:284
#9 0x000000000022340f in for_each_test_case (data=0x611000000918, cb=0x2234f2 <run_case>) at ../tests/weston-test-runner.c:242
#10 0x000000000022395e in testsuite_run (data=0x611000000918) at ../tests/weston-test-runner.c:319
#11 0x00007f44f83188cd in client_thread_routine (data_=0x611000000918) at ../tests/weston-test.c:639
#12 0x00007f44f9a7e907 in start_thread () at /lib64/libc.so.6
#13 0x00007f44f9b04870 in clone3 () at /lib64/libc.so.6
Thread 1 (Thread 0x7f44f8d4d940 (LWP 699514) "test-xwayland"):
#0 0x00007f44f9b04c72 in epoll_wait () at /lib64/libc.so.6
#1 0x00007f44f9d7eae2 in wl_event_loop_dispatch (loop=0x60d000000450, timeout=timeout@entry=-1) at ../src/event-loop.c:1004
#2 0x00007f44f9d7c8a5 in wl_display_run (display=0x611000000b80) at ../src/wayland-server.c:1493
#3 0x00007f44f9fe3cf6 in wet_main (argc=1, argv=0x60e0000003c0, test_data=0x7f44f6f00140) at ../compositor/main.c:4244
#4 0x0000000000220faf in execute_compositor (setup=0x7f44f6f00030, data=0x611000000918) at ../tests/weston-test-fixture-compositor.c:410
#5 0x00000000002248c1 in weston_test_harness_execute_as_client (harness=0x611000000900, setup=0x7f44f6f00030) at ../tests/weston-test-runner.c:536
#6 0x0000000000212f06 in fixture_setup (harness=0x611000000900) at ../tests/xwayland-test.c:63
#7 0x0000000000212f81 in fixture_setup_run_ (harness=0x611000000900, arg_=0x0) at ../tests/xwayland-test.c:65
#8 0x0000000000224ee1 in main (argc=1, argv=0x7ffd74051968) at ../tests/weston-test-runner.c:684
```https://gitlab.freedesktop.org/wayland/weston/-/issues/769xwayland _NET_WM_STATE_ABOVE property / gitk crash relative & abs positioning2023-07-19T12:41:10ZMarius Vladxwayland _NET_WM_STATE_ABOVE property / gitk crash relative & abs positioningThis seems to be introduced with fe4d5711bf6d8e3dae9e8, when clicking on gitk Line diff (the window needs to be maximized)
we get the following crash:
```
#5 0x00007f80fc9bfdf2 in __GI___assert_fail
(assertion=0x7f80fc969c75 "!view...This seems to be introduced with fe4d5711bf6d8e3dae9e8, when clicking on gitk Line diff (the window needs to be maximized)
we get the following crash:
```
#5 0x00007f80fc9bfdf2 in __GI___assert_fail
(assertion=0x7f80fc969c75 "!view->geometry.parent", file=0x7f80fc9699a5 "../libweston/compositor.c", line=1640, function=0x7f80fc96bbc0 <__PRETTY_FUNCTION__.62> "weston_view_set_position") at ./assert/assert.c:101
#6 0x00007f80fc92b625 in weston_view_set_position (view=0x55cce976bbc0, pos=...) at ../libweston/compositor.c:1640
#7 0x00007f80fc95b338 in weston_desktop_surface_update_view_position (surface=0x55cce976c6f0) at ../libweston/desktop/surface.c:112
#8 0x00007f80fc95b73e in weston_desktop_surface_surface_committed (listener=0x55cce976c748, data=0x55cce9776330) at ../libweston/desktop/surface.c:199
#9 0x00007f80fc926fc6 in wl_signal_emit (signal=0x55cce9776350, data=0x55cce9776330) at /home/mvlad/install-amd64/include/wayland-server-core.h:496
#10 0x00007f80fc9312e8 in weston_surface_commit_state (surface=0x55cce9776330, state=0x55cce9776458) at ../libweston/compositor.c:4217
#11 0x00007f80fc931320 in weston_surface_commit (surface=0x55cce9776330) at ../libweston/compositor.c:4226
#12 0x00007f80fc93167f in surface_commit (client=0x55cce9701470, resource=0x55cce976b5b0) at ../libweston/compositor.c:4309
#13 0x00007f80fc66df7a in () at /lib/x86_64-linux-gnu/libffi.so.8
#14 0x00007f80fc66d40e in () at /lib/x86_64-linux-gnu/libffi.so.8
#15 0x00007f80fc66db0d in ffi_call () at /lib/x86_64-linux-gnu/libffi.so.8
#16 0x00007f80fc8f0496 in wl_closure_invoke (closure=closure@entry=0x55cce8e0df60, flags=flags@entry=2, target=<optimized out>,
```
With the xwm debug scope enabled:
```
[2023-07-04 12:13:21.641][xwm-wm-x11] XCB_CLIENT_MESSAGE (_NET_WM_STATE 1 303 0 0 0 win 4195344)
[2023-07-04 12:13:21.642][xwm-wm-x11] XCB_PROPERTY_NOTIFY: window 4195344, WM_HINTS: WM_HINTS/32, length 36 (value_len 9): huh?
[2023-07-04 12:13:21.643][xwm-wm-x11] XCB_PROPERTY_NOTIFY: window 4195344, WM_NORMAL_HINTS: WM_SIZE_HINTS/32, length 72 (value_len 18): huh?
[2023-07-04 12:13:21.645][xwm-wm-x11] XCB_CONFIGURE_NOTIFY (window 4195344) 611,367 @ 101x52, override
[2023-07-04 12:13:21.645][xwm-wm-x11] XCB_PROPERTY_NOTIFY: window 4195344, _NET_WM_STATE: ATOM/32, length 4 (value_len 1): _NET_WM_STATE_ABOVE
[2023-07-04 12:13:21.645][xwm-wm-x11] XCB_MAP_NOTIFY (window 4195344, override)
[2023-07-04 12:13:21.646][xwm-wm-x11] XCB_CLIENT_MESSAGE (WL_SURFACE_ID 65 0 0 0 0 win 4195344)
[2023-07-04 12:13:21.671][xwm-wm-x11] XWM: create weston_surface 0x55cce9776330
[2023-07-04 12:13:21.671][xwm-wm-x11] XWM: map shell surface, win 4195344, weston_surface 0x55cce9776330, xwayland surface 0x55cce975ffd0
```
We seem to be having a parent in this case even though the code assumes none.https://gitlab.freedesktop.org/wayland/weston/-/issues/756cleanup after cairo / xwayland / font map hash table destroy2023-06-07T12:06:27ZMarius Vladcleanup after cairo / xwayland / font map hash table destroyStarting with commit 823580e07094feab7d2a8a229fd7bd3a81dab5bc, the headless backend explicitly calls `cleanup_after_cairo()`
which seems to trigger an assert within cairo, when `cairo_debug_reset_static_data()` is called. This happens *o...Starting with commit 823580e07094feab7d2a8a229fd7bd3a81dab5bc, the headless backend explicitly calls `cleanup_after_cairo()`
which seems to trigger an assert within cairo, when `cairo_debug_reset_static_data()` is called. This happens *only*
when we run xwayland-test, and it happens once in a few runs, suggesting a race somewhere.
I initially thought this might be a result of `cairo_xcb_surface_create_with_xrender_format()` which still holds a reference
somehow. But going a bit deeper it seems that the specific assert would reference the same hash table (which the current code should
release all possible references), the font_map one, while `cairo_xcb_surface_create_with_xrender_format()` operates on a distinct hash table.
The trace looks like this:
```
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f29e32dbd2f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007f29e328cef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007f29e3277472 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00007f29e3277395 in __assert_fail_base
(fmt=0x7f29e33eba70 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f29e357e47b "hash_table->live_entries == 0", file=file@entry=0x7f29e357e467 "../src/cairo-hash.c", line=line@entry=219, function=function@entry=0x7f29e357e5c0 <__PRETTY_FUNCTION__.8> "_cairo_hash_table_destroy") at ./assert/assert.c:92
#5 0x00007f29e3285df2 in __GI___assert_fail
(assertion=0x7f29e357e47b "hash_table->live_entries == 0", file=0x7f29e357e467 "../src/cairo-hash.c", line=219, function=0x7f29e357e5c0 <__PRETTY_FUNCTION__.8> "_cairo_hash_table_destroy") at ./assert/assert.c:101
#6 0x00007f29e346ee6d in _cairo_hash_table_destroy (hash_table=0x55cf02eaf320) at ../src/cairo-hash.c:219
#7 0x00007f29e34bc48a in _cairo_scaled_font_map_destroy () at ../src/cairo-scaled-font.c:460
#8 0x00007f29e34622c1 in cairo_debug_reset_static_data () at ../src/cairo-debug.c:67
#9 0x00007f29e36dde10 in cleanup_after_cairo () at ../shared/cairo-util.c:700
#10 0x00007f29e36db9fa in headless_destroy (backend=0x55cf02e0b160) at ../libweston/backend-headless/headless.c:511
#11 0x00007f29e371438b in weston_compositor_destroy (compositor=0x55cf02e01c30) at ../libweston/compositor.c:8968
#12 0x00007f29e3776597 in wet_main (argc=1, argv=0x55cf02dfff00, test_data=0x7ffc85f2eff0) at ../compositor/main.c:4220
#13 0x000055cf02bb3d97 in execute_compositor (setup=0x7ffc85f2f060, data=0x55cf02dff998) at ../tests/weston-test-fixture-compositor.c:410
#14 0x000055cf02bb56e5 in weston_test_harness_execute_as_client (harness=0x55cf02dff980, setup=0x7ffc85f2f060) at ../tests/weston-test-runner.c:534
#15 0x000055cf02badb72 in fixture_setup (harness=0x55cf02dff980) at ../tests/xwayland-test.c:61
#16 0x000055cf02badb90 in fixture_setup_run_ (harness=0x55cf02dff980, arg_=0x0) at ../tests/xwayland-test.c:63
#17 0x000055cf02bb597d in main (argc=1, argv=0x7ffc85f2f248) at ../tests/weston-test-runner.c:682
```
The way that we handled this previously, like in fb57ce17ef3f9, was to explicitly call `pango_cairo_font_map_set_default(NULL)`. Instrumenting cairo when creating/insert/removing and destroying entries in that font_map hash table shows that there's still a cached version of a hash entry, but that there's *no holdover* that still references it . Now in normal runs, `_cairo_scaled_font_map_destroy()` would perform removal
from the font_map hash table, when it detects *at least a holdover*, and finally when `_cairo_hash_table_destroy()` is called, there are no entries left in that font map hash table.
For runs that trigger the assert `_cairo_scaled_font_map_destroy()` will skip removal of entries as that holdover is 0. It seems to suggest that there's window of time where the holdovers and the hash table entries are out-of-sync / or some kind of thread race, happening internally.
For `pango_cairo_font_map_set_default()`, the docs say:
```
" * Note that since Pango 1.32.6, the default fontmap is per-thread.
* This function only changes the default fontmap for
* the current thread. Default fontmaps of existing threads
* are not changed. Default fontmaps of any new threads will
* still be created using [func@PangoCairo.FontMap.new]."
```
What I've also noticed that building with -fsantize=address I can't trigger the issue, even after a few hundred of times. Might explain why I have not seen it before in CI, but I'm not excluding it.
So far, I've tried a couple of things, but I can still trigger it:
- add `pango_cairo_font_map_set_default(NULL)` in `weston_wm_destroy()` respectively `weston_wm_window_destroy()`
- in weston-test-runner.c add a `atexit(3)` to explicitly call `cleanup_after_cairo()` in that function, rather
than doing it in headless backend.
Maybe another set of eyes can over these might trigger some follow-up I could try.https://gitlab.freedesktop.org/wayland/weston/-/issues/747Segfault while playing a Xwayland game2023-04-25T09:03:56ZLink MauveSegfault while playing a Xwayland gameHere is the stack trace:
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f416483dcb0 in wm_debug_is_enabled (wm=<optimized out>) at ../xwayland/window-manager.c:221
221 ../xwayland/window-manager.c: No such...Here is the stack trace:
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f416483dcb0 in wm_debug_is_enabled (wm=<optimized out>) at ../xwayland/window-manager.c:221
221 ../xwayland/window-manager.c: No such file or directory.
[Current thread is 1 (Thread 0x7f41667e68c0 (LWP 2063))]
(gdb) bt
#0 0x00007f416483dcb0 in wm_debug_is_enabled (wm=<optimized out>) at ../xwayland/window-manager.c:221
#1 wm_printf (wm=0x562bdb775700, fmt=fmt@entry=0x7f41648490d0 "surface for xid %d destroyed\n") at ../xwayland/window-manager.c:230
#2 0x00007f416483dd7d in surface_destroy (listener=0x562bdb7de2d0, data=<optimized out>) at ../xwayland/window-manager.c:1967
#3 0x00007f4166ddeede in weston_signal_emit_mutable (data=0x562bdb7e8200, signal=0x562bdb7e8208) at ../shared/signal.c:62
#4 weston_surface_unref (surface=0x562bdb7e8200) at ../libweston/compositor.c:2170
#5 0x00007f416485358f in desktop_shell_destroy_surface (shsurf=0x562bdb775070) at ../desktop-shell/shell.c:293
#6 0x00007f4166da2a63 in wl_event_loop_dispatch_idle (loop=loop@entry=0x562bdadecc30) at ../wayland/src/event-loop.c:969
#7 0x00007f4166da2b74 in wl_event_loop_dispatch (loop=0x562bdadecc30, timeout=timeout@entry=-1) at ../wayland/src/event-loop.c:1032
#8 0x00007f4166d9fe67 in wl_display_run (display=display@entry=0x562bdadecb40) at ../wayland/src/wayland-server.c:1471
#9 0x00007f4167054c47 in wet_main (argc=<optimized out>, argv=<optimized out>, test_data=0x0) at ../compositor/main.c:4080
#10 0x00007f4166e4a790 in () at /usr/lib/libc.so.6
#11 0x00007f4166e4a84a in __libc_start_main () at /usr/lib/libc.so.6
#12 0x0000562bda80b055 in _start ()
```
It seems the server became `NULL` somehow, according to gdb still:
```
(gdb) p wm->server
$3 = (struct weston_xserver *) 0x0
```
What is strange is that I wasn’t destroying a surface, it might have been a crash of the game or of Xwayland, although I don’t see that in coredumpctl.https://gitlab.freedesktop.org/wayland/weston/-/issues/746Sudden mouse pointer shift with nested weston x11 backend in GNOME xwayland2023-04-25T05:24:12ZKeyu TaoSudden mouse pointer shift with nested weston x11 backend in GNOME xwaylandVersions:
- Arch Linux
- Weston 11.0.1-1
- Xorg-xwayland 23.1.1-1
- gnome-shell 43.4-1
- mutter 43.4-1
Description:
When using nested weston with x11-backend.so in GNOME Wayland session, mouse pointer inside weston shift unexpectedly f...Versions:
- Arch Linux
- Weston 11.0.1-1
- Xorg-xwayland 23.1.1-1
- gnome-shell 43.4-1
- mutter 43.4-1
Description:
When using nested weston with x11-backend.so in GNOME Wayland session, mouse pointer inside weston shift unexpectedly from time to time. I'm not quite sure whether it is a bug of weston, xwayland or GNOME. The wayland-backend.so does not have this issue.
I know that it is very weird to use x11-backend weston in a wayland session, and I found this issue when using nested X server with weston in x11docker -- I guess I should submit a bug report (let user decide whether to start weston in X or Wayland) to them afterwards.
How to reproduce:
1. In a wayland session (I only tested in GNOME) `weston --backend=x11-backend.so`
2. Start terminal inside weston
3. Drag the terminal window for several rounds, and move mouse to any corner of weston window
4. And then your mouse pointer is moved to an unexpected location
Video:
![Kooha-2023-04-25-05-33-49](/uploads/ac564bb810de630db57ca480851871f7/Kooha-2023-04-25-05-33-49.mp4)https://gitlab.freedesktop.org/wayland/weston/-/issues/722Resize is broken for X windows2023-02-28T17:15:46ZLeandro RibeiroResize is broken for X windowsAfter https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1153, resizing X windows has a weird behavior after releasing the drag. Examples:
- Firefox gets really small
- xterm disappears
If we can't fix that soon, it's bette...After https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1153, resizing X windows has a weird behavior after releasing the drag. Examples:
- Firefox gets really small
- xterm disappears
If we can't fix that soon, it's better to revert that MR and find another solution.
Reported by @derekf.https://gitlab.freedesktop.org/wayland/weston/-/issues/698Xwayland crashes if clipboard is set without a seat present2022-12-07T08:07:11ZDerek ForemanXwayland crashes if clipboard is set without a seat presentEasily reproduced with the RDP backend, as it only creates seats for active connections. Launch weston, don't connect an RDP client.
Use `DISPLAY=:0 xclip -i -selection clipboard` or similar to set a selection.Easily reproduced with the RDP backend, as it only creates seats for active connections. Launch weston, don't connect an RDP client.
Use `DISPLAY=:0 xclip -i -selection clipboard` or similar to set a selection.https://gitlab.freedesktop.org/wayland/weston/-/issues/643UI elements in rviz under Xwayland fail to dock properly2022-07-29T12:44:35ZDerek ForemanUI elements in rviz under Xwayland fail to dock properlyrviz allows users to undock panels and re-dock them. When running under weston via XWayland this leads to multiple flavours of brokenness.
Once the initial drag completes, attempting the drag the window again crashes the compositor. (!9...rviz allows users to undock panels and re-dock them. When running under weston via XWayland this leads to multiple flavours of brokenness.
Once the initial drag completes, attempting the drag the window again crashes the compositor. (!972)
The window also jumps to a set location and, even when patched with !972, can never be moved again(#642)
The window can be redocked with a double click on its title bar, but after that point it never visibly updates again - though it does process input events (eg: you can toggle the visible "grid" in the main application window with it)https://gitlab.freedesktop.org/wayland/weston/-/issues/642Some XWayland windows can't be moved as expected2022-09-22T11:14:23ZDerek ForemanSome XWayland windows can't be moved as expectedSome programs (like gkrellm) have no decor and attempt move themselves in response to mouse drags. Except we don't let them. They send Configure requests, but we ignore the requested co-ordinates.Some programs (like gkrellm) have no decor and attempt move themselves in response to mouse drags. Except we don't let them. They send Configure requests, but we ignore the requested co-ordinates.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/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/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/454Window position incorrect after restoring from fullscreen mode2022-06-20T17:59:27ZMarcel KorpelWindow position incorrect after restoring from fullscreen modeAfter returning from fullscreen mode, the window position of the restored window is changed: the window is about 20 pixels moved to the left and the top.
To reproduce, open a browser, e.g. Chromium, press F11 to go to fullscreen mode, a...After returning from fullscreen mode, the window position of the restored window is changed: the window is about 20 pixels moved to the left and the top.
To reproduce, open a browser, e.g. Chromium, press F11 to go to fullscreen mode, and return by pressing F11 again. Do this several times in a row. The first time, the window position of a maximized Chromium window still seems correct, but every other time you can see the window move up and left.https://gitlab.freedesktop.org/wayland/weston/-/issues/407Weston crashes on launching dolphin-emu on a Nouveau GPU using PRIME2020-06-02T10:37:33ZLink MauveWeston crashes on launching dolphin-emu on a Nouveau GPU using PRIMEHere is the relevant log from stderr:
```
[11:12:21.835] Spawned Xwayland server, pid 4179
glamor: No eglstream capable devices found
[11:12:21.962] xfixes version: 5.0
[11:12:21.966] created wm, root 924
The XKEYBOARD keymap compiler (x...Here is the relevant log from stderr:
```
[11:12:21.835] Spawned Xwayland server, pid 4179
glamor: No eglstream capable devices found
[11:12:21.962] xfixes version: 5.0
[11:12:21.966] created wm, root 924
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Unsupported maximum keycode 569, clipping.
> X11 cannot support keycodes above 255.
> Internal error: Could not resolve keysym Invalid
Errors from xkbcomp are not fatal to the X server
weston: cairo-xcb-screen.c:219: _get_screen_index: Assertion `!"reached"' failed.
(EE) failed to read Wayland events: Broken pipe
```
Since this is Xwayland, running a Qt application (so otherwise using EGL), this might be caused by drawing the frame around the X11 window.
I’m on Weston master (https://gitlab.freedesktop.org/wayland/weston/-/commit/40c519a3e6130f4f5f41b564057507a1e993fb5d), Xwayland 1.20.8, Mesa 20.1.0, Linux 5.6.15, on a Nvidia 1070 running Nouveau, while Weston renders/scanouts on an Intel UHD630.
This might be linked to https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035, which happens in the exact same environment, except without using `DRI_PRIME=1`.https://gitlab.freedesktop.org/wayland/weston/-/issues/390xwayland crashes on heap overflow problem address sanitizer2020-06-03T12:38:43Zxichenxwayland crashes on heap overflow problem address sanitizerI tried to compile weston with `-fsantitizer=address` on. It crashes when I launched a simple [hello world](https://gist.github.com/whosaysni/5733660) xlib program. I think there is a bit of heap reading problem on xwm side, I haven't go...I tried to compile weston with `-fsantitizer=address` on. It crashes when I launched a simple [hello world](https://gist.github.com/whosaysni/5733660) xlib program. I think there is a bit of heap reading problem on xwm side, I haven't gone through the code yet, later I would update on details.
Here is the crash report from santitizer.
```
==24542==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6080001d51fc at pc 0x7f0f61f1bab4 bp 0x7ffd9ff4d0f0 sp 0x7ffd9ff4c898
READ of size 72 at 0x6080001d51fc thread T0
#0 0x7f0f61f1bab3 in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
#1 0x7f0f4903d8a9 in weston_wm_window_read_properties ../xwayland/window-manager.c:597
#2 0x7f0f49043130 in weston_wm_handle_map_request ../xwayland/window-manager.c:1173
#3 0x7f0f4904be90 in weston_wm_handle_event ../xwayland/window-manager.c:2286
#4 0x7f0f61808fa9 in wl_event_loop_dispatch (/usr/lib/libwayland-server.so.0+0xafa9)
#5 0x7f0f618074e6 in wl_display_run (/usr/lib/libwayland-server.so.0+0x94e6)
#6 0x7f0f61e59872 in wet_main ../compositor/main.c:3388
#7 0x55ae68abd178 in main ../compositor/executable.c:33
#8 0x7f0f61c94022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
#9 0x55ae68abd08d in _start (/home/developer/Projects/weston-mine/install/bin/weston+0x108d)
0x6080001d51fc is located 0 bytes to the right of 92-byte region [0x6080001d51a0,0x6080001d51fc)
allocated by thread T0 here:
#0 0x7f0f61f8fb3a in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7f0f5e884b17 (/usr/lib/libxcb.so.1+0xeb17)
```https://gitlab.freedesktop.org/wayland/weston/-/issues/356_NET_WM_SYNC_REQUEST support2020-01-31T12:58:44ZPekka Paalanenppaalanen@gmail.com_NET_WM_SYNC_REQUEST supportThere is an old series implementing `_NET_WM_SYNC_REQUEST` support in XWM from @lfrb. It might be nice to resurrect and get merged.
https://patchwork.freedesktop.org/series/22883/
Four patches of the original eight remain. The very lea...There is an old series implementing `_NET_WM_SYNC_REQUEST` support in XWM from @lfrb. It might be nice to resurrect and get merged.
https://patchwork.freedesktop.org/series/22883/
Four patches of the original eight remain. The very least needs rebasing and a Gitlab submission.https://gitlab.freedesktop.org/wayland/weston/-/issues/351User can't escape from (fullscreen) override-redirect X window2020-01-31T11:48:21ZEero TamminenUser can't escape from (fullscreen) override-redirect X windowWith _NET_WM fullscreen window handling being fixed with #114, the problem of handling (fullscreen) override-redirect X windows remains.
If user starts e.g. one of these programs:
* Unigine [Valley](https://benchmark.unigine.com/valley)...With _NET_WM fullscreen window handling being fixed with #114, the problem of handling (fullscreen) override-redirect X windows remains.
If user starts e.g. one of these programs:
* Unigine [Valley](https://benchmark.unigine.com/valley) or [Heaven](https://benchmark.unigine.com/heaven) benchmark
* Xracer (open source) game
And configures their window to be in fullscreen, they change their window to be override-redirect (O-R) one.
Which results in:
1. Weston panel being shown on top of the window
2. Window covering rest of the screen i.e. all other apps/windows
3. User being unable to Alt-TAB (*) to another application and/or to kill the program
4. Window stopping to get any input from keyboard or mouse, i.e. user can't ask program itself to quit
I don't think Weston panel being shown on top of the O-R window is a problem, but user being unable to escape from the program is a serious UI reliability issue. Only thing non-technical user can do that at that point is power-cycle their computer. This is rather bad user experience, and I think against Wayland design principle for UI security/robustness.
There are some things that could be done to allow user to escape gracefully from this situation, at least when O-R window covers the whole screen (or workspace) area:
* Allow O-R layer to receive input, or
* Have O-R layer in the window stack so that user can Alt-TAB'ed to other windows. Whenever another O-R window opens, O-R layer should then be topped again
I think latter is preferable as it doesn't require application to co-operate and avoiding input to O-R windows is more secure. Large enough O-R windows might also be overlaid with huge "Legacy Overlay-Redirect Window, escape with Alt/Windows-TAB" text.
(*) For some reason Weston requires use of Windows key instead of Alt.
Here's an example of Xracer window properties:
```
WM_CLASS(STRING) = "xracer", "XRacer"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_HINTS(WM_HINTS):
Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 0, 0
user specified size: 1920 by 1080
WM_CLIENT_MACHINE(STRING) = "skl-skull"
WM_ICON_NAME(STRING) = "FREEGLUT"
WM_NAME(STRING) = "FREEGLUT"
xwininfo: Window id: 0x400002 "FREEGLUT"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1920
Height: 1080
Depth: 24
Visual: 0x1c8
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x400001 (not installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: yes
Corners: +0+0 -0+0 -0-0 +0-0
-geometry 1920x1080+0+0
```
=> Maybe other FreeGlut programs also use O-R for fullscreen?