wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2018-06-30T09:00:03Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/44ICCCM: mime-type guidelines for data_source2018-06-30T09:00:03ZBugzilla Migration UserICCCM: mime-type guidelines for data_source## Submitted by Darxus XXX `@darxus`
Assigned to **Wayland bug list**
**[Link to original bug (#48989)](https://bugs.freedesktop.org/show_bug.cgi?id=48989)**
## Description
mime-type guidelines for data_source (ie, both dnd and se...## Submitted by Darxus XXX `@darxus`
Assigned to **Wayland bug list**
**[Link to original bug (#48989)](https://bugs.freedesktop.org/show_bug.cgi?id=48989)**
## Description
mime-type guidelines for data_source (ie, both dnd and selection): recommended types for text or images, types that a clipboard manager must support, mime-types must be listed in preferred order
### Blocking
* [Bug 91948](https://bugs.freedesktop.org/show_bug.cgi?id=91948)https://gitlab.freedesktop.org/wayland/wayland/-/issues/23Add support for "scrolling while DND" on DND protocol2018-06-30T09:05:39ZBugzilla Migration UserAdd support for "scrolling while DND" on DND protocol## Submitted by Nelson Benitez
Assigned to **Wayland bug list**
**[Link to original bug (#63874)](https://bugs.freedesktop.org/show_bug.cgi?id=63874)**
## Description
Hi, I take the chance that Wayland DND protocol is in its early...## Submitted by Nelson Benitez
Assigned to **Wayland bug list**
**[Link to original bug (#63874)](https://bugs.freedesktop.org/show_bug.cgi?id=63874)**
## Description
Hi, I take the chance that Wayland DND protocol is in its early stages to bring attention to a cool feature that was recently added to XDND[1] spec but never got to be implemented in GTK+, that is, to being able to scroll the target while DND by using mousewheel.
Basically we need support for the source widget to receive scroll events and transmit them to the target widget so the destination widget can scroll accordingly.
Some example usescase to get an idea:
- Drag some text in gedit and then go to nautilus and scroll to reach some folder where to drop it.
- Drag some file in a nautilus pane/window and go to another pane/window and scroll to reach a folder where to drop it.
[1] XDND spec added support for scrolling target in June 17, 2009 see http://www.newplanetsoftware.com/xdnd/#ChangeLoghttps://gitlab.freedesktop.org/wayland/wayland/-/issues/45Backwards compatibility testing2018-06-30T09:10:17ZBugzilla Migration UserBackwards compatibility testing## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#86110)](https://bugs.freedesktop.org/show_bug.cgi?id=86110)**
## Description
To ensure the continued backwards-compatibility of the Wayland ...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#86110)](https://bugs.freedesktop.org/show_bug.cgi?id=86110)**
## Description
To ensure the continued backwards-compatibility of the Wayland protocol and libwayland-server,client ABI, we should have some automated testing in place. I very much doubt any developer ever tests mixed versions of different components in purpose.
The components in play:
- Wayland (libwayland-server, libwayland-client, protocols)
- Weston
- an autonomous test app to be written, that excercises as much as possible given the versions available
We would like to test building Weston and app against one version of wayland, and run them against another version. This produces a test matrix on Wayland build version vs. Wayland runtime version.
Only official release tags are the tested versions. Alpha and beta releases should be included if resources allow. In addition, the master version of Wayland and Weston should be included, so we can catch breakage before releases. The rolling tests could run, say, weekly or more often if resources allow.
Weston very often requires the contemporary version of wayland, which is fine, and produces expected build failures. These should be found by testing rather than pre-encoding the assumption. Once a test is confirmed to legitimately fail, it can be marked as known-to-not-work.
We need some way to limit the combinatorial explosion, because both Weston and the app maybe built or ran against different versions of wayland. It is also useless to re-run tests with the exact same setup as before (unless the test app is updated).
The essential idea is, that we would get an automated test bot, that ensures that we do not break the backwards-compatibility of wayland.
There exists
http://upstream.rosalinux.ru/versions/wayland.html
but I think doesn't cover the Wayland-specifics, like different code generation between versions of wayland and how generated code gets built into compositor and app binaries.
### Blocking
* [Bug 83980](https://bugs.freedesktop.org/show_bug.cgi?id=83980)https://gitlab.freedesktop.org/wayland/wayland/-/issues/42Consider whether wl_data_offer::accept should really require a MIME type2018-06-30T09:22:35ZBugzilla Migration UserConsider whether wl_data_offer::accept should really require a MIME type## Submitted by Michael Catanzaro
Assigned to **Wayland bug list**
**[Link to original bug (#91950)](https://bugs.freedesktop.org/show_bug.cgi?id=91950)**
## Description
I have a Wayland client that would like to send wl_data_offe...## Submitted by Michael Catanzaro
Assigned to **Wayland bug list**
**[Link to original bug (#91950)](https://bugs.freedesktop.org/show_bug.cgi?id=91950)**
## Description
I have a Wayland client that would like to send wl_data_offer::accept requests when acting as the drag destination, to indicate if drag data would be accepted for the current location of the pointer. However, my client is unable to guarantee which MIME type it will eventually choose to receive data for. It therefore picks the first MIME type it could ever possibly use, and passes that MIME type to wl_data_offer::accept, even if it will eventually decide not to use that MIME type. This enhances the user experience during a DnD session by encouraging the drag source to display a cursor image that indicates the drag will be accepted, but some clients might choose a non-ideal drag image based on the potentially-misleading MIME type my client has accepted.
It would be nice if there was a way to indicate that some MIME type would be accepted for the current pointer location, without committing to any particular MIME type. Passing NULL for the mime_type parameter would be ideal for this, except that is a reject message.
Version: 1.5.0
### Blocking
* [Bug 91948](https://bugs.freedesktop.org/show_bug.cgi?id=91948)https://gitlab.freedesktop.org/wayland/wayland/-/issues/26Naming of input devices in Wayland2018-06-30T09:32:35ZBugzilla Migration UserNaming of input devices in Wayland## Submitted by Jehan Pagès `@jehan`
Assigned to **Wayland bug list**
**[Link to original bug (#103979)](https://bugs.freedesktop.org/show_bug.cgi?id=103979)**
## Description
Created attachment 135815
Naming of devices under X.
W...## Submitted by Jehan Pagès `@jehan`
Assigned to **Wayland bug list**
**[Link to original bug (#103979)](https://bugs.freedesktop.org/show_bug.cgi?id=103979)**
## Description
Created attachment 135815
Naming of devices under X.
With X, input devices in GIMP have a quite human-understandable name.
Like "Wacom MobileStudio Pro 13 Pen stylus".
With Wayland, in GIMP, this becomes "xwayland-stylus:13".
The name became generic, and not really made for human.
Do we have some code to change in GIMP to get a human-targetted name for devices when it runs under Wayland?
**Attachment 135815**, "Naming of devices under X.":
![Screenshot_from_2017-11-29_22-26-41](/uploads/9f4f36daf3d1b3af17fa9d72fb3b8c92/Screenshot_from_2017-11-29_22-26-41.png)Peter HuttererPeter Huttererhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/39Support NetBSD2018-06-30T20:01:43ZBugzilla Migration UserSupport NetBSD## Submitted by lol..@..or.com
Assigned to **Wayland bug list**
**[Link to original bug (#62055)](https://bugs.freedesktop.org/show_bug.cgi?id=62055)**
## Description
Created attachment 76214
Wayland build log (without modifying w...## Submitted by lol..@..or.com
Assigned to **Wayland bug list**
**[Link to original bug (#62055)](https://bugs.freedesktop.org/show_bug.cgi?id=62055)**
## Description
Created attachment 76214
Wayland build log (without modifying wayland-os.c)
Needs sys/epoll.h, which seems a Linuxism. When changed to use just poll.h, the build continues and further fails with:
Making all in src
CC wayland-os.lo
wayland-os.c: In function 'wl_os_epoll_create_cloexec':
wayland-os.c:145:2: warning: implicit declaration of function 'epoll_create'
CCLD libwayland-util.la
CCLD wayland-scanner
/usr/pkg/bin/bmake all-am
CC wayland-protocol.lo
CC wayland-server.lo
wayland-server.c:78:15: error: field 'ucred' has incomplete type
wayland-server.c: In function 'wl_client_create':
wayland-server.c:350:33: error: 'SO_PEERCRED' undeclared (first use in this function)
wayland-server.c:350:33: note: each undeclared identifier is reported only once for each function it appears in
*** Error code 1
**Attachment 76214**, "Wayland build log (without modifying wayland-os.c)":
[b.txt](/uploads/e369ac02e8312ebb56b6b8a69f53862a/b.txt)
Version: 1.0.5
### Depends on
* [Bug 91799](https://bugs.freedesktop.org/show_bug.cgi?id=91799)https://gitlab.freedesktop.org/wayland/wayland/-/issues/25zwp_confined_pointer_v1.unconfined vs. wl_pointer.leave ordering is undefined2018-07-02T05:48:50ZBugzilla Migration Userzwp_confined_pointer_v1.unconfined vs. wl_pointer.leave ordering is undefined## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#106704)](https://bugs.freedesktop.org/show_bug.cgi?id=106704)**
## Description
The specification text on zwp_confined_pointer_v1 is not clea...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#106704)](https://bugs.freedesktop.org/show_bug.cgi?id=106704)**
## Description
The specification text on zwp_confined_pointer_v1 is not clear whether a specific ordering between the unconfined and wl_pointer.leave events should be guaranteed. On the other hand, it does guarantee that the confined event can only arrive while in pointer focus, so the ordering between confined and wl_pointer.enter is clearly specified.
I propose to require that also the unconfined event can only be sent while having pointer focus.
According to https://patchwork.freedesktop.org/patch/221802/ GNOME and Weston currently implement the opposite behaviours.https://gitlab.freedesktop.org/wayland/wayland/-/issues/64Publish HTML versions of Wayland protocols2018-11-04T22:53:27ZDaniel Stonedaniel@fooishbar.orgPublish HTML versions of Wayland protocolsWe should publish HTML reference versions of the Wayland protocols, and publish them on https://wayland.freedesktop.org.We should publish HTML reference versions of the Wayland protocols, and publish them on https://wayland.freedesktop.org.https://gitlab.freedesktop.org/wayland/wayland/-/issues/27Document the new_id wire signature generation rules2018-12-19T11:05:52ZBugzilla Migration UserDocument the new_id wire signature generation rules## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83478)](https://bugs.freedesktop.org/show_bug.cgi?id=83478)**
## Description
Document how the wire signature is generated from the XML descr...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83478)](https://bugs.freedesktop.org/show_bug.cgi?id=83478)**
## Description
Document how the wire signature is generated from the XML description, especially how new_id arguments are handled differently when the interface is given in the XML vs. not. The not case leads to three arguments, not one.
While at it, one might document everything about the wire format generation... like how opcodes get assigned.
### Blocking
* [Bug 83429](https://bugs.freedesktop.org/show_bug.cgi?id=83429)https://gitlab.freedesktop.org/wayland/wayland/-/issues/69wl_fixed_* not in API docs2019-01-31T09:10:34ZJessewl_fixed_* not in API docsI'm writing a Wayland client and found that the conversion methods for the `fixed` data type are missing from the [Client](https://wayland.freedesktop.org/docs/html/apb.html) and [Server](https://wayland.freedesktop.org/docs/html/apc.htm...I'm writing a Wayland client and found that the conversion methods for the `fixed` data type are missing from the [Client](https://wayland.freedesktop.org/docs/html/apb.html) and [Server](https://wayland.freedesktop.org/docs/html/apc.html) API pages.https://gitlab.freedesktop.org/wayland/wayland/-/issues/82Client + server headers fail with -Wredundant-decls2019-03-12T09:26:46ZSimon Sercontact@emersion.frClient + server headers fail with -Wredundant-declsWhen compositors include both `wayland-client-protocol.h` and `wayland-server-protocol.h` (e.g. for their Wayland backend), GCC 8.3.1 with `-Werror=redundant-decls` fails to build.
Not sure how to fix this.
Full log, found via packagin...When compositors include both `wayland-client-protocol.h` and `wayland-server-protocol.h` (e.g. for their Wayland backend), GCC 8.3.1 with `-Werror=redundant-decls` fails to build.
Not sure how to fix this.
Full log, found via packaging wlroots on OpenSUSE: [49002676.log](/uploads/bc408df37c67657e4fe1f123e48169dd/49002676.log)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/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/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/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/wayland/-/issues/131Document the event loop API freeze2020-01-13T09:25:45ZSimon Sercontact@emersion.frDocument the event loop API freezeIt seems there's interest in freezing the libwayland-server event loop API, preventing any new feature from being added. We should document that.
See https://gitlab.freedesktop.org/wayland/wayland/merge_requests/45#note_372901It seems there's interest in freezing the libwayland-server event loop API, preventing any new feature from being added. We should document that.
See https://gitlab.freedesktop.org/wayland/wayland/merge_requests/45#note_372901https://gitlab.freedesktop.org/wayland/wayland/-/issues/138Expand event loop post-dispatch-check tests2020-01-20T09:09:45ZM. StoecklExpand event loop post-dispatch-check testsSee https://gitlab.freedesktop.org/wayland/wayland/merge_requests/45#note_387678 . It could be helpful to verify that the dispatch functions for timer, idle, and signal event sources still behave correctly when marked for re-checking. St...See https://gitlab.freedesktop.org/wayland/wayland/merge_requests/45#note_387678 . It could be helpful to verify that the dispatch functions for timer, idle, and signal event sources still behave correctly when marked for re-checking. Still more edge cases might be found by having the callbacks for the source modify other sources.
(At the moment, it looks like event sources added by`wl_event_loop_add_idle` don't have a dispatch handler, and are added to the [`loop->idle_list`](https://gitlab.freedesktop.org/wayland/wayland/blob/55d044810ca32ae24499d2c6aee6084d7e31d576/src/event-loop.c#L434) list on construction, so trying to call `wl_event_source_check` will probably cause a crash.)
Of course, it is possible that nobody actually uses `wl_event_source_check` with anything other than file descriptor event sources; in that case, it may suffice to adjust the documentation and then close this issue.https://gitlab.freedesktop.org/wayland/wayland/-/issues/135Timer may dispatch even after being disabled (not removed) or reconfigured2020-02-12T15:19:20ZPekka Paalanenppaalanen@gmail.comTimer may dispatch even after being disabled (not removed) or reconfiguredThe following discussion from !45 should be addressed:
```c
// Removing a timer always prevents its callback from
// being called ...
wl_event_source_remove(context->timers[1]);
// ... but disarming or rescheduling a timer does ...The following discussion from !45 should be addressed:
```c
// Removing a timer always prevents its callback from
// being called ...
wl_event_source_remove(context->timers[1]);
// ... but disarming or rescheduling a timer does not,
// (in the case where the modified timers had already expired
// as of when `wl_event_loop_dispatch` was called.)
```
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/wayland/merge_requests/45#note_385397):
> This is quite interesting behavior btw. We don't seem to document that anywhere in the API. It should be, because I think it is surprising. I read the old timer and event loop code, and indeed this seems to be how it works. To me it is a design mistake, but I'm not sure we can change it anymore.
>
> I think if a timer is disabled instead of removed, I would still intuitively expect it to not call the callback anymore. It is kind of a race, yes, but if there are two event handlers competing, one of them being this timer, and the other fires first, the other one might change state such that calling the timer handler does not work anymore. I suppose it is not unusual to want to keep the timer around disabled until it is needed again.
>
> Roughly the same applies when a timer is updated to fire later than originally due to some other event. It doesn't matter which event actually happened first, it is the dispatch ordering that matters. Again, the handler for another event might reconfigure the timer, and I wouldn't expect the timer to dispatch according to its old state afterwards.
>
> I have a feeling we would need to review all timer uses in Weston and check that they are safe against this... quirk.
The very least we need the documentation to underline this behaviour, if we deem that we cannot change this behaviour.
- Is this behaviour desired?
- If not, can we change it?https://gitlab.freedesktop.org/wayland/wayland/-/issues/146Please make tests installable2020-02-24T09:57:37ZAlexander KanavinPlease make tests installablePlease see here for rationale and implementation hints:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
Particularly, the Yocto project is cross compiling wayland (like everything else), and thus has no ability to run tests...Please see here for rationale and implementation hints:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
Particularly, the Yocto project is cross compiling wayland (like everything else), and thus has no ability to run tests at build time. Running them on the target device on the other hand would be extremely useful.https://gitlab.freedesktop.org/wayland/wayland/-/issues/58'What is Wayland?' documentation2020-05-07T07:55:29ZDaniel Stonedaniel@fooishbar.org'What is Wayland?' documentationSimilar to freedesktop/freedesktop#76 - we are pretty terrible at explaining what Wayland is and isn't, and getting all kinds of people started with it:
* the 'what is Wayland' people, who need a coherent explanation of the ideas behin...Similar to freedesktop/freedesktop#76 - we are pretty terrible at explaining what Wayland is and isn't, and getting all kinds of people started with it:
* the 'what is Wayland' people, who need a coherent explanation of the ideas behind it and how it relates to the world around it (e.g. the rest of the graphics/input stack)
* people who want to 'use Wayland' and need to be redirected to the appropriate page for GNOME/KDE/Enlightenment/Weston/sway/...
* people who want to 'help Wayland' and need to be redirected to the above list of appropriate projects
* people who want to 'work on Wayland' and need to be redirected to the above, or our laundry list of generic-Wayland work to be done, or 'how do I new protocol' with best practices
We should collate all of this into a coherent jumping-off page and make that our website. Radical, I know.
Whilst looking around, I found this [Wayland client guide](https://bugaevc.gitbooks.io/writing-wayland-clients/) which is surprisingly comprehensive and well written. We should integrate that somehow.
Please use the comments to contribute any resources you've come across that we should integrate, or if you would like to help out (e.g. I know nothing about doing actual web pages).