weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2021-11-11T15:18:53Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/563Weston X11 crash when image is copied to clipboard2021-11-11T15:18:53Zrichkiz devopserWeston X11 crash when image is copied to clipboardWindows 11 standard installation.
WSL Ubuntu 20.04.
Running any GUI app.
Copying any image data to clipboard, taking screenshot to clipboard -> X11 crashes.
X11 keeps crashing while image data still in the clipboard memory. Copying any a...Windows 11 standard installation.
WSL Ubuntu 20.04.
Running any GUI app.
Copying any image data to clipboard, taking screenshot to clipboard -> X11 crashes.
X11 keeps crashing while image data still in the clipboard memory. Copying any amount of text allows GUI apps to start again.
Pardon me if this report does not confirm to standards.
I am not the developer, just wanted to document is as clearly as my competence allows.
Attaching weston.log and dmesg.log
[weston.log](/uploads/3ca9497afe465c6936f02aad4f9be857/weston.log)
[dmesg.log](/uploads/b69932d415dee2644ef2f2db24ee1476/dmesg.log)https://gitlab.freedesktop.org/wayland/weston/-/issues/564"static_assert" macro in helpers.h2021-11-16T20:40:04Zca lee"static_assert" macro in helpers.hIn shared\helpers.h, it defines a "static_assert" macro, which is different with macro in c++. When I develop a client in c++, and include \<map\> after "helpers.h", it will report an weird error shows:
```
uses_allocator.h:93: error: ma...In shared\helpers.h, it defines a "static_assert" macro, which is different with macro in c++. When I develop a client in c++, and include \<map\> after "helpers.h", it will report an weird error shows:
```
uses_allocator.h:93: error: macro "static_assert" passed 8 arguments, but takes just 2
" an allocator must be possible if uses_allocator is true");
```
source code is:
```cpp
static_assert(__or_<
is_constructible<_Tp, allocator_arg_t, _Alloc, _Args...>,
is_constructible<_Tp, _Args..., _Alloc>>::value, "construction with"
" an allocator must be possible if uses_allocator is true");
```
It looks like preprocessor can't distinguish comma in template or in args. What I can do now is leaving "helpers.h" behind every other headers. So I wanna know if there is other way to work around this problem, or we can change the macro in "helpers.h"?https://gitlab.freedesktop.org/wayland/weston/-/issues/565Super+R screen capture should be an option2021-11-19T12:03:55ZTestMode1Super+R screen capture should be an optionThere should be an option to disable below in meson_options.txt as it is very easy to accidentally hit Super+R leading to OOM, slowdowns or hangs.
```c
weston_compositor_add_key_binding(ec, KEY_R, MODIFIER_SUPER,
recorder_binding...There should be an option to disable below in meson_options.txt as it is very easy to accidentally hit Super+R leading to OOM, slowdowns or hangs.
```c
weston_compositor_add_key_binding(ec, KEY_R, MODIFIER_SUPER,
recorder_binding, shooter);
```https://gitlab.freedesktop.org/wayland/weston/-/issues/177Better errors for keymap compilation failure2021-11-25T09:42:00ZbitofhopeBetter errors for keymap compilation failure```
$ weston --version
weston 5.0.0
$ cat .config/weston.ini
[core]
xwayland=true
[libinput]
enable_tap=true
[shell]
allow-zap=true
[keyboard]
keymap_layout=fi,sv,us
vt-switching=true
```
## What I do
Open a terminal, attempt to ty...```
$ weston --version
weston 5.0.0
$ cat .config/weston.ini
[core]
xwayland=true
[libinput]
enable_tap=true
[shell]
allow-zap=true
[keyboard]
keymap_layout=fi,sv,us
vt-switching=true
```
## What I do
Open a terminal, attempt to type in it
## What I expect to happen
Text appears in the terminal
## What happens instead
Weston core dumps. Sometimes the console indicates a segmentation fault.
## Steps to reproduce
* Set `.config/weston.ini` to match above
* Run weston from a pseudo-TTY
* Open Weston Terminal
* Try to type
## Workaround
Commenting out keymap_layout fixes the crashing but forces US layout.https://gitlab.freedesktop.org/wayland/weston/-/issues/555kiosk-shell/kiosk-shell.c 410:Does it need to process the other situations?2021-11-27T10:15:52ZHankWong-guangdongkiosk-shell/kiosk-shell.c 410:Does it need to process the other situations?There is a "if...else if" case in kiosk-shell.c 406 line, the code is:
if (keyboard &&
wl_list_empty(&shseat->keyboard_focus_listener.link)) {
wl_signal_add(&keyboard->focus_signal,
&shseat->keyboard_focus_listener);
} ...There is a "if...else if" case in kiosk-shell.c 406 line, the code is:
if (keyboard &&
wl_list_empty(&shseat->keyboard_focus_listener.link)) {
wl_signal_add(&keyboard->focus_signal,
&shseat->keyboard_focus_listener);
} else if (!keyboard) {
wl_list_remove(&shseat->keyboard_focus_listener.link);
wl_list_init(&shseat->keyboard_focus_listener.link);
}
I want to ask if it need an else case after the "else if" to process the other situations?https://gitlab.freedesktop.org/wayland/weston/-/issues/567How to enable the screenshooter in kiosk-shell2021-11-27T10:18:32ZMihai OlteanuHow to enable the screenshooter in kiosk-shellI've recently switched from desktop-shell to kiosk-shell and noticed the keybindings, and especially the screenshot feature, don't work anymore.
Looking at the source code, [kiosk-shell.c](https://gitlab.freedesktop.org/wayland/weston/-...I've recently switched from desktop-shell to kiosk-shell and noticed the keybindings, and especially the screenshot feature, don't work anymore.
Looking at the source code, [kiosk-shell.c](https://gitlab.freedesktop.org/wayland/weston/-/blob/main/kiosk-shell/kiosk-shell.c#L998) is indeed missing most of the keybindings that are available in [shell.c](https://gitlab.freedesktop.org/wayland/weston/-/blob/main/desktop-shell/shell.c#L4961), so this is to be expected.
But both the kiosk and the desktop call the [screenshooter_create](https://gitlab.freedesktop.org/wayland/weston/-/blob/main/compositor/weston-screenshooter.c#L180) as part of their init process ([here](https://gitlab.freedesktop.org/wayland/weston/-/blob/main/kiosk-shell/kiosk-shell.c#L1174) for kiosk, and [here](https://gitlab.freedesktop.org/wayland/weston/-/blob/main/desktop-shell/shell.c#L5173) for desktop), which contains the needed keybindings for screenshoting and recording. Just reading the code would lead one to believe these features are thus available in kiosk, as well, but trying them out leaves me with no screenshot actually taken. I can successfully take a screenshot in desktop-shell, though.
I've also tried [weston-binder](https://github.com/tarvi-verro/weston-binder) in kiosk and defined a key to call the /bin/weston-screenshooter directly and redirecting the stderr to a tmp file. I get a `display doesn't support screenshooter` error. Weston was started with "--debug" in this case, since without it I get a `error 0: screenshooter failed: permission denied. Debug protocol must be enabled` from /bin/weston-screenshooter.
I would still like to retain the possibility of taking screenshots in kiosk-shell, as well. Can you guide me on how would one achieve that, either with a keybinding or with calling weston-screenshooter directly, an external tool or with patching the source code and rebuilding?https://gitlab.freedesktop.org/wayland/weston/-/issues/550How to temporarily take control of DRM from Weston?2021-12-02T09:27:59ZMichal ArtazovHow to temporarily take control of DRM from Weston?I'm running Weston with DRM backend on Raspberry Pi 4. Is there a way to temporarily suspend it so that I can run another program that will take control of DRM and render something, then end and give control back to Weston?
I looked thr...I'm running Weston with DRM backend on Raspberry Pi 4. Is there a way to temporarily suspend it so that I can run another program that will take control of DRM and render something, then end and give control back to Weston?
I looked through libdrm header files and found functions `drmSetMaster` and `drmDropMaster` but when I try to call `drmSetMaster` in my program, it fails. I think Weston would have to call `drmDropMaster` first or something like that.
More details about my project: I have an embedded solution running Chromium in Weston with DRM backend on Raspberry Pi 4. I also need to ocasionaly play HEVC videos and I have implemented a player for that but the problem is, I can't run the player as a Wayland client because the decoder returns dmabufs with a weird pixel format (SAND) which is not supported by Mesa yet, so I can't import it to OpenGL. The only way right now seems to be to pass dmabufs straight to DRM but I can't do that while Weston is running. I don't want to stop Weston every time so I'm looking for a solution that would simply "borrow" the control of the screen from Weston, then give it back.https://gitlab.freedesktop.org/wayland/weston/-/issues/415Segfault in desktop-shell when focused client shuts down abruptly2021-12-14T18:01:55ZAlexandros FrantzisSegfault in desktop-shell when focused client shuts down abruptlyUnder certain conditions, when a focused client is shut down abruptly weston/desktop-shell crashes.
This is the result of a signal listener being removed from within the invocation of the previous listener in the listener list. wl_signa...Under certain conditions, when a focused client is shut down abruptly weston/desktop-shell crashes.
This is the result of a signal listener being removed from within the invocation of the previous listener in the listener list. wl_signal_emit uses wl_list_for_each_safe() but this is safe only for removal of the currently invoked listener.
In this particular case, when emitting the destroy_signal for a surface, the `focus_state->surface_destroy_listener` is notified first and down the line calls weston_keyboard_set_focus() which removes the `seat->saved_kbd_focus_listener`. The saved_kbd_focus_listener happens to be the next listener in the surface's destroy_signal listener list, wreaking havoc on the listener iteration.
To reproduce:
0. Start weston with desktop-shell with X11 backend
1. Start a weston client A (e.g., weston-terminal)
2. Start a second weston client B from an X11 terminal (e.g., another weston-terminal)
3. Click on client B's window
4. Ctrl-C client B
Result:
```
Thread 1 "weston" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d76615 in wl_signal_emit (signal=0x555555c8adc8, data=0x555555c8adc0)
at /usr/include/wayland-server-core.h:477
477 wl_list_for_each_safe(l, next, &signal->listener_list, link)
(gdb) bt
#0 0x00007ffff7d76615 in wl_signal_emit (signal=0x555555c8adc8, data=0x555555c8adc0)
at /usr/include/wayland-server-core.h:477
#1 0x00007ffff7d7b76d in weston_surface_destroy (surface=0x555555c8adc0)
at ../libweston/compositor.c:2220
#2 0x00007fffeefee60e in fade_out_done_idle_cb (data=0x555555591440) at ../desktop-shell/shell.c:2335
#3 0x00007ffff7d4731b in wl_event_loop_dispatch_idle (loop=loop@entry=0x555555562f00)
at ../src/event-loop.c:969
#4 0x00007ffff7d47422 in wl_event_loop_dispatch (loop=0x555555562f00, timeout=timeout@entry=-1)
at ../src/event-loop.c:1032
#5 0x00007ffff7d459e5 in wl_display_run (display=0x555555568fd0) at ../src/wayland-server.c:1351
#6 0x00007ffff7fbd47f in wet_main (argc=1, argv=0x7fffffffd938) at ../compositor/main.c:3398
#7 0x0000555555555155 in main (argc=6, argv=0x7fffffffd938) at ../compositor/executable.c:33
```https://gitlab.freedesktop.org/wayland/weston/-/issues/574Implement primary selection protocol2021-12-23T17:57:45ZMax IhlenfeldtImplement primary selection protocolWeston currently does not implement the (admittedly unstable) primary selection protocol. It would be nice if it did :)Weston currently does not implement the (admittedly unstable) primary selection protocol. It would be nice if it did :)https://gitlab.freedesktop.org/wayland/weston/-/issues/48Weston testing meta-bug2021-12-27T06:56:42ZBugzilla Migration UserWeston testing meta-bug## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83980)](https://bugs.freedesktop.org/show_bug.cgi?id=83980)**
## Description
All enhancement bugs for Weston's test suite should be marked b...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83980)](https://bugs.freedesktop.org/show_bug.cgi?id=83980)**
## Description
All enhancement bugs for Weston's test suite should be marked blocking this bug.
### Depends on
* [Bug 83984](https://bugs.freedesktop.org/show_bug.cgi?id=83984)
* [Bug 83985](https://bugs.freedesktop.org/show_bug.cgi?id=83985)
* [Bug 83986](https://bugs.freedesktop.org/show_bug.cgi?id=83986)
* [Bug 83989](https://bugs.freedesktop.org/show_bug.cgi?id=83989)
* [Bug 83990](https://bugs.freedesktop.org/show_bug.cgi?id=83990)
* [Bug 83981](https://bugs.freedesktop.org/show_bug.cgi?id=83981)
* [Bug 83987](https://bugs.freedesktop.org/show_bug.cgi?id=83987)
* [Bug 83994](https://bugs.freedesktop.org/show_bug.cgi?id=83994)
* [Bug 86110](https://bugs.freedesktop.org/show_bug.cgi?id=86110)https://gitlab.freedesktop.org/wayland/weston/-/issues/575ibus-pinyin not work when run wps in weston with xwayland2021-12-27T07:09:01ZVollyBirdibus-pinyin not work when run wps in weston with xwaylandHi,guys
I compile and run the weston-10 on Ubuntu 20.04. My weston run commond is:
`weston --xwayland --logger-scopes=log,x11-backend,desktop-shell,xwm-wm-x11`
I have alse installed [wps](https://www.wps.com/office/linux/) on my Ubun...Hi,guys
I compile and run the weston-10 on Ubuntu 20.04. My weston run commond is:
`weston --xwayland --logger-scopes=log,x11-backend,desktop-shell,xwm-wm-x11`
I have alse installed [wps](https://www.wps.com/office/linux/) on my Ubuntu.
I run wps through weston shell commond, but I can't use ibus-pinyin in wps.
![image](/uploads/1e2c1c500d07de590330663e324ae348/image.png)
Due to some format problem, I attach the weston log and weston.ini file, please check.
[weston.ini](/uploads/b80531c331cb5cdb21b18c241ed1c9c7/weston.ini)
[weston.log](/uploads/c6d56b209abde2f1af36a6bccab31983/weston.log)
If I run wps directly(without weston), ibus-pinyin woks fine.
If I run wps through weston shell commond and replace ibus to fcitx5, fcitx5 works fine too.
So, I want to find how to solve this problem, please help me. Thanks a lot!https://gitlab.freedesktop.org/wayland/weston/-/issues/509Finalizing a layer with views still on it2022-01-07T20:08:59ZLeandro RibeiroFinalizing a layer with views still on itIf you run Weston using the desktop-shell (I think that doesn't matter in which backend), start Weston terminal (for instance) and then press Ctrl+LAlt+backspace to quit, we hit this BUG:
```c
WL_EXPORT void weston_layer_fini(struct wes...If you run Weston using the desktop-shell (I think that doesn't matter in which backend), start Weston terminal (for instance) and then press Ctrl+LAlt+backspace to quit, we hit this BUG:
```c
WL_EXPORT void weston_layer_fini(struct weston_layer *layer)
{
wl_list_remove(&layer->link);
if (!wl_list_empty(&layer->view_list.link))
weston_log("BUG: finalizing a layer with views still on it.\n");
wl_list_remove(&layer->view_list.link);
}
```
I still didn't have the time to investigate.https://gitlab.freedesktop.org/wayland/weston/-/issues/576Required order when emitting globals2022-01-07T20:16:13ZJulian OrthRequired order when emitting globalsWhen globals are emitted from a registry, is there a required order in which they are emitted? I could not find anything like that in the spec but the weston example clients segfault when a wl_seat is emitted before a wl_compositor.When globals are emitted from a registry, is there a required order in which they are emitted? I could not find anything like that in the spec but the weston example clients segfault when a wl_seat is emitted before a wl_compositor.https://gitlab.freedesktop.org/wayland/weston/-/issues/87Please add option to adjust output RGB range2022-01-08T17:59:37ZBugzilla Migration UserPlease add option to adjust output RGB range## Submitted by N. W.
Assigned to **Wayland bug list**
**[Link to original bug (#99406)](https://bugs.freedesktop.org/show_bug.cgi?id=99406)**
## Description
Hi,
when using X, it's possible to adjust the Intel driver's Broadcast ...## Submitted by N. W.
Assigned to **Wayland bug list**
**[Link to original bug (#99406)](https://bugs.freedesktop.org/show_bug.cgi?id=99406)**
## Description
Hi,
when using X, it's possible to adjust the Intel driver's Broadcast RGB setting via xrandr like this:
xrandr --output OUTPUT --set "Broadcast RGB" "Full"
or:
xrandr --output OUTPUT --set "Broadcast RGB" "Limited 16:235"
or:
xrandr --output OUTPUT --set "Broadcast RGB" "Automatic"
Unfortunately the Intel driver now sets this to "Automatic" by default and "Automatic" doesn't really set it properly all of the time:
https://bugzilla.kernel.org/show_bug.cgi?id=94921
amdgpu and radeon apparently are also planned to get options to to adjust the RGB range / color space, see:
https://bugs.freedesktop.org/show_bug.cgi?id=83226
When asking on #wayland on the freenode IRC channel, I was told that such an option would need to be added to the corresponding Wayland compositor and that I should submit a feature request for the corresponding Wayland compositor.
So, could you pease add an option to adjust the RGB range?
Regards
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=99040https://gitlab.freedesktop.org/wayland/weston/-/issues/572"require-input" config parameter ignored when using backend-drm2022-01-10T16:32:24ZKenneth Sloat"require-input" config parameter ignored when using backend-drmIn cases where the DRM system is used, a flag was introduced in e57d8ae818c39fc434fcf3bfc97274195296c8d6 called "continue-without-input" that allows the system to run without an input device attached. This can be passed as a arg to westo...In cases where the DRM system is used, a flag was introduced in e57d8ae818c39fc434fcf3bfc97274195296c8d6 called "continue-without-input" that allows the system to run without an input device attached. This can be passed as a arg to weston. There already exists a current and older method to achieve the same via the configuration file using a parameter called "require-input."
The introduction of "continue-without-input" seems to render "require-input" moot since it takes precedence. It seems the former was introduced for test purposes, perhaps without realizing the impact this could have where users are relying on the latter config file param. I do not know the history here, so I wanted to open this for discussion.
I found this in version 9.0 when upgrading from 5.0 running on an embedded Linux system with a DRM back-end.https://gitlab.freedesktop.org/wayland/weston/-/issues/557Provide a comparison of libweston and wlroots2022-01-10T20:05:59ZDemi Marie Obenourdemiobenour@gmail.comProvide a comparison of libweston and wlrootslibweston seems to be little-used in desktops nowadays, with most compositors using wlroots or implementing everything themselves. It would be nice to have a comparison of libweston and wlroots, so that compositor authors could determin...libweston seems to be little-used in desktops nowadays, with most compositors using wlroots or implementing everything themselves. It would be nice to have a comparison of libweston and wlroots, so that compositor authors could determine which is more suitable for them.https://gitlab.freedesktop.org/wayland/weston/-/issues/558Missing escape sequences in weston-terminal2022-01-10T20:27:49ZDemi Marie Obenourdemiobenour@gmail.comMissing escape sequences in weston-terminalweston-terminal is missing support for some escape sequences used by Vim.weston-terminal is missing support for some escape sequences used by Vim.https://gitlab.freedesktop.org/wayland/weston/-/issues/559Missing mouse support in weston-terminal2022-01-10T20:27:51ZDemi Marie Obenourdemiobenour@gmail.comMissing mouse support in weston-terminalweston-terminal doesn’t have mouse support.weston-terminal doesn’t have mouse support.https://gitlab.freedesktop.org/wayland/weston/-/issues/566Demote weston-terminal to a demo or remove it2022-01-10T20:59:57ZSimon Sercontact@emersion.frDemote weston-terminal to a demo or remove itI'm not sure it's a good idea for the Weston project to maintain a fully-fledged terminal emulator. I think it would be better to keep it as a demo instead. That way users can lower their expectations in terms of support and feature requ...I'm not sure it's a good idea for the Weston project to maintain a fully-fledged terminal emulator. I think it would be better to keep it as a demo instead. That way users can lower their expectations in terms of support and feature requests.
Potential action items:
- Clearly label it as a demo in the README
- Move it from the Meson option `tools` to `demo-clients`
- Don't install it by defaulthttps://gitlab.freedesktop.org/wayland/weston/-/issues/424Weston 8.0.0 does not appear to clean up overlay planes on switch-out2022-01-11T18:45:14ZRobert MaderWeston 8.0.0 does not appear to clean up overlay planes on switch-outSwitching between Mutter and Weston on different ttys, sessions from different users, under certain circumstances subsurfaces from Weston stick around in Mutter (which does not clear overlay planes itself so far).
Relevant IRC log:
```
...Switching between Mutter and Weston on different ttys, sessions from different users, under certain circumstances subsurfaces from Weston stick around in Mutter (which does not clear overlay planes itself so far).
Relevant IRC log:
```
robert.mader: yeah, me too. Fun fact: just opened obs in weston on tty3 and the right subsurface now stays on screen
even when I switch back to tt2 - like cross user, cross wayland session content leaking :/
I suppose a mesa gdm bug or so?
...
robert.mader: oh wait, weston supports hardware planes, right? That must be it. So most likely a weston bug....or a kernel bug?
robert.mader: I suppose it must be a kernel / intel driver bug
...
MrCooper: sounds like a bug in what's on tty2
or weston
but at the end of the day each KMS user has to make ensure the KMS state they want, can't rely on the previous one cleaning up after themselves
pq: MrCooper, indeed. OTOH, Weston definitely has code that calls drmModeSetPlane() to turn all overlays off on switch-away.
and cursor planes
would need to sprinkle a little more drm_debug() calls in weston and look at the drm debug log to see if weston actually leaves planes around
...
robert.mader: MrCooper Concerning KMS: on tty2 was my GS session - then mutter does not ensure it cleares all hardware planes IIUC?
MrCooper: sounds like it; or, since weston (which version are you using?) is supposed to disable overlay planes, there could be a kernel bug
robert.mader: Currently on weston-8.0.0-4.fc32
pq: I suppose with legacy KMS it is uncommon to go and reset the overlay planes you don't use on switch-in...
```
Mutter issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/1383
cc: @pq, @daenzer, @jadahl