wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2023-01-23T21:04:11Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/87Support setting scroll speed2023-01-23T21:04:11ZClaudius EllselSupport setting scroll speedI try to get issues set up in order to get setting of scroll speed implemented for Linux systems. The "meta" issue for this is https://gitlab.gnome.org/GNOME/gnome-control-center/issues/379 so feel free to join with your opinion, also no...I try to get issues set up in order to get setting of scroll speed implemented for Linux systems. The "meta" issue for this is https://gitlab.gnome.org/GNOME/gnome-control-center/issues/379 so feel free to join with your opinion, also note https://gitlab.gnome.org/GNOME/gnome-control-center/issues/379#note_485183 where some implementation for Wayland has been suggested. Hopefully you can add some input to that.https://gitlab.freedesktop.org/wayland/weston/-/issues/89Add autohide option for panels2018-06-30T11:15:56ZBugzilla Migration UserAdd autohide option for panels## Submitted by Bug Report
Assigned to **Wayland bug list**
**[Link to original bug (#100272)](https://bugs.freedesktop.org/show_bug.cgi?id=100272)**
## Description
Please add a autohide option or a function call for panels that a...## Submitted by Bug Report
Assigned to **Wayland bug list**
**[Link to original bug (#100272)](https://bugs.freedesktop.org/show_bug.cgi?id=100272)**
## Description
Please add a autohide option or a function call for panels that autohide. Maximized windows can then cover the whole screen without patching weston.https://gitlab.freedesktop.org/wayland/wayland/-/issues/89Add a way to deprecate part of a protocol2024-03-12T13:22:58ZSimon Sercontact@emersion.frAdd a way to deprecate part of a protocolSometimes it's desirable to deprecate part of a protocol as they evolve:
- `wl_shell` in `wayland` is deprecated with a plaintext note
- `format` in `wp_linux_dmabuf_unstable_v1` will probably get deprecated too
However there's no way ...Sometimes it's desirable to deprecate part of a protocol as they evolve:
- `wl_shell` in `wayland` is deprecated with a plaintext note
- `format` in `wp_linux_dmabuf_unstable_v1` will probably get deprecated too
However there's no way to explicitly mark an interface, event or request as deprecated via an XML attribute. Having such an attribute could be useful for both code generators and documentation generators.https://gitlab.freedesktop.org/wayland/wayland/-/issues/90Undefined references when building with files generated from wayland-protocols2019-04-24T16:30:57ZorbeaUndefined references when building with files generated from wayland-protocolsI am trying to solve undefined references with RetroArch when built with CXX_BUILD=1 which uses -xc++.
```
/usr/bin/ld: obj-unix/release/gfx/drivers_context/wayland_ctx.o: in function `registry_handle_global(void*, wl_registry*, unsigned...I am trying to solve undefined references with RetroArch when built with CXX_BUILD=1 which uses -xc++.
```
/usr/bin/ld: obj-unix/release/gfx/drivers_context/wayland_ctx.o: in function `registry_handle_global(void*, wl_registry*, unsigned int, char const*, unsigned int)':
wayland_ctx.c:(.text+0x1e52): undefined reference to `zxdg_decoration_manager_v1_interface'
/usr/bin/ld: wayland_ctx.c:(.text+0x1f6b): undefined reference to `xdg_wm_base_interface'
/usr/bin/ld: wayland_ctx.c:(.text+0x1fa3): undefined reference to `zxdg_shell_v6_interface'
/usr/bin/ld: wayland_ctx.c:(.text+0x2053): undefined reference to `zwp_idle_inhibit_manager_v1_interface'
collect2: error: ld returned 1 exit status
make: *** [Makefile:196: retroarch] Error 1
```
These issues occur with files generated using wayland-scanner and wayland-protocols.
For example we use xdg_wm_base_interface here.
https://github.com/libretro/RetroArch/blob/dcd5cb2602e7d3d28308a46838a2c23ce4fc39dc/gfx/drivers_context/wayland_ctx.c#L932
And include the generated xdg-shell.h in the same file.
https://github.com/libretro/RetroArch/blob/dcd5cb2602e7d3d28308a46838a2c23ce4fc39dc/gfx/drivers_context/wayland_ctx.c#L58
Inside xdg-shell.h:
```
extern const struct wl_interface xdg_wm_base_interface;
```
And xdg-shell.c
```
WL_PRIVATE const struct wl_interface xdg_wm_base_interface = {
"xdg_wm_base", 2,
4, xdg_wm_base_requests,
1, xdg_wm_base_events,
};
```
I think this explains the problem I am seeing.
> In C++, const objects at global scope are by default also static, i.e., they are not visible outside the source file. To fix that, add extern to each of the definitions.
Source: https://stackoverflow.com/questions/34185401/extern-variable-undefined/34185641#34185641
I have tried adding extern in xdg-shell.c where appropriate and I also tried including xdg-shell.h inside xdg-shell.c. Both approaches helped, but I as the files are auto-generated I am not sure how to solve this or where.
Any suggestions?https://gitlab.freedesktop.org/wayland/weston/-/issues/92Chrome/Chromium's maximize button doesn't work2018-06-30T11:16:51ZBugzilla Migration UserChrome/Chromium's maximize button doesn't work## Submitted by Ilia Bozhinov
Assigned to **Wayland bug list**
**[Link to original bug (#101036)](https://bugs.freedesktop.org/show_bug.cgi?id=101036)**
## Description
I've tested this on weston and on my own toy WM, so I guess th...## Submitted by Ilia Bozhinov
Assigned to **Wayland bug list**
**[Link to original bug (#101036)](https://bugs.freedesktop.org/show_bug.cgi?id=101036)**
## Description
I've tested this on weston and on my own toy WM, so I guess this is a bug in libweston. When I open chrome or chromium, they are not decorated by the WM(which is fine). However, their "custom" buttons for maximization don't work. In other Xwayland views, the maximize button on the frames drawn by weston are working fine. So my guess is that the maximize request from Xwayland isn't implemented in XWM.https://gitlab.freedesktop.org/wayland/weston/-/issues/93Weston window frames for Xwayland views cause performance problems2018-06-30T11:17:02ZBugzilla Migration UserWeston window frames for Xwayland views cause performance problems## Submitted by Ilia Bozhinov
Assigned to **Wayland bug list**
**[Link to original bug (#101162)](https://bugs.freedesktop.org/show_bug.cgi?id=101162)**
## Description
To reproduce the issue(at least on my machine this is the beha...## Submitted by Ilia Bozhinov
Assigned to **Wayland bug list**
**[Link to original bug (#101162)](https://bugs.freedesktop.org/show_bug.cgi?id=101162)**
## Description
To reproduce the issue(at least on my machine this is the behavior, I'm using weston 2.0.0):
Open chromium/chrome, load a youtube video, leave the pointer above it, after a few seconds it will "hide". At this moment the FPS of the video drops considerably(or probably this is the compositor's FPS) and the video lags. When I move the cursor again so it becomes visible the problem goes away until it gets hidden again. This doesn't happen with fullscreen video, maybe the black surfaces that weston uses or something similar is the reason behind this, as on my WM it happens with fullscreen windows and I don't use black surfaces.https://gitlab.freedesktop.org/wayland/weston/-/issues/94Drag surfaces coordinates don't follow window position2018-06-30T11:17:18ZBugzilla Migration UserDrag surfaces coordinates don't follow window position## Submitted by Ilia Bozhinov
Assigned to **Wayland bug list**
**[Link to original bug (#101477)](https://bugs.freedesktop.org/show_bug.cgi?id=101477)**
## Description
For example, when I open chrome and move the window in the rig...## Submitted by Ilia Bozhinov
Assigned to **Wayland bug list**
**[Link to original bug (#101477)](https://bugs.freedesktop.org/show_bug.cgi?id=101477)**
## Description
For example, when I open chrome and move the window in the right half of the screen for example, I try to select and drag something. The drag "surface" still appears on the left(outside of the window), this can probably be fixed by setting its position relative to the main view.https://gitlab.freedesktop.org/wayland/weston/-/issues/95Use HiDPI cursors in clients where applicable2018-06-30T11:17:38ZBugzilla Migration UserUse HiDPI cursors in clients where applicable## Submitted by Link Mauve
Assigned to **Wayland bug list**
**[Link to original bug (#101609)](https://bugs.freedesktop.org/show_bug.cgi?id=101609)**
## Description
Clients currently always use a scale=1 cursor, which looks worse ...## Submitted by Link Mauve
Assigned to **Wayland bug list**
**[Link to original bug (#101609)](https://bugs.freedesktop.org/show_bug.cgi?id=101609)**
## Description
Clients currently always use a scale=1 cursor, which looks worse than it could on HiDPI outputs.
### Depends on
* [Bug 101608](https://bugs.freedesktop.org/show_bug.cgi?id=101608)https://gitlab.freedesktop.org/wayland/weston/-/issues/96subcomposited surfaces with content outside shell surface area lack proper da...2018-06-30T11:17:49ZBugzilla Migration Usersubcomposited surfaces with content outside shell surface area lack proper damage on some occasions## Submitted by k.p..@..il.com
Assigned to **Wayland bug list**
**[Link to original bug (#101922)](https://bugs.freedesktop.org/show_bug.cgi?id=101922)**
## Description
Created attachment 132984
Window decoration in subsurface tha...## Submitted by k.p..@..il.com
Assigned to **Wayland bug list**
**[Link to original bug (#101922)](https://bugs.freedesktop.org/show_bug.cgi?id=101922)**
## Description
Created attachment 132984
Window decoration in subsurface that stays visible after minimizing window
If subsurfaces have parts that are visible outside the area of their parent shell surface, these parts will not get proper damage and thus have improper contents on some occasions.
Confirmed are:
* minimizing windows
* switching between windows
but there may be more.
To test, move some subsurface outside the window area in clients/subsurfaces.c, e.g. add some arbitrary x/y offset to a widget_set_allocation call in resize_handler.
**Attachment 132984**, "Window decoration in subsurface that stays visible after minimizing window":
![Bildschirmfoto_von_Â_2017-07-26_12-24-39Â_](/uploads/f0ace1c6c462038391ac75b491ab6ede/Bildschirmfoto_von_Â_2017-07-26_12-24-39Â_.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/98Wire format header does not describe number of file descriptors per message2021-10-07T13:54:15ZM. StoecklWire format header does not describe number of file descriptors per messageThe Wayland [wire format header](https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format) provides a field for the message length in bytes, but does not provide a field for the number of file descriptors that is con...The Wayland [wire format header](https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format) provides a field for the message length in bytes, but does not provide a field for the number of file descriptors that is consumed.
Because clients must fully parse the incoming protocol to match the file descriptors that are provided with corresponding messages, an [inventive solution](https://gitlab.freedesktop.org/wayland/wayland/commit/4485ed1f59cb8695f3ab690e074abd7e79a27640) in libwayland-client is needed to ensure that clients can parse even messages sent to objects that have been deleted by the client, but not yet acknowledged as deleted by the server. If the wire format would describe the number of file descriptors used per message, then libwayland-client could more easily close all file descriptors corresponding to unknown messages.
(I'm adding this issue because it's something to keep in mind in case the wire format ever has some other reason for a change; one may as well solve two problems at once then. It's also an issue for anyone writing their own code to manipulate the Wayland protocol. As noted in the comments of ["The Wayland Zombie Apocalypse is Near"](
https://web.archive.org/web/20180320133849/blogs.s-osg.org/wayland-zombie-apocalypse-near/
), wire format and core semantic changes should definitely *not* be made without consensus or in a way that can break existing code.)
It's possible to update the wire format in a (mostly) backwards compatible fashion. Since practically no messages use >4096 bytes, and no interfaces have >1024 methods, the second word of the wire format has bits to spare to count a small number of fds per message. [One approach, albeit not recommended.](https://gitlab.freedesktop.org/snippets/615)https://gitlab.freedesktop.org/wayland/wayland/-/issues/100Add a wl_display.delete_id request for server-created objects2019-07-08T08:32:48ZSimon Sercontact@emersion.frAdd a wl_display.delete_id request for server-created objectsSee https://gitlab.freedesktop.org/wayland/wayland/merge_requests/23#note_187478See https://gitlab.freedesktop.org/wayland/wayland/merge_requests/23#note_187478https://gitlab.freedesktop.org/wayland/wayland/-/issues/101Add \since tags to all post 1.0 API additions2021-03-22T15:59:28ZJonas ÅdahlAdd \since tags to all post 1.0 API additionsWe've added various API after the initial release, but to know what version they were introduced in, one have to rely on git paleontology to figure it out. What would be better is to go and add the `\since` tag to the corresponding funct...We've added various API after the initial release, but to know what version they were introduced in, one have to rely on git paleontology to figure it out. What would be better is to go and add the `\since` tag to the corresponding function documentation.https://gitlab.freedesktop.org/wayland/wayland/-/issues/104wayland-scanner: easier enum validation2024-01-27T13:19:23ZSimon Sercontact@emersion.frwayland-scanner: easier enum validationOne pain point when implementing a protocol interface is that libwayland doesn't check that values with an `enum` hint are valid enum members. I guess it's not possible to make libwayland check this anymore because it would break ABI. Ma...One pain point when implementing a protocol interface is that libwayland doesn't check that values with an `enum` hint are valid enum members. I guess it's not possible to make libwayland check this anymore because it would break ABI. Maybe it would be possible to generate helpers in wayland-scanner, e.g. something like an `<enum>_check` function?https://gitlab.freedesktop.org/wayland/wayland/-/issues/106Versioned wl_registry2019-07-22T22:43:41ZSimon Sercontact@emersion.frVersioned wl_registryDisclaimer: this is just a wild idea, don't take it too seriously. I have no idea what the implications of this would be. Also, some might call it a hack (it is).
While talking about https://gitlab.freedesktop.org/wayland/wayland/issues...Disclaimer: this is just a wild idea, don't take it too seriously. I have no idea what the implications of this would be. Also, some might call it a hack (it is).
While talking about https://gitlab.freedesktop.org/wayland/wayland/issues/10, kennylevinsen has suggested a way to make `wl_registry` versioned. We could keep object ID 1 as `wl_display` v1 (which creates a `wl_registry` v1), but also advertise the `wl_registry` as a regular global, possibly with a higher version. This way, clients can bind to it and get extra functionality.
The annoying thing is that clients that are willing to use a higher `wl_registry` version will need to bind twice (and will receive twice the list of globals).https://gitlab.freedesktop.org/wayland/weston/-/issues/109Option to disable mouse acceleration2018-06-30T11:22:03ZBugzilla Migration UserOption to disable mouse acceleration## Submitted by Vincent Grande
Assigned to **Wayland bug list**
**[Link to original bug (#106484)](https://bugs.freedesktop.org/show_bug.cgi?id=106484)**
## Description
It seems the only way to currently disable mouse acceleration...## Submitted by Vincent Grande
Assigned to **Wayland bug list**
**[Link to original bug (#106484)](https://bugs.freedesktop.org/show_bug.cgi?id=106484)**
## Description
It seems the only way to currently disable mouse acceleration under Wayland, is with sway and gnome. Is it possible for Weston to incorporate mouse acceleration settings so we can disable mouse acceleration under Weston?https://gitlab.freedesktop.org/wayland/wayland/-/issues/109cursor: Avoid loading all images at once2021-08-30T17:07:42ZLink Mauvecursor: Avoid loading all images at onceWhen the cursor theme has a lot of data, for instance if it contains many animation frames, or if the user loads a HiDPI theme, all images are loaded in memory at load time even if the application seldom uses them.
It can waste quite a ...When the cursor theme has a lot of data, for instance if it contains many animation frames, or if the user loads a HiDPI theme, all images are loaded in memory at load time even if the application seldom uses them.
It can waste quite a lot of memory (about 4 MiB loading the default Adwaita at size 64 in addition to size 32) and use CPU time on load (28.18% according to perf, vs. 9.80% with only size 32 loaded), delaying the actual start of the application.
This kind of lazy loading would require a refactoring from the Xcursor code path, to keep the `XcursorFile` around during the entire lifetime of the `wl_cursor_theme` and expose `_XcursorReadImage()` as a public API in xcursor.h for integration in `wl_cursor_theme_get_cursor()`.https://gitlab.freedesktop.org/wayland/weston/-/issues/120Remove possible_crtcs and possible_clones workarounds2018-06-27T14:07:54ZPekka Paalanenppaalanen@gmail.comRemove possible_crtcs and possible_clones workaroundsThis is about the function `drm_output_pick_crtc()`:
https://gitlab.freedesktop.org/wayland/weston/blob/78a42116ae92f93a01539a785ce95cc478189608/libweston/compositor-drm.c#L4809
It works around `possible_crtcs` and `possible_clones` bei...This is about the function `drm_output_pick_crtc()`:
https://gitlab.freedesktop.org/wayland/weston/blob/78a42116ae92f93a01539a785ce95cc478189608/libweston/compositor-drm.c#L4809
It works around `possible_crtcs` and `possible_clones` being unreliable. If the kernel gets fixed to report realistic values, remove the workarounds.
However, if Weston gains support for atomic modesetting's `TEST_ONLY` commits and iterates over possible configurations to find one that works, then it might not be necessary to use the values, if not for optimizing out definitely invalid configurations.https://gitlab.freedesktop.org/wayland/weston/-/issues/122Test suite: Run weston/wayland under weston/headless2019-11-21T11:16:32ZPekka Paalanenppaalanen@gmail.comTest suite: Run weston/wayland under weston/headlessModify the test suite to run weston/wayland under weston/headless for a second run of the screenshot tests. The nested weston will have Mesa fall back to software GL, so we get the GL-renderer tested. It should also work in all CI runner...Modify the test suite to run weston/wayland under weston/headless for a second run of the screenshot tests. The nested weston will have Mesa fall back to software GL, so we get the GL-renderer tested. It should also work in all CI runners without requiring drivers like hw GL does.
This depends on #121 because modifying the autotools build is painful.https://gitlab.freedesktop.org/wayland/wayland/-/issues/122Automatic code coverage testing in MRs2019-11-28T09:34:58ZPekka Paalanenppaalanen@gmail.comAutomatic code coverage testing in MRsOnce #80 is done, rig up the CI to use https://diff-cover.readthedocs.io to check that all new code will be covered by tests.
The code coverage results in cobertura.xml can be produced by Meson with gcovr, see wayland/weston!307 for ins...Once #80 is done, rig up the CI to use https://diff-cover.readthedocs.io to check that all new code will be covered by tests.
The code coverage results in cobertura.xml can be produced by Meson with gcovr, see wayland/weston!307 for instance.
That's easier said than done though, because we cannot require 100% coverage, there are always error paths etc. that are not triggered in tests. How to integrate with Gitlab is also a good question.https://gitlab.freedesktop.org/wayland/weston/-/issues/123weston should turn off unplugged pipes2018-07-09T16:34:53ZSean Paulseanpaul@chromium.orgweston should turn off unplugged pipes**Steps to repro:**
- Launch weston with a removable display
- Unplug display
**Expected behavior:**
- turns off the crtc/encoder/connector to save power
**Actual behavior:**
- all planes are disabled, but the crtc/encoder/connector ar...**Steps to repro:**
- Launch weston with a removable display
- Unplug display
**Expected behavior:**
- turns off the crtc/encoder/connector to save power
**Actual behavior:**
- all planes are disabled, but the crtc/encoder/connector are left on
- device will continue to scan out black pixels to nowhere
**drm logs on unplug (debug=0x16):**
From Dragonboard 410c:
```
[ +8.063165] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:29:HDMI-A-1]
[ +0.000885] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:29:HDMI-A-1] disconnected
[ +0.000385] [drm:msm_framebuffer_destroy] destroy: FB ID: 0 (000000006599c6c8)
[ +0.000068] [drm:drm_atomic_state_init] Allocated atomic state 00000000fb118117
[ +0.000019] [drm:drm_atomic_get_plane_state] Added [PLANE:30:plane-0] 000000002bef9e83 state to 00000000fb118117
[ +0.000014] [drm:drm_atomic_get_crtc_state] Added [CRTC:39:crtc-0] 00000000acbd6758 state to 00000000fb118117
[ +0.000006] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state 000000002bef9e83
[ +0.000007] [drm:drm_atomic_set_crtc_for_plane] Link plane state 000000002bef9e83 to [NOCRTC]
[ +0.000007] [drm:drm_atomic_check_only] checking 00000000fb118117
[ +0.000012] [drm:mdp5_plane_atomic_check] plane-0: check (1 -> 1)
[ +0.000012] [drm:drm_atomic_get_private_obj_state] Added new private object 00000000bb38088b state 00000000d3aa6148 to 00000000fb118117
[ +0.000006] [drm:mdp5_pipe_release] DMA0: release from plane plane-0
[ +0.000005] [drm:mdp5_pipe_release] DMA0: free SMP blocks
[ +0.000007] [drm:mdp5_crtc_atomic_check] crtc-0: check
[ +0.000006] [drm:drm_atomic_commit] committing 00000000fb118117
[ +0.000025] [drm:mdp5_crtc_atomic_begin] crtc-0: begin
[ +0.000006] [drm:mdp5_plane_atomic_update] plane-0: update
[ +0.000006] [drm:mdp5_crtc_atomic_flush] crtc-0: event: 0000000076b12383
[ +0.000005] [drm:blend_setup] Border Color is enabled
[ +0.000012] [drm:mdp5_ctl_blend] lm0: blend config = 0x03000000. ext_cfg = 0x00000000
[ +0.000006] [drm:crtc_flush.isra.2] crtc-0: flush=00000040
[ +0.000011] [drm:msm_enable_vblank] dev=0000000012eadf3b, crtc=0
[ +0.002368] [drm:mdp5_crtc_vblank_irq] crtc-0: send event: 0000000076b12383
[ +0.002451] [drm:mdp5_smp_complete_commit] release DMA0
[ +0.014527] [drm:mdp5_plane_cleanup_fb] plane-0: cleanup: FB[74]
[ +0.000028] [drm:drm_atomic_state_default_clear] Clearing atomic state 00000000fb118117
[ +0.000025] [drm:__drm_atomic_state_free] Freeing atomic state 00000000fb118117
[ +0.000023] [drm:msm_framebuffer_destroy] destroy: FB ID: 0 (00000000ff21dd31)
[ +0.016301] [drm:msm_disable_vblank] dev=0000000012eadf3b, crtc=0
```Daniel Stonedaniel@fooishbar.orgDaniel Stonedaniel@fooishbar.org