weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2020-11-06T10:33:29Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/451Should libexec_weston be promoted into a proper public library?2020-11-06T10:33:29ZPekka Paalanenppaalanen@gmail.comShould libexec_weston be promoted into a proper public library?Currently, libexec_weston is a private shared convenience library that contains essentially everything that makes the `weston` binary, and is installed without a pkg-config file into an unconventional library path to avoid other projects...Currently, libexec_weston is a private shared convenience library that contains essentially everything that makes the `weston` binary, and is installed without a pkg-config file into an unconventional library path to avoid other projects linking to it. It is unversioned and has no stable ABI. You cannot install multiple versions of it simultaneously, like you can't install multiple versions of Weston the compositor.
Libexec_weston exists for two reasons:
- Weston plugins can be built with all symbols resolved when they link to it. (Libweston plugins do not need or use it.)
- Weston test suite uses it to run the compositor in-process.
Other projects cannot currently do either. Would other projects be interested in having those possibilities?
If we were to promote libexec_weston as a proper public library:
- It needs to be versioned. That means it has it's own major version number separate from libweston.
- It needs to have a defined ABI, so that we know when we break it and need to bump the major version.
- It probably needs a better name. `libweston-frontend` maybe?
- It needs a pkg-config file.
It would also cause questions and issues:
- Does it need to be parallel-installable like libweston is? What to do with the installed file resources it needs?
- It would be a library that does process-wide actions, e.g. sets up signal handlers.
- Do we keep the project version derived from libweston major version and let libweston-frontend major version diverge? What happens to the project version when libweston-frontend bumps major but libweston does not?
The version number questions would have applied to libweston-desktop as well if it wasn't decided to strictly follow libweston major both ways. Doing that with yet another library may be going too far.
Should we go for this? If yes, why?https://gitlab.freedesktop.org/wayland/weston/-/issues/450xdg-shell: set_parent() should be a no-op when the parent surface passed is n...2024-02-28T10:22:02ZMarius Vladxdg-shell: set_parent() should be a no-op when the parent surface passed is null?This is more of a question rather an issue and would like to get some
feedback on the matter.
So, according to the XDG-Shell proto, for `set_parent()` the following is written:
> Setting a null parent for a child window removes any ...This is more of a question rather an issue and would like to get some
feedback on the matter.
So, according to the XDG-Shell proto, for `set_parent()` the following is written:
> Setting a null parent for a child window removes any parent-child
> relationship for the child. Setting a null parent for a window which
> currently has no parent is a no-op.
Now, in libweston-desktop, the implementation for `set_parent()` will make sure to
call `weston_desktop_xdg_toplevel_ensure_added()` no matter if the argument to parent
is null and there's no check if the current top level surface has any children.
For situations where the client issues a `set_parent()` for a top level
surface which wasn't even added until then, will this be considered as a no-op or
my interpretation of the above is faulty?
A consequence of that is that any property set to the top level surface, for instance,
if a client does the following:
```
wl_compositor@4.create_surface(new id wl_surface@38)
xdg_wm_base@18.get_xdg_surface(new id xdg_surface@39, wl_surface@1)
xdg_surface@39.get_toplevel(new id xdg_toplevel@40)
xdg_toplevel@40.set_parent(nil)
xdg_toplevel@40.set_title("title")
wl_surface@38.commit()
```
will result in the fact that `desktop_api.set_parent()` will not "see"/gain access to the properties
at that time.
Question is, should or shouldn't `weston_desktop_xdg_toplevel_ensure_added()` be deferred until
properties have been added, or alternatively, check if there are any children in case the parent arg
being passed is null. I guess that is even easier to check as if the top level surface wasn't even
added as it can't have any children obviously.
Notice that changing the order between setting the property and doing `set_parent()` will change
the outcome.https://gitlab.freedesktop.org/wayland/weston/-/issues/448capture.wcap does not contain output for second monitor2020-11-02T15:08:20ZDaniel Kahn Gillmorcapture.wcap does not contain output for second monitori have a dual monitor setup, running weston 9.0.0-2 on debian unstable. The first monitor is 800×600, the second monitor is 1680×1050.
i use `super+R` to record the desktop. It places `capture.wcap` in the directory i launched `weston`...i have a dual monitor setup, running weston 9.0.0-2 on debian unstable. The first monitor is 800×600, the second monitor is 1680×1050.
i use `super+R` to record the desktop. It places `capture.wcap` in the directory i launched `weston` from.
When i run `wcap-decode capture.wcap`, though, it reports only the data from the first monitor:
```
$ wcap-decode capture.wcap
wcap file: size 800x600, 3140 frames
$
```
This is a problem because i want to record activity in a multi-monitor setup to [document a problem with GtkEntryCompletion under Wayland](https://gitlab.gnome.org/GNOME/gtk/-/issues/699)https://gitlab.freedesktop.org/wayland/weston/-/issues/445minimum toplevel size is ignored2020-11-09T05:50:03ZChristian Rauchrauch.christian@gmx.deminimum toplevel size is ignoredWeston seems to ignore the minimum dimensions that are set via `xdg_toplevel_set_min_size`.
1. build and run the [libdecoration demo](https://gitlab.gnome.org/jadahl/libdecoration)
2. decrease size of window via dragging on the edges
T...Weston seems to ignore the minimum dimensions that are set via `xdg_toplevel_set_min_size`.
1. build and run the [libdecoration demo](https://gitlab.gnome.org/jadahl/libdecoration)
2. decrease size of window via dragging on the edges
The client has a minimum size set so that a 2x8 checker pattern should be visible and the min/max/close buttons are inside the title bar area. However, in weston the toplevel can be decreased up to the point where the min/max/close buttons are outside of the window geometry and further to the point where the toplevel area decreases to 0:
![weston_min_size](/uploads/58f9bb959c7e32ce104cb920534ca182/weston_min_size.m4v)
This works as expected in mutter / GNOME Shell.https://gitlab.freedesktop.org/wayland/weston/-/issues/444Fix libweston.so EGL dep - Follow-up from "libweston/backend/drm: might need ...2020-10-23T08:33:47ZPekka Paalanenppaalanen@gmail.comFix libweston.so EGL dep - Follow-up from "libweston/backend/drm: might need EGL"The following discussion from !508 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/508#note_670782):
> > This condition is modelled after a similar one in libwes...The following discussion from !508 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/508#note_670782):
> > This condition is modelled after a similar one in libweston/meson.build
>
> That highlights a problem in `libweston/meson.build`. libweston must not link to EGL libraries, but looks like it does. Instead, it only needs the EGL headers for `pixel-formats.c`. It is missing to use `partial_dependency(compile_args: true)`.https://gitlab.freedesktop.org/wayland/weston/-/issues/442Use cursor_view to check if cursor plane's view changed between repaints2020-10-20T14:15:41ZLeandro RibeiroUse cursor_view to check if cursor plane's view changed between repaintsThe following discussion from !458 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458#note_655629): (+3 comments)
> After looking more into `cursor_view` I...The following discussion from !458 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458#note_655629): (+3 comments)
> After looking more into `cursor_view` I'm disappointed in myself. I think we should remove it long-term, or at least construct it in a less foolish way. (`drm_plane_state` has a `ev` member, but it's only live across `assign_planes`; we could keep it live for longer if we had a view destroy listener which `NULL`ed out the view when it was destroyed, then we could just look at `output->prev_state->plane_list[output->cursor_plane]->ev` to see if the cursor plane's view had changed between repaints.)
See `drm_output_prepare_cursor_view()` and `drm_assign_planes()` in `state-propose.c` for better understanding.https://gitlab.freedesktop.org/wayland/weston/-/issues/441The ball in weston-simple-damage leaves a trail after itself2022-01-13T22:20:18ZVlad ZahorodniiThe ball in weston-simple-damage leaves a trail after itselfIf weston-simple-damage runs with weston, the ball leaves a trail after itself. This bug can be also reproduced with kwin. It doesn't matter if transformed buffers are provided.If weston-simple-damage runs with weston, the ball leaves a trail after itself. This bug can be also reproduced with kwin. It doesn't matter if transformed buffers are provided.https://gitlab.freedesktop.org/wayland/weston/-/issues/439Getting notified when weston actually displays the desktop visually2020-10-08T12:41:01ZMustafa ÖzçelikörsGetting notified when weston actually displays the desktop visuallyHi,
I am trying to use weston in a couple of embedded platform projects. When weston-start is executed, there is a delay of 1 or 2 seconds before something is displayed on the screen. I wonder if there is a way that we could get notifie...Hi,
I am trying to use weston in a couple of embedded platform projects. When weston-start is executed, there is a delay of 1 or 2 seconds before something is displayed on the screen. I wonder if there is a way that we could get notified when weston actually displays the desktop. The reason that I want to know this is that I would like to close down system services right about when something is displayed on the screen by weston. Otherwise, pre-weston services that use the framebuffer draws on top of weston and that causes an unpleasent flickering to look at. Furthermore, if I knew when the desktop is ready, I can adjust services that use weston to start. I think this would be a nice feature. If it is already implemented, I would like to know. Thanks in advance.https://gitlab.freedesktop.org/wayland/weston/-/issues/438Super+Shift+Tab doesn't go to previous window2022-02-25T10:53:20ZJim BSuper+Shift+Tab doesn't go to previous windowComing from a windows world, I sort of expect things like alt-tab and alt-shift-tab to change windows.
I can sort of deal with super+tab instead; however if I miss the window I want to go to, I can't just hit shift and tab to go back a w...Coming from a windows world, I sort of expect things like alt-tab and alt-shift-tab to change windows.
I can sort of deal with super+tab instead; however if I miss the window I want to go to, I can't just hit shift and tab to go back a window....
Looking at the settings there doesn't even seem to be a method to trigger to go to previous window.
Windows also on alt-tab, these days, shows a palette with windows on it which I can just go up to and click on while still holding alt to go to that window directly... that is occasionally a nice feature that I'd wished for since win3.1.https://gitlab.freedesktop.org/wayland/weston/-/issues/435Assertion atomic_complete_pending failed after EBUSY on hotplug2020-09-18T18:31:31ZPekka Paalanenppaalanen@gmail.comAssertion atomic_complete_pending failed after EBUSY on hotplugI start Weston/DRM/GL with three monitors connected.
Unplug one monitor, and re-plug it. This hits EBUSY, which is likely #24.
Unplug the same monitor again, and re-plug it. That results in
```
weston: ../../git/weston/libweston/backen...I start Weston/DRM/GL with three monitors connected.
Unplug one monitor, and re-plug it. This hits EBUSY, which is likely #24.
Unplug the same monitor again, and re-plug it. That results in
```
weston: ../../git/weston/libweston/backend-drm/kms.c:1404: atomic_flip_handler: Assertion `output->atomic_complete_pending' failed.
```
[Full Weston log](/uploads/5705166d5dbabe8532d0ba6aca202fe4/loki.txt)https://gitlab.freedesktop.org/wayland/weston/-/issues/434Issue EVIOCGRAB on all input devices on non-default seats2020-09-16T23:01:55ZPekka Paalanenppaalanen@gmail.comIssue EVIOCGRAB on all input devices on non-default seatsThe following discussion from !494 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/494#note_625950): (+3 comments)
> Btw. do not try this without an actual norma...The following discussion from !494 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/494#note_625950): (+3 comments)
> Btw. do not try this without an actual normal desktop running. If you are in VT text mode, then the udev seat assignment will **not** stop the insecure keyboard typing going to the console!
In that thread, @whot suggest to issue `EVIOCGRAB` on the input devices to avoid leaking them to the console. There are corner case issues with doing that (things like rfkill stop getting the events), but those can be ignored on non-default seats.
This would need to be implemented in all three lauchers.https://gitlab.freedesktop.org/wayland/weston/-/issues/429Prune DRM modifier list when enabling a new output2023-09-06T08:46:15ZPekka Paalanenppaalanen@gmail.comPrune DRM modifier list when enabling a new outputEnabling a new output with other outputs already existing can fail for the first modifier that GBM picks. An example of this is running out of available bandwidth on Intel when using a specific modifier for one output, leaving very littl...Enabling a new output with other outputs already existing can fail for the first modifier that GBM picks. An example of this is running out of available bandwidth on Intel when using a specific modifier for one output, leaving very little room to enable any other output.
Therefore, Weston should do something like this when enabling a new output:
1. Get the primary plane `IN_FORMATS` as the modifier list.
2. Create a GBM surface with the modifier list.
3. `glClear(); eglSwapBuffers();`
4. `gbm_surface_lock_front_buffer()` to get a buffer.
5. Do a `TEST_ONLY` atomic commit with the buffer on the primary plane.
6. `gbm_surface_release_buffer();`
7. If the test commit fails, remove the modifier used by the buffer from the modifier list, destroy the GBM surface, and go to 2.
But this is not enough, if an existing output is using a modifier that consumes all available resources. Therefore if the modifier list becomes empty, we have to start pruning the modifier lists of other outputs and then repeat the above at each step.
But this leads to combinatorial explosion to test: on which existing output do you drop the current modifier first? Second? Then?
cc @danvet @emersionhttps://gitlab.freedesktop.org/wayland/weston/-/issues/425Replace hand-crafted pixel format conversion routines with Pixman calls2020-10-08T12:17:32ZLeandro RibeiroReplace hand-crafted pixel format conversion routines with Pixman callsThe following discussion from !458 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458#note_596068): (+2 comments)
> Oh my, I didn't even realize these were dupl...The following discussion from !458 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458#note_596068): (+2 comments)
> Oh my, I didn't even realize these were duplicated already.
>
> They should be replaced with `pixman_image_composite32()` calls, but that's another story. Just leave them here.
Instead of writing our own functions to copy the screenshot to the client buffer, it is better to use `pixman` functions instead.https://gitlab.freedesktop.org/wayland/weston/-/issues/423Fix libweston ABI minor version?2020-08-21T08:35:06ZPekka Paalanenppaalanen@gmail.comFix libweston ABI minor version?wayland/wayland#175 explains the issue. It looks to me like the version number computations for libweston ignore the project minor version.
Check if there is something to be fixed and fix it.
So far this hasn't been really a problem, b...wayland/wayland#175 explains the issue. It looks to me like the version number computations for libweston ignore the project minor version.
Check if there is something to be fixed and fix it.
So far this hasn't been really a problem, because libweston is much less used and has been bumping its major practically every release.https://gitlab.freedesktop.org/wayland/weston/-/issues/418Cannot start weston on orangepi 3 (architecture=arm642024-02-20T14:29:48ZChen2008Cannot start weston on orangepi 3 (architecture=arm64I want test wayland work on my board,I want start weston,but it says:
```
Date: 2020-08-08 CST
[23:02:47.978] weston 8.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayl...I want test wayland work on my board,I want start weston,but it says:
```
Date: 2020-08-08 CST
[23:02:47.978] weston 8.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 8.0.0
[23:02:47.979] Command line: weston --modules=xwayland.so
[23:02:47.979] OS: Linux, 5.6.16-sunxi64, #7 SMP Fri Jul 24 01:39:42 CST 2020, aarch64
[23:02:47.998] Using config file '/root/.config/weston.ini'
[23:02:48.026] Output repaint window is 7 ms maximum.
[23:02:48.043] Loading module '/usr/lib/aarch64-linux-gnu/libweston-8/x11-backend.so'
[23:02:48.203] Loading module '/usr/lib/aarch64-linux-gnu/libweston-8/gl-renderer.so'
[23:02:48.434] EGL client extensions:
[23:02:48.435] warning: either no EGL_EXT_platform_base support or specific platform support; falling back to eglGetDisplay.
[23:02:48.435] failed to create display
[23:02:48.435] fatal: failed to create compositor backend
```
If I use drm backend,looks like this:
```
"drm-backend has not been destroyed.specfific platform support"
```
What should I do?https://gitlab.freedesktop.org/wayland/weston/-/issues/416Nested sub-surfaces in shells (Follow-up from "kiosk-shell: Introduce kiosk/f...2020-10-29T12:14:14ZPekka Paalanenppaalanen@gmail.comNested sub-surfaces in shells (Follow-up from "kiosk-shell: Introduce kiosk/fullscreen shell for desktop apps")The following discussion from !416 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/416#note_559762): (+1 comment)
> Isn't this forgetting to account for nested s...The following discussion from !416 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/416#note_559762): (+1 comment)
> Isn't this forgetting to account for nested sub-surfaces?
>
> However, if desktop-shell has the exact same code, I'd be ok with just adding a comment here explaining desktop-shell does the same and the problem it has.
>
> I think most of the code in `kiosk-shell/util.c` is such that we should add in libweston as a helper library, but that's something out of scope for this MR (unless you want to do that work in this MR). If not done in this MR, we should have an issue filed about introducing such a helper function collection and de-duplicating this code.Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/issues/413Follow-up from "Run DRM-backend tests on GitLab CI"2020-06-25T10:13:00ZDaniel Stonedaniel@fooishbar.orgFollow-up from "Run DRM-backend tests on GitLab CI"The following discussion from !436 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/436#note_549788):
> Whenever the relevant vKMS support makes it into a re...The following discussion from !436 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/436#note_549788):
> Whenever the relevant vKMS support makes it into a released mainline kernel, we should update the kernel clone to use that release tag.https://gitlab.freedesktop.org/wayland/weston/-/issues/412weston-simple-egl on Intel iris leaks memory2020-10-23T23:12:58ZChristian Rauchrauch.christian@gmx.deweston-simple-egl on Intel iris leaks memoryRunning `weston-simple-egl` (weston 8, Ubuntu 20.04) and monitoring the memory usage simply by the GNOME system monitor shows an increase of memory over time (starts at 40.0MB, reaches 40.9MB after 30 seconds).
I've only seen this with ...Running `weston-simple-egl` (weston 8, Ubuntu 20.04) and monitoring the memory usage simply by the GNOME system monitor shows an increase of memory over time (starts at 40.0MB, reaches 40.9MB after 30 seconds).
I've only seen this with the new Intel `iris` driver. So not really sure if this is a client or driver issue.
With `MESA_LOADER_DRIVER_OVERRIDE=i965 weston-simple-egl` this already starts with a lower memory usage of 21.1MB and stays constant for at least two minutes.
Valgrind just reports many invalid writes in `iris_dri.so` / `i965_dri.so`.https://gitlab.freedesktop.org/wayland/weston/-/issues/408Weston segfaults when starting dolphin-emu’s inexistant Wayland backend2020-10-05T21:10:24ZLink MauveWeston segfaults when starting dolphin-emu’s inexistant Wayland backendHere is the stack trace:
```
(gdb) bt
#0 weston_view_schedule_repaint (view=0x562c82647b60) at ../libweston/compositor.c:1697
#1 0x00007f75cd35ce95 in weston_view_damage_below (view=0x562c82647b60) at ../libweston/compositor.c:1055
#2 ...Here is the stack trace:
```
(gdb) bt
#0 weston_view_schedule_repaint (view=0x562c82647b60) at ../libweston/compositor.c:1697
#1 0x00007f75cd35ce95 in weston_view_damage_below (view=0x562c82647b60) at ../libweston/compositor.c:1055
#2 0x00007f75c8f0d656 in weston_desktop_view_destroy (view=0x562c8262ab80) at ../libweston-desktop/surface.c:119
#3 0x00007f75c8f0d805 in weston_desktop_surface_destroy (surface=0x562c82646650) at ../libweston-desktop/surface.c:158
#4 0x00007f75cd359939 in wl_signal_emit (data=0x562c82647600, signal=0x562c82647608) at /usr/include/wayland-server-core.h:478
#5 weston_surface_destroy (surface=0x562c82647600) at ../libweston/compositor.c:2220
#6 0x00007f75cd313e90 in () at /usr/lib/libwayland-server.so.0
#7 0x00007f75cd313f11 in wl_resource_destroy () at /usr/lib/libwayland-server.so.0
#8 0x00007f75cd045a8d in () at /usr/lib/libffi.so.7
#9 0x00007f75cd04501b in () at /usr/lib/libffi.so.7
#10 0x00007f75cd317f62 in () at /usr/lib/libwayland-server.so.0
#11 0x00007f75cd3142dc in () at /usr/lib/libwayland-server.so.0
#12 0x00007f75cd315faa in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#13 0x00007f75cd3144e7 in wl_display_run () at /usr/lib/libwayland-server.so.0
#14 0x00007f75cd380b9f in wet_main (argc=<optimized out>, argv=<optimized out>) at ../compositor/main.c:3388
#15 0x00007f75cd3b2002 in __libc_start_main () at /usr/lib/libc.so.6
#16 0x0000562c806e205e in _start ()
```
In this function, `output` is `(struct weston_output*)-40` (that is, `0xffffffffffffffd8`) which obviously can’t be dereferenced, hence the crash.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`.