wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2024-03-10T09:58:38Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/324Clarify on sub-surface `place_above`/`place_below`2024-03-10T09:58:38ZyshuiClarify on sub-surface `place_above`/`place_below`Quote:
> This state includes the sub-surface position relative to the parent surface (wl_subsurface.set_position), and the stacking order of the parent and its sub-surfaces (wl_subsurface.place_above and .place_below).
I read this as e...Quote:
> This state includes the sub-surface position relative to the parent surface (wl_subsurface.set_position), and the stacking order of the parent and its sub-surfaces (wl_subsurface.place_above and .place_below).
I read this as each surface has its own stack, which consists of itself and its immediate child sub-surfaces, is that correct? I find this ambiguous because the wording "parent and its sub-surfaces" can also mean "parent and all of its descendant", i.e. including grand-children, etc.
Also as a corollary, `.place_above` and `.place_below` moves the surface and its stack as a whole, is that right? Because otherwise the stacks can interleave which would break the assumption above.
(Example:
```
A
/ \
B C
|
D
```
initial stacking top to bottom: C, BD, A.
Call .place_above(C) on B, is the resulting stack:
1. BD, C, A; or
2. B, C, D, A?
)https://gitlab.freedesktop.org/wayland/weston/-/issues/669`xdg-activation` support2022-09-23T19:16:12ZMax Ihlenfeldt`xdg-activation` supportIn the discussion at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50#note_900740 @daniels said:
> Weston is NOPP
I'm not sure what that means - is support for `xdg-activation` not planned for Weston?In the discussion at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50#note_900740 @daniels said:
> Weston is NOPP
I'm not sure what that means - is support for `xdg-activation` not planned for Weston?https://gitlab.freedesktop.org/wayland/wayland/-/issues/323wl_data_device.leave after wl_data_device.drop2022-09-23T08:42:27ZVlad Zahorodniiwl_data_device.leave after wl_data_device.dropMany compositors send `wl_data_device.leave` after `wl_data_device.drop`, but on the other hand, `wl_data_device.leave`'s docs state that you should destroy the data offer if you receive that event
```xml
<event name="leave">
...Many compositors send `wl_data_device.leave` after `wl_data_device.drop`, but on the other hand, `wl_data_device.leave`'s docs state that you should destroy the data offer if you receive that event
```xml
<event name="leave">
<description summary="end drag-and-drop session">
This event is sent when the drag-and-drop pointer leaves the
surface and the session ends. The client must destroy the
wl_data_offer introduced at enter time at this point.
</description>
</event>
```
This has a conflict with `wl_data_offer.finish`. The client may not be able to finish drag-and-drop operation in a timely manner after receiving `wl_data_device.drop`.https://gitlab.freedesktop.org/wayland/weston/-/issues/667Fullscreen windows should get pointer confinement activated immediately by de...2024-02-26T12:46:12Zmanuel alfayateFullscreen windows should get pointer confinement activated immediately by defaultCurrently, when pointer confinement is asking for a window, user has to click on the window for the confinement to actually happen.
That's a compositor policy, implemented on `maybe_enable_pointer_constraint()` here:
https://gitlab.freed...Currently, when pointer confinement is asking for a window, user has to click on the window for the confinement to actually happen.
That's a compositor policy, implemented on `maybe_enable_pointer_constraint()` here:
https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/input.c#L3729
However, in the case of fullscreen windows, they should have the pointer confinement granted.
Think of any fullscreen UI or game where the pointer is only supposed to move on a part of the screen: it's very strange to have users click on screen before pointer confinement happens in that case.
So, modification of `maybe_enable_pointer_constraint()` is needed to detect whether a window is fullscreen, and grant pointer confinement immediately in that case.https://gitlab.freedesktop.org/wayland/weston/-/issues/666SDL2 programs cause a failed assertion on Weston when program quits while poi...2022-09-27T11:45:23Zmanuel alfayateSDL2 programs cause a failed assertion on Weston when program quits while pointer is confinedAll SDL2 programs with a confined pointer cause this assert on the Weston code to fail when they quit:
https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/input.c#L4745
The problem is that, on SDL2 window closing, mayb...All SDL2 programs with a confined pointer cause this assert on the Weston code to fail when they quit:
https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/input.c#L4745
The problem is that, on SDL2 window closing, maybe_warp_confined_pointer() is called, and at that point confine_region is already NULL.
The consequence of this is that closing any SDL2 program with a confined pointer causes Weston to suddenly die, which isn't nice at all.
I have an small SDL2 test program here:
https://github.com/vanfanel/LBE_DOCS/blob/master/SDL2-basic-example/ppp.c
...but all SDL2 programs with confined pointer are affected (Scummvm, etc).
I consider this is a Weston bug because it's only happening on this compositor, but of course I could be wrong.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/107idle-inhibit: allow inhibiting all outputs2022-09-17T18:14:59ZHugoidle-inhibit: allow inhibiting all outputsI maintain `caffeine-ng`, a tiny tray application where a user can manually toggle inhibiting screen powering off.
I'd like to inhibit screens being turned off for all outputs, but the current protocol requires that I provide a surface ...I maintain `caffeine-ng`, a tiny tray application where a user can manually toggle inhibiting screen powering off.
I'd like to inhibit screens being turned off for all outputs, but the current protocol requires that I provide a surface and will only inhibit idle for that one. I can hack around this with layer shell and create a surface on each output, but this is a terrible hack.
I'd like to be able to inhibit idle for all outputs -- perhaps with a new request, perhaps with just `surface=null`. Any thoughts on this?https://gitlab.freedesktop.org/wayland/wayland/-/issues/321Support specific XCURSORPATH or search XDG_DATA_DIRS2022-09-13T00:21:35ZcatsoutSupport specific XCURSORPATH or search XDG_DATA_DIRSCurrently there is no method to change the hardcode XCURSORPATH.
However, when using with some complex systems(such as flatpak/snap/nix), it may be needed.
We should support XDG_DATA_DIRS which is described in [XDG Base Directory Spe...Currently there is no method to change the hardcode XCURSORPATH.
However, when using with some complex systems(such as flatpak/snap/nix), it may be needed.
We should support XDG_DATA_DIRS which is described in [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html), or at least supports specific XCURSORPATH when compiling.
Related:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1484
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/192
https://github.com/alacritty/alacritty/issues/4371
https://github.com/flatpak/flatpak/commit/ad87b12264e2795c27a2a4da496b2e3c719767e1https://gitlab.freedesktop.org/wayland/weston/-/issues/663Follow-up from "protocol: add wl_compositor.error.bad_parent"2022-09-09T07:51:45ZPekka Paalanenppaalanen@gmail.comFollow-up from "protocol: add wl_compositor.error.bad_parent"The following discussion from wayland!264 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/264#note_1537544): (+1 comment)
> The first commit is good.
>
...The following discussion from wayland!264 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/264#note_1537544): (+1 comment)
> The first commit is good.
>
> ----
>
> FWIW, Weston's test suite already checks that:
> - `test_subsurface_paradox`: making a surface into its own child produces BAD_SURFACE
> - `test_subsurface_loop_paradox`: creating a sub-surface loop with three surfaces produces BAD_SURFACE
The mentioned MR changes the required error code. Weston and its test suite needs to be updated.https://gitlab.freedesktop.org/wayland/weston/-/issues/656weston demo lost focus after suspend & resume2022-09-12T07:57:07Zives liuweston demo lost focus after suspend & resumeHi all,
We meet a issue and reproduce it by running weston demo weston-eventdemo in Linux.
After suspend (echo mem > /sys/power/state) and resume, the demo lost focus and key press cannot be received by this demo.
If we use mouse to left...Hi all,
We meet a issue and reproduce it by running weston demo weston-eventdemo in Linux.
After suspend (echo mem > /sys/power/state) and resume, the demo lost focus and key press cannot be received by this demo.
If we use mouse to left click the console after resume, then it can repair and receive this key press again.
Could anyone share any idea about solving this issue? We hope this console will not lost focus and can receive key event after that resume.
Any idea would be greatly helpful for solving this problem.
Thanks!https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/104Add toplevel map-location hint to xdg-shell2023-05-14T05:58:46ZJulian OrthAdd toplevel map-location hint to xdg-shellApplications such as zoom will open a new window when a meeting is started. Usually there is a long time (at least several seconds) between the user requesting access to a meeting and the meeting actually starting. During this time the u...Applications such as zoom will open a new window when a meeting is started. Usually there is a long time (at least several seconds) between the user requesting access to a meeting and the meeting actually starting. During this time the user might move his focus to a different output or to a different workspace. When zoom finally creates the window, the compositor might map this window wherever the current focus of the user is.
Instead it might be more optimal to map the window on the same workspace or at least on the same output as the main zoom window.
The following addition to xdg-shell could allow us to fix this problem:
```
// Sets a hint for the compositor where to map this toplevel.
//
// This hint is only used during the current commit cycle. If the application
// unmaps the toplevel and later maps it again, it should set the hint again at
// that point.
//
// This hint is ignored unless the toplevel is newly mapped during this commit
// cycle.
//
// The compositor is free to ignore this hint.
fn xdg_toplevel::set_map_location_hint(
// The surface relative to which this toplevel should be mapped.
reference_surface: wl_surface,
// The granularity of the hint.
granularity: map_location_hint_granularity,
);
enum map_location_hint_granularity {
// The toplevel should be mapped on the same output as the reference surface.
Output,
// The toplevel should be mapped on the same workspace as the reference surface.
Workspace,
}
```https://gitlab.freedesktop.org/wayland/weston/-/issues/654Mipi display rotate with weston-wayland2024-02-01T10:20:09ZHimanshu BhavaniMipi display rotate with weston-waylandHi Team,
I want to rotate weston wayland window.
I can rotate weston wayland window using weston.ini, but it needs to restart weston service to apply the rotation.
Can any one help me with rotating weston wayland window without using ...Hi Team,
I want to rotate weston wayland window.
I can rotate weston wayland window using weston.ini, but it needs to restart weston service to apply the rotation.
Can any one help me with rotating weston wayland window without using weston.ini?
Any help will be appreciated.https://gitlab.freedesktop.org/wayland/weston/-/issues/653If no programs are displayed on the desktop ,"weston-touch-calibrator" can ne...2022-08-25T08:19:01Zbot crackIf no programs are displayed on the desktop ,"weston-touch-calibrator" can never be displayed when set to "panel-position=none"If no programs are displayed on the desktop ,"weston-touch-calibrator" can never be displayed when set to "panel-position=none"
Version is : Weston 10.0.0
weston.ini
[shell]
panel-position=none
[libinput]
touchscreen_calibrator=tr...If no programs are displayed on the desktop ,"weston-touch-calibrator" can never be displayed when set to "panel-position=none"
Version is : Weston 10.0.0
weston.ini
[shell]
panel-position=none
[libinput]
touchscreen_calibrator=true
calibration_helper=/bin/weston-calibration-helper.shhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/318Need flag/handle/protocol to disable low render rates on occlusion2022-08-18T22:56:47ZAndrew LentvorskiNeed flag/handle/protocol to disable low render rates on occlusionAs there seems to be no resolution to vkAcquireNextImageKHR getting 1Hz timeouts on Wayland from issue 99 in wayland-protocols (see: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99), there needs to be a way t...As there seems to be no resolution to vkAcquireNextImageKHR getting 1Hz timeouts on Wayland from issue 99 in wayland-protocols (see: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99), there needs to be a way to disable the frame rate drop on occlusion from Wayland either as a global flag or as a protocol that an application can request.
Thanks.https://gitlab.freedesktop.org/wayland/wayland/-/issues/317cursor: Theme that inherits itself causes infinite recursion2024-03-28T12:51:34ZNicolas Fellacursor: Theme that inherits itself causes infinite recursionThis was originally reported as https://bugs.kde.org/show_bug.cgi?id=457926
While of course nonsensical it is possible to write an xcursor theme that inherits itself, either directly or indirectly
This will cause infinite recursion whe...This was originally reported as https://bugs.kde.org/show_bug.cgi?id=457926
While of course nonsensical it is possible to write an xcursor theme that inherits itself, either directly or indirectly
This will cause infinite recursion when loading the theme via libwayland-cursor
A sample file is mentioned in the original report.
Backtrace from an affected application:
```
#0 __GI___libc_read (nbytes=4096, buf=0x17d2bf0, fd=29) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI___libc_read (fd=29, buf=0x17d2bf0, nbytes=4096) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x00007f75baa5c5b8 in _IO_new_file_seekoff (fp=0x155a000, offset=28, dir=<optimized out>, mode=<optimized out>) at fileops.c:1015
#3 0x00007f75baa59523 in __GI_fseek (fp=0x155a000, offset=28, whence=0) at fseek.c:36
#4 0x00007f75b78e2486 in _XcursorSeekToToc (toc=<optimized out>, fileHeader=0x16f4470, file=0x7ffe83376ef0) at ../cursor/xcursor.c:375
#5 _XcursorFileReadChunkHeader (chunkHeader=0x7ffe83376ee0, toc=<optimized out>, fileHeader=0x16f4470, file=0x7ffe83376ef0) at ../cursor/xcursor.c:388
#6 _XcursorReadImage (toc=<optimized out>, fileHeader=0x16f4470, file=0x7ffe83376ef0) at ../cursor/xcursor.c:478
#7 XcursorXcFileLoadImages (size=24, file=0x7ffe83376ef0) at ../cursor/xcursor.c:555
#8 XcursorFileLoadImages (size=24, file=0x155a000) at ../cursor/xcursor.c:609
#9 load_all_cursors_from_dir (load_callback=0x7f75b78e1bf0 <load_callback>, user_data=0x12db8c0, size=24, path=0x16f3b30 "/home/nico/.icons/VS5/cursors/") at ../cursor/xcursor.c:932
#10 xcursor_load_theme (theme=theme@entry=0x17cab00 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:989
#11 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17caa70 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#12 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca9e0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#13 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca950 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#14 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca8c0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#15 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca830 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#16 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca7a0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#17 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca710 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#18 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca680 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#19 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca5f0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#20 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca560 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#21 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca4d0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
```
Observed with wayland 1.20.0 on Fedora 36https://gitlab.freedesktop.org/wayland/wayland/-/issues/315surface offset semantics are mildly ambiguous2022-08-12T08:03:15ZDerek Foremansurface offset semantics are mildly ambiguousThe doc for wl_egl_window_resize states:
```
* If the wl_surface.offset request is used, applications MUST pass 0 to both
* dx and dy.
```
And the protocol documentation for wl_surface_attach states:
```
[...] Setting anything o...The doc for wl_egl_window_resize states:
```
* If the wl_surface.offset request is used, applications MUST pass 0 to both
* dx and dy.
```
And the protocol documentation for wl_surface_attach states:
```
[...] Setting anything other than 0
as x and y arguments is discouraged, and should instead be replaced
with using the separate wl_surface.offset request.
When the bound wl_surface version is 5 or higher, passing any
non-zero x or y is a protocol violation, and will result in an
'invalid_offset' error being raised. To achieve equivalent semantics,
use wl_surface.offset.
```
So we have text that indicates that it's ok to pass dx, dy to wl_egl_window_resize if you're not using wl_surface.offset, and we have text that suggests that passing x, y to an attach is merely discouraged, but we also clearly state that you'll receive an error for using non-zero x or y in any situation in which wl_surface.offset is *available* to you, regardless of whether it's used or not.
I think we should probably at least change the wl_egl_window_resize test to ``` * If the wl_surface.offset request is available ``` ?https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/103Window embedding API2022-08-29T18:44:18ZIlya FedinWindow embedding APII have a trouble porting application functionality to Wayland. The application has web-based features and uses webkit2gtk while itself is not written in gtk. It does so with window embedding, but I don't see equivalent API in Wayland. I ...I have a trouble porting application functionality to Wayland. The application has web-based features and uses webkit2gtk while itself is not written in gtk. It does so with window embedding, but I don't see equivalent API in Wayland. I heard I can create a nested compositor, but I fail to find a library that would allow me doing that in a reasonable amount of code. Implementing low-level things like mapping input/output/keyboard layout/keyboard/entire xdg-shell/etc is absolutely doesn't worth the effort (especially given that Wayland is only 7% of 2% of the application userbase currently and all other platforms allow to embed system-provided webview with a little amount of code, like in 3 lines using toolkit-provided API and native window handle).
I believe this is an essential problem as not every toolkit has things like webview and cross-toolkit interability is a must therefore.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/101Define protocol naming (prefix or not)2022-08-14T04:24:17ZKenny LevinsenDefine protocol naming (prefix or not)Some protocols put their prefix in their protocol name, others do not. The README requires the prefix in interface names, but merely refers to it as a namespace for the protocol name, not explicitly requiring a prefix.
At the current ti...Some protocols put their prefix in their protocol name, others do not. The README requires the prefix in interface names, but merely refers to it as a namespace for the protocol name, not explicitly requiring a prefix.
At the current time, the vast majority of wp protocols do not apply the prefix to their protocol name, whereas all xdg and ext protocols do apply their prefix to their protocol name.
It would be nice to have a formalized rule in the README to avoid future confusion.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/100RFC: Protocol for reading global (style) settings or properties2023-06-13T19:18:53ZJulian KirschRFC: Protocol for reading global (style) settings or propertiesPlatforms such as macOS and Windows provide functions for accessing global settings such as "double click time" (see here [Win32](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdoubleclicktime)/[macOS](https://d...Platforms such as macOS and Windows provide functions for accessing global settings such as "double click time" (see here [Win32](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdoubleclicktime)/[macOS](https://developer.apple.com/documentation/appkit/nsevent/1528384-doubleclickinterval)) or the current "accent colour" (again, see here [Win32](https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings?view=winrt-22621)/[macOS](https://developer.apple.com/documentation/SwiftUI/Color/accentColor?changes=_3)).
Functions like these enable developers to create applications, that look or at least feel consistent on the platform. As far as I am aware, there is no proper alternative except for libraries such as `Gio`, which are not necessarily authoritative and are bound to a distinct toolkit and/or WM/compositor.
The need for such interface is, IMHO, evident given "recent" issues, that I came across such as #57 or https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/95#note_1493449.
The aspect that strikes me the most is that this can bring some consistency for applications using CSD by requesting things such as "accent colour", "border width"
without being coupled to a toolkit the compositor may or may not use.
## Request for comment
Given that there is no protocol for this yet, would you even accept such interface? (I can't be the first one to think of such protocol).
To be clear, I am envisioning an API similar to GIO, where a developer can try to request properties using keys. I.e. like that (warning, ignoring conventions for the examples sake):
```c
bool has_xyz = wl_store_has(u8"property-xyz");
type = wl_store_get_type(u8"xdg:accent-color");
u16 border_width = 0;
wl_store_get_u16(u8"xdg:border-width", &border_width);
u32 accent_color = 0;
result = wl_store_get_u32(u8"xdg:accent-color", &accent_color);
bool is_dark_mode = false;
wl_store_get_boolean(u8"xdg:dark-mode-enabled", &is_dark_mode);
path font_path = null_path;
wl_store_get_path(u8"xdg:decoration-title-font-path", &font_path);
// A result type may be used to check, whether the property exists at all
// and if the property is assignable to the given variable.
// Alternatively, getters may return an "any" type and it is the developers
// responsibility to determine the type.
// ...
// Analogous for other, primitive types.
//
//
// After an incubation period, one could make vague attempts at standardizing certain properties
// and provide constants:
//
u32 accent_color = 0;
result = wl_store_get_u16(WL_STORE_XDG_ACCENT_COLOR, &accent_color);
```
Keys should be strings following a strict schema, perhaps even reverse domain notation to prevent conflicts.
Properties may be enumerated following a similar scheme as seen in `wl_registry_listener`.
Considering XOrg, one can probably implement this there as well by using prefixed atoms, e.g. "PROP:org.freedesktop.dark-mode-enabled".
---
I'd like to develop a protocol like this, but:
- What are your thoughts on that?
- Are you willing to accept such protocol at all?
- Is there something that needs special thought?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.