wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2022-12-07T09:41:48Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/700Testing out multiple independent output states2022-12-07T09:41:48ZMarius VladTesting out multiple independent output statesBefore actually writing some tests that do that we first need the following
addressed:
- [ ] expand our ability to independently control outputs, should be taken care of in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/...Before actually writing some tests that do that we first need the following
addressed:
- [ ] expand our ability to independently control outputs, should be taken care of in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1047
- [ ] have the ability to specify multiple outputs, in VKMS, which we use in CI: https://lore.kernel.org/dri-devel/20221202142051.136651-1-marius.vlad@collabora.com/
- [ ] teach CI to make use of multiple outputs, and fix an issue I've found with it: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1066
After all that gets in, we can then create plug-in tests, and address some of the scenarious detailed in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1047#note_1638354.https://gitlab.freedesktop.org/wayland/weston/-/issues/699Weird pointer focus behaviour with `xdg_popup.grab`2022-12-05T12:01:23ZMax IhlenfeldtWeird pointer focus behaviour with `xdg_popup.grab`The `xdg-shell` specification says the following about `xdg_popup.grab`:
> During a popup grab, the client owning the grab will receive pointer and touch events for all their surfaces as normal (similar to an "owner-events" grab in X11 p...The `xdg-shell` specification says the following about `xdg_popup.grab`:
> During a popup grab, the client owning the grab will receive pointer and touch events for all their surfaces as normal (similar to an "owner-events" grab in X11 parlance), while the top most grabbing popup will always have keyboard focus.
However, I observed the following behaviour in Weston 11.0.0 when pressing the left mouse button while over a surface, in response to which an `xdg_popup` is created and its `grab` request is called, and then the mouse is dragged over the popup and released again:
- the pointer focus leaves and then almost immediately re-enters the parent surface
- as soon as the mouse is dragged above the popup, the pointer focus switches to the popup surface
- when the mouse button is released, the appropriate `wl_pointer.button` event is emitted
In my understanding of the specification, I would have expected the following behaviour instead:
- the pointer focus remains with the parent surface (no leaving and re-entering)
- when the mouse button is released, the appropriate `wl_pointer.button` event is emitted
- the pointer focus switches to the popup surfacehttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/119XML file license requirements2023-10-06T22:11:35ZPekka Paalanenppaalanen@gmail.comXML file license requirementsThe wayland-protocols repository `COPYING` file contains the MIT license: https://opensource.org/licenses/MIT
The governance document makes no mention of license of XML files, it only requires open-source implementations and defines wha...The wayland-protocols repository `COPYING` file contains the MIT license: https://opensource.org/licenses/MIT
The governance document makes no mention of license of XML files, it only requires open-source implementations and defines what "open-source" is license-wise.
The XML files vary:
- pointer_gestures_unstable_v1 is missing the license
- text_input_unstable_v3 has some "old" variant
- ext_session_lock_v1 uses ISC license: https://opensource.org/licenses/ISC
- every other XML file uses MIT license
There are new proposals using ISC license.
I don't see much difference between MIT and ISC, but IANAL.
Should wayland-protocols strictly standardize on a single specific license (MIT), or is there a reason to allow variations? What kind of variations should be allowed?https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/118xdg_activation: determine seat for a given token2023-05-18T15:12:01ZHugoxdg_activation: determine seat for a given tokenAn xdg activation token allows activating a surface. However, it's not possible to determine to which seat this token belongs. E.g.: Typically, when a user starts a client via the launcher, an activation token is passed to it. This token...An xdg activation token allows activating a surface. However, it's not possible to determine to which seat this token belongs. E.g.: Typically, when a user starts a client via the launcher, an activation token is passed to it. This token may be used by this client or passed to an existing client. However, neither of these clients can determine which seat initiated the action.
My user case is rendering an layer-shell overlay that should only react to actions from that seat. I can imagine other potential use cases may arise for applications that have actual multi-seat support. For example, a game when launched by a second seat might want to add a player 2 for that seat to an existing instance (or at least prompt to?).
Could a new request be added to `xdg-activation-v1::xdg_activation_v1`? This would take the token as input and somehow yield the corresponding seat's id. Or would an extension protocol be best?https://gitlab.freedesktop.org/wayland/weston/-/issues/696WL_OUTPUT_TRANSFORM refactoring2022-12-21T16:54:51ZDerek ForemanWL_OUTPUT_TRANSFORM refactoringSome follow up work stemming from https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1015#note_1656682
I'll just copy and paste Pekka's comment from there to here:
Refactor weston_output_update_matrix() and move the switch-...Some follow up work stemming from https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1015#note_1656682
I'll just copy and paste Pekka's comment from there to here:
Refactor weston_output_update_matrix() and move the switch-case-ladders handling enum wl_output_transform into matrix.c. Use that helper from weston_output_update_matrix() obviously. Then delete the similar ladders from weston_surface_build_buffer_matrix() and make that use the helper as well with a matrix inversion added.
Then, if we still have more of those ladders open-coded (clients/simple-damage?), migrate those as well.
And make something for all the open-coded "get width/height" simple cases that switch on enum wl_output_transform as well.https://gitlab.freedesktop.org/wayland/wayland/-/issues/338Stride constraints for wl_shm_pool::create_buffer2022-11-24T02:06:54ZM. StoecklStride constraints for wl_shm_pool::create_bufferThe current text for `wl_shm_pool::create_buffer` defines the image stride as follows:
> The stride argument specifies the number of bytes from the beginning of one row to the beginning of the next.
`wl_shm` also has an invalid stride...The current text for `wl_shm_pool::create_buffer` defines the image stride as follows:
> The stride argument specifies the number of bytes from the beginning of one row to the beginning of the next.
`wl_shm` also has an invalid stride error, with name="invalid_stride", summary="invalid size or stride during pool or buffer creation".
However, it is not specified what stride values are invalid. To ensure that applications can rely on the same behavior across compositors, this should be standardized and documented.
In theory, we could allow _any_ stride value, as long as the union of the content bytes of the image lies within the shm pool region. By the definition of the stride quoted above, if the first row of the image starts at address `p`, then the second row of the image starts at `p + stride`. This is well defined even if the stride is zero, negative, or smaller in absolute value than `width * bpp` -- although not necessarily useful.
Some common constraints in practice:
* libwayland-shm requires the stride (in bytes) to be at least the image width (in pixels)
* wlroots/wlr-shm currently requires that the stride to be a multiple of `bpp`, the number of bytes for a pixel
* pixman (and cairo) require that the stride be a multiple of 4.
* libwayland-shm requires that the image row padding also fits in the pool; i.e., `offset+stride*height<pool_size`, which can be more than necessary if, say, `height=1` and `stride > width*bpp`
See also https://gitlab.freedesktop.org/wayland/wayland/-/issues/333 for related issues specifying multi-planar and subsampled formats.https://gitlab.freedesktop.org/wayland/weston/-/issues/694Remove matrix type field2022-12-20T19:02:05ZDerek ForemanRemove matrix type fieldIn !1015 we're replacing this loosely tracked (reversing a rotation can't revert the type field to its pre-rotated value) with matrix inspection. This mostly removes the need to track the type at all, but there are still some places that...In !1015 we're replacing this loosely tracked (reversing a rotation can't revert the type field to its pre-rotated value) with matrix inspection. This mostly removes the need to track the type at all, but there are still some places that use it (specifically `weston_view_update_transform_enable()`.
It should be possible to replace the usage of matrix type there too, and remove matrix type entirely.https://gitlab.freedesktop.org/wayland/weston/-/issues/693Dynamically adapt resolution to monitor ?2022-11-17T11:50:45ZbenintechDynamically adapt resolution to monitor ?I have a 1600x900 laptop, with an external 1920x1080 monitor.
For various reasons I am still running X11, and I use Weston to run Waydroid. It works fine.
Only problem is resolution. With 1920x1080 in `weston.ini`, it looks good on the ...I have a 1600x900 laptop, with an external 1920x1080 monitor.
For various reasons I am still running X11, and I use Weston to run Waydroid. It works fine.
Only problem is resolution. With 1920x1080 in `weston.ini`, it looks good on the external monitor, but is unusable on the built-in monitor. So I used 1600x900, now it looks fine on the built-in monitor, but of course on the external one it doesn't use all the available screen real estate.
Is it possible to dynamically change Weston's resolution when I drag the Weston window from one monitor to the other ?https://gitlab.freedesktop.org/wayland/weston/-/issues/692Can no longer launch Weston on RPI2022-12-08T09:28:20ZgearheadCan no longer launch Weston on RPISometime this summer, weston ceased to launch on my RPi. I am running Arch Linux and am using the vc3 graphics. Weston is launched then a web browser is launched full screen as a 'kiosk' without a keyboard or mouse. The browser then disp...Sometime this summer, weston ceased to launch on my RPi. I am running Arch Linux and am using the vc3 graphics. Weston is launched then a web browser is launched full screen as a 'kiosk' without a keyboard or mouse. The browser then displays a php based 'UI'. To get it to launch as a service, I had to jump through some hoops as no user is logged in and a service runs as root. The service file looks something like this:
```
cat /etc/systemd/system/weston.service
[Unit]
Description=Weston Kiosk Mode
After=network.target
[Service]
Type=notify
#User=http
# cannot run as http, so chown after start
Group=http
RuntimeDirectory=weston
RuntimeDirectoryMode=0700
Environment="XDG_RUNTIME_DIR=/run/weston"
ExecStart=/usr/bin/weston --tty=1 --log=/var/log/runeaudio/weston.log --config=/srv/http/.config/weston.ini --modules=systemd-notify.so
ExecStartPost=/usr/bin/chown -R http:http /run/weston/
ExecStop=/usr/bin/pkill -15 weston
IgnoreSIGPIPE=no
#Restart=always
#RestartSec=1
StandardOutput=journal
StandardError=journal
TimeoutSec=infinity
[Install]
WantedBy=multi-user.target
```
I launch as root, but then chmod the socket to http so I can launch a browser (luakit) as user http after weston starts. When I try this now, I get:
```
# cat /var/log/runeaudio/weston.log
Date: 2022-11-16 CST
[21:46:31.744] weston 11.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 11.0.0
[21:46:31.744] Command line: /usr/bin/weston --tty=1 --log=/var/log/runeaudio/weston.log --config=/srv/http/.config/weston.ini --modules=systemd-notify.so
[21:46:31.744] OS: Linux, 5.15.76-2-rpi-ARCH, #1 SMP Wed Nov 2 06:57:11 MDT 2022, armv7l
[21:46:31.744] Flight recorder: enabled
[21:46:31.745] Using config file '/srv/http/.config/weston.ini'
[21:46:31.761] Output repaint window is 7 ms maximum.
[21:46:31.769] Loading module '/usr/lib/libweston-11/drm-backend.so'
[21:46:31.789] initializing drm backend
[21:46:31.789] Trying libseat launcher...
[21:46:31.789] [libseat/backend/seatd.c:64] Could not connect to socket /run/seatd.sock: No such file or directory
[21:46:31.789] [libseat/libseat.c:76] Backend 'seatd' failed to open seat, skipping
[21:46:31.789] [libseat/libseat.c:76] Backend 'logind' failed to open seat, skipping
[21:46:31.789] [libseat/libseat.c:79] No backend was able to open a seat
[21:46:31.789] libseat: could not open seat
[21:46:31.789] Trying logind launcher...
[21:46:31.790] logind: failed to get session seat
[21:46:31.790] logind: cannot setup systemd-logind helper error: (No data available), using legacy fallback
[21:46:31.790] fatal: your system should either provide the logind D-Bus API, or use seatd.
[21:46:31.790] fatal: failed to create compositor backend
```
I am guessing I need to do something different from before, but am unsure of what that may be. Can anyone here help me figure this out out?https://gitlab.freedesktop.org/wayland/weston/-/issues/691Stop deferring view transform updates2022-11-14T19:38:46ZDerek ForemanStop deferring view transform updatesAs discussed on !1053, deferring these transform updates causes us some discomfort.
As mentioned at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1053#note_1632462 the goal is to remove the dirty flag entirely and minim...As discussed on !1053, deferring these transform updates causes us some discomfort.
As mentioned at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1053#note_1632462 the goal is to remove the dirty flag entirely and minimize the `weston_view_update_transform()` call sites.
The exact reason for these deferrals is not well remembered - perhaps performance due to the fact that a surface can be moved many times between renders. The transform update process performs maths for each of these moves, but also tracks damage. This problem maybe be improved or resolved by #494https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/117Tablet: How to pass the current mode during pad initialization ?2022-11-12T02:44:06ZFabrice SalvaireTablet: How to pass the current mode during pad initialization ?I read https://wayland.app/protocols/tablet-unstable-v2#zwp_tablet_pad_group_v2, but I don't see any explanation how we should send the current mode to a client. I think this information must be part of the pad initialization, else the ...I read https://wayland.app/protocols/tablet-unstable-v2#zwp_tablet_pad_group_v2, but I don't see any explanation how we should send the current mode to a client. I think this information must be part of the pad initialization, else the application cannot know the current state when the tablet is initialized. Also, the message `zwp_tablet_pad_v2::button(0)` is redundant with `zwp_tablet_pad_group_v2::mode_switch()`.https://gitlab.freedesktop.org/wayland/weston/-/issues/689Application with weston.h include fails since it can not find libweston.h inc...2022-11-09T10:13:12ZShehan DeshapriyaApplication with weston.h include fails since it can not find libweston.h include file.I got following error in Ubuntu 20.04 when i build an application which include weston.h
![libweston_include_error](/uploads/3c96251e48dd4ffa3839f7f54b111762/libweston_include_error.PNG)
installed weston version is 8.0.0
As it seems we...I got following error in Ubuntu 20.04 when i build an application which include weston.h
![libweston_include_error](/uploads/3c96251e48dd4ffa3839f7f54b111762/libweston_include_error.PNG)
installed weston version is 8.0.0
As it seems weston.h file can not locate libweston.h.
Does any one has an idea on this ? Really appreciate you time.https://gitlab.freedesktop.org/wayland/weston/-/issues/688feature : could weston provide a method of unminimized windows2022-11-08T07:34:32Zhaorui wangfeature : could weston provide a method of unminimized windowsIn `weston/desktop-shell/shell.c` contain method `void set_minimized(struct weston_surface *surface)`. I read about its implementation and find it is possible to implement `set_unminimized` method.
Could `weston` provide the interface o...In `weston/desktop-shell/shell.c` contain method `void set_minimized(struct weston_surface *surface)`. I read about its implementation and find it is possible to implement `set_unminimized` method.
Could `weston` provide the interface of it? I know this interface is strange for a display server (a client can minimized itself but it can't unminimized itself), but it may useful in some embedded scenarios.
(up to now, win + Tab is the only way to unminimized)https://gitlab.freedesktop.org/wayland/weston/-/issues/686Bug: OpenGL viewport of a client is clamped by the left edge of the output2022-11-07T14:46:29ZMark Bolhuismark@bolhuis.devBug: OpenGL viewport of a client is clamped by the left edge of the output###### Steps to reproduce:
1. Launch weston-simple-egl
2. Drag the window over the left edge of the display so that a region of the window is in negative coordinates
###### Expected Result:
The triangle should remain centered on the win...###### Steps to reproduce:
1. Launch weston-simple-egl
2. Drag the window over the left edge of the display so that a region of the window is in negative coordinates
###### Expected Result:
The triangle should remain centered on the window as it crosses the output edge.
###### Observed Result:
The triangle moves with respect to the window up until the window crosses the edge, then the triangle remains fixed horizontally with respect the the edge.
###### Notes:
- I did not observe the issue on KDE, Sway, or with the v3d driver on a raspberry pi.
- Dragging the window past the right or bottom edge behaves as expected, which would suggest that it's something to do with negative coordinates. Weston prevents dragging a window into negative y coordinates but I'm guessing the same would happend there.
- WAYLAND_DEBUG doesn't show anything meaningful.
- Running weston as a nested session doesn't show the bug.
###### Picture
The built-in weston screen shot tool couldn't actually capture the bug, taking the screenshot fixes it for the one frame that the shot it taken, and then immediately reverts back. The client window physically flickers as well.
<details>
![20221106_174009](/uploads/abd78d97d3e1494f1719f2a69a62d1bb/20221106_174009.png)
</details>
###### System:
- linux 6.0.7-arch1-1
- weston 11.0.0
- mesa 22.2.1
- nvidia 520.56.06https://gitlab.freedesktop.org/wayland/wayland/-/issues/336scanner: check local enums2022-11-07T07:10:56ZSimon Sercontact@emersion.frscanner: check local enumsIf the enum isn't namespaced (doesn't contain `.`), check that it exists.
Ref https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/174If the enum isn't namespaced (doesn't contain `.`), check that it exists.
Ref https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/174https://gitlab.freedesktop.org/wayland/wayland/-/issues/335Privileged wayland sockets2022-11-08T15:45:52ZJulian OrthPrivileged wayland socketsWe already have several protocols (e.g. xwayland-only protocols) that must not be exposed to unprivileged clients. I expect this number to rise in the future with at least ext-screencopy and ext-layer-shell becoming privileged protocols....We already have several protocols (e.g. xwayland-only protocols) that must not be exposed to unprivileged clients. I expect this number to rise in the future with at least ext-screencopy and ext-layer-shell becoming privileged protocols.
One way to separate unprivileged and privileged sockets is via the file system. Sandboxes only expose selected sockets in $XDG_RUNTIME_DIR to sandboxed applications. A wayland compositor can therefore create a socket called wayland-N.privileged which exposes even privileged protocols.
If such a schema was standardized, then clients that make use of such privileged protocols (e.g. screenshot tools, application launchers) could try to connect to the privileged socket. This would allow users to launch them without having to jump through compositor-specific hoops to launch them with elevated privileges.https://gitlab.freedesktop.org/wayland/wayland/-/issues/334Introduce a proper role object for cursor surfaces2022-11-15T11:36:15ZSimon Sercontact@emersion.frIntroduce a proper role object for cursor surfacesRight now cursors are a bit special: they're set via `wl_pointer.set_cursor` and take a raw `wl_surface`. This is inconsistent with all other roles. This makes it difficult to update the offset, or to update the offset and the image atom...Right now cursors are a bit special: they're set via `wl_pointer.set_cursor` and take a raw `wl_surface`. This is inconsistent with all other roles. This makes it difficult to update the offset, or to update the offset and the image atomically. Updating the offset is possible via `wl_surface.offset`, but it's annoying because it's relative to the previous offset.
Additionally, cursors are not extensible. There's no easy way to refer to an existing cursor. There could be a new protocol to set a cursor by an image name, but with the status quo it'd need to hand-roll an input type (pointer/tablet/etc) enum.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/116Transparent fullscreen surfaces2024-03-23T22:30:09ZXaver HuglTransparent fullscreen surfaces`xdg_toplevel.set_fullscreen` says that
```
If the fullscreened surface is not opaque, the compositor must make
sure that other screen content not part of the same surface tree (made
up of subsurfaces, popups or similarly coupled surface...`xdg_toplevel.set_fullscreen` says that
```
If the fullscreened surface is not opaque, the compositor must make
sure that other screen content not part of the same surface tree (made
up of subsurfaces, popups or similarly coupled surfaces) are not
visible below the fullscreened surface
```
While that is useful for some applications, for use cases like transparent+blurred fullscreen application launchers or terminal emulators, it takes away functionality that users expect. KWin currently doesn't enforce opaqueness in part to not break that expectation, but that of course has the potential to break clients relying on that functionality.
The most straight-forward way to handle this would probably be to add a `set_transparent_fullscreen` request (plus the corresponding capability and state) that allows for (partially) transparent surfaces.https://gitlab.freedesktop.org/wayland/wayland/-/issues/333Define semantics of `wl_shm` with tiled or multi-plane formats2022-11-24T09:54:01ZDemi Marie Obenourdemiobenour@gmail.comDefine semantics of `wl_shm` with tiled or multi-plane formatsThe semantics of `wl_shm` with tiled or multi-plane formats are not clear. In particular, I am not aware of any document specifying how to handle sizes that are not a multiple of the subsampling quantum.
Edit:
- As per <https://gitlab...The semantics of `wl_shm` with tiled or multi-plane formats are not clear. In particular, I am not aware of any document specifying how to handle sizes that are not a multiple of the subsampling quantum.
Edit:
- As per <https://gitlab.freedesktop.org/wayland/wayland/-/issues/333#note_1619508>, tiled formats are _never_ valid.
- Is the same true of formats that require a non-linear modifier?https://gitlab.freedesktop.org/wayland/wayland/-/issues/332WAYLAND_DEBUG logging doesn't include arrays' contents2022-11-02T12:21:43ZDmitry BatrakWAYLAND_DEBUG logging doesn't include arrays' contentsCurrently, only array size is logged by the protocol logger. For completeness, it would be good to include the contents of arrays. As the structure of the contents isn't enforced by the protocol, it can be logged as a sequence of byte va...Currently, only array size is logged by the protocol logger. For completeness, it would be good to include the contents of arrays. As the structure of the contents isn't enforced by the protocol, it can be logged as a sequence of byte values.
I can submit a merge request, solving this issue, if the idea is acceptable.