wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2023-04-02T02:10:20Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/230Switch asserts to wl_abort2023-04-02T02:10:20ZDerek ForemanSwitch asserts to wl_abortassert()s can be compiled away by #defining NDEBUG. Some build systems do this.
libwayland's assertions are inexpensive, and they protect against errors that have no recovery paths. If compiled with NDEBUG, libwayland could allow both b...assert()s can be compiled away by #defining NDEBUG. Some build systems do this.
libwayland's assertions are inexpensive, and they protect against errors that have no recovery paths. If compiled with NDEBUG, libwayland could allow both broken library code and buggy compositor code to silently do very wrong things in difficult to debug ways.
We should really be using our wl_abort() function instead of assert(), as it can't be compiled away for non-debug builds.https://gitlab.freedesktop.org/wayland/wayland/-/issues/225libwayland-cursor documentation needs improvement2021-08-04T14:06:43ZDerek Foremanlibwayland-cursor documentation needs improvementWhile there's been some work to improve it (!49), libwayland-cursor's documentation doesn't really meet the standard to which we hold the rest of the project.While there's been some work to improve it (!49), libwayland-cursor's documentation doesn't really meet the standard to which we hold the rest of the project.https://gitlab.freedesktop.org/wayland/wayland/-/issues/222Upstream wlroots Utility Functions2022-08-13T13:59:10ZRoman GilgUpstream wlroots Utility Functionswlroots provides some helper functions, which are so universal, they could be provided by libwayland directly instead:
* [array_remove_at](https://github.com/swaywm/wlroots/blob/2fa47c1837ef54642ce646bc14ef2b8ef1f37e8d/util/array.c#L51-...wlroots provides some helper functions, which are so universal, they could be provided by libwayland directly instead:
* [array_remove_at](https://github.com/swaywm/wlroots/blob/2fa47c1837ef54642ce646bc14ef2b8ef1f37e8d/util/array.c#L51-L57);
* [wlr_global_destroy_safe](https://github.com/swaywm/wlroots/blob/2fa47c1837ef54642ce646bc14ef2b8ef1f37e8d/util/global.c#L17-L43);
* [wlr_signal_emit_safe](https://github.com/swaywm/wlroots/blob/2fa47c1837ef54642ce646bc14ef2b8ef1f37e8d/util/signal.c#L7-L34), see also https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/457#note_830178 and note that wl_priv_signal_emit is "slightly less safe".https://gitlab.freedesktop.org/wayland/wayland/-/issues/134Add more version checks to wayland-scanner2021-07-01T14:19:28ZSimon Sercontact@emersion.frAdd more version checks to wayland-scannerWe could check more things related to versioning in wayland-scanner. For instance, this is invalid:
```xml
<request name="my_request" since="2">
<arg name="my_arg" type="uint" enum="my_enum"/>
</request>
<enum name="my_enum" since="3...We could check more things related to versioning in wayland-scanner. For instance, this is invalid:
```xml
<request name="my_request" since="2">
<arg name="my_arg" type="uint" enum="my_enum"/>
</request>
<enum name="my_enum" since="3">
…
</enum>
```https://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/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/48Set up CI to generate and publish the Wayland doc2020-10-16T10:57:53ZPekka Paalanenppaalanen@gmail.comSet up CI to generate and publish the Wayland docSet up Gitlab CI to generate and publish the Wayland docs automatically at https://wayland.freedesktop.org/docs/html/ .
Right now, one would have to generate the doc manually, copy and commit it to https://gitlab.freedesktop.org/wayland...Set up Gitlab CI to generate and publish the Wayland docs automatically at https://wayland.freedesktop.org/docs/html/ .
Right now, one would have to generate the doc manually, copy and commit it to https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org and push.https://gitlab.freedesktop.org/wayland/wayland/-/issues/19Tests do not fail, if XDG_RUNTIME_DIR is unset2022-03-20T20:14:58ZBugzilla Migration UserTests do not fail, if XDG_RUNTIME_DIR is unset## Submitted by isa..@..ol.com
Assigned to **Wayland bug list**
**[Link to original bug (#103475)](https://bugs.freedesktop.org/show_bug.cgi?id=103475)**
## Description
If XDG_RUNTIME_DIR is set (ex. "/tmp/xdg-$USER"), but the dir...## Submitted by isa..@..ol.com
Assigned to **Wayland bug list**
**[Link to original bug (#103475)](https://bugs.freedesktop.org/show_bug.cgi?id=103475)**
## Description
If XDG_RUNTIME_DIR is set (ex. "/tmp/xdg-$USER"), but the directory is not present, most tests from "make check" fail. This happens, if one tries to build wayland and run the tests on a freshly rebooted system. Creating the directory manually enables the tests to complete.
Version: 1.4.0https://gitlab.freedesktop.org/wayland/wayland/-/issues/9Make deprecation warnings work2022-03-20T20:14:57ZBugzilla Migration UserMake deprecation warnings work## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7592)](https://phabricator.freedesktop.org/T7592)**
## Description
It turns out that all the deprecation warnings in e.g. `wayland...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7592)](https://phabricator.freedesktop.org/T7592)**
## Description
It turns out that all the deprecation warnings in e.g. `wayland-server.h` are ineffective when Wayland is installed in the system instead of a prefix. This is presumably caused by [GCC system headers behaviour](https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html) when Wayland headers are installed in `/usr/include`.
Quentin proposed the idea of installing Wayland headers in a `wayland` subdirectory and having the `wayland.pc` add the correct `-I` flag to avoid any breakage. If that works, IMO we should do it.https://gitlab.freedesktop.org/wayland/wayland/-/issues/8Wayland protocol fuzzer2022-03-20T20:14:57ZBugzilla Migration UserWayland protocol fuzzer## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7545)](https://phabricator.freedesktop.org/T7545)**
## Description
Fuzz testing is cool, isn't it? Here's an idea that came to me,...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7545)](https://phabricator.freedesktop.org/T7545)**
## Description
Fuzz testing is cool, isn't it? Here's an idea that came to me, but I haven't learnt about the proper ways of fuzzing.
Have a Wayland protocol object pool. Initially you have only wl_display there. Then repeat:
1. Pick a random object from the pool.
2. Pick a random request from the object's interface.
3. Send the request with random arguments:
- Just randomize something for all POD data types.
- Creating a new protocol object? Add it in the pool.
- An object as an argument? Pick one from the pool at random.
4. Sync with the compositor:
- If the compositor crashed, win! \o/
- If you got disconnected, backtrack, replay, and try again with something different on this iteration.
- If it went ok, continue from 1.
Of course you need to set listeners for all events in an interface. You need some smarts to make it more likely to hit acceptable parameters. The backtracking on failure or crash should be like a tree depth-search. If an action does not let you continue, repeat the whole earlier sequence but this time pick a different action than the one that stopped you.
Maybe use a deterministic pseudo-random number generator to guide the decisions, so you need only the seed and a { number of steps, chosen decision } for every time you had to backtrack, to be able to replay the sequence.
Or rig it all up to some proper fuzzing framework.https://gitlab.freedesktop.org/wayland/wayland/-/issues/7Write a man-page for wayland-scanner2022-03-20T20:14:57ZBugzilla Migration UserWrite a man-page for wayland-scanner## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7347)](https://phabricator.freedesktop.org/T7347)**
## Description
It would be nice to have a man-page for a tool that the wayland...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7347)](https://phabricator.freedesktop.org/T7347)**
## Description
It would be nice to have a man-page for a tool that the wayland project installs.
It could explain all the things that people had to dig up from the code like here:
https://bugs.gentoo.org/show_bug.cgi?id=575212 comments 2-4
wayland-scanner is a binary program and therefore arch-dependent on its own. The input and output of wayland-scanner are arch-independent, though.https://gitlab.freedesktop.org/wayland/wayland/-/issues/6Test wayland-scanner's error detection2022-03-20T20:14:57ZBugzilla Migration UserTest wayland-scanner's error detection## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#3358)](https://phabricator.freedesktop.org/T3358)**
## Description
Wayland-scanner is supposed to detect as much of invalid XML as...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#3358)](https://phabricator.freedesktop.org/T3358)**
## Description
Wayland-scanner is supposed to detect as much of invalid XML as possible, while leaving it possible to extend the XML language itself with new elements and attributes. However, we have no tests checking that wayland-scanner actually detects any problems at all.
Extend the test suite in wayland repository to run wayland-scanner on various broken XML files, each with excercising a certain error or mistake in the XML, and verify it is rejected accordingly.
Study wayland-scanner to see what errors it can detect, and write test XML files to trigger all those errors.https://gitlab.freedesktop.org/wayland/wayland/-/issues/5Create a protocol backward-compatibility checking tool2022-03-20T20:14:56ZBugzilla Migration UserCreate a protocol backward-compatibility checking tool## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#3357)](https://phabricator.freedesktop.org/T3357)**
## Description
It would be useful to have a tool, that would do all the mechan...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#3357)](https://phabricator.freedesktop.org/T3357)**
## Description
It would be useful to have a tool, that would do all the mechanical checks of protocol backward-compatibility when XML files get updated. One possible way to implement it would be as follows:
Add a new output mode to wayland-scanner, that produces distilled details of protocol ABI on the wire, including things like opcodes for messages, argument signatures, and 'since' versioning. You would generate this output for the XML before and after a change, and then use a new tool to verify all the changes are backward-compatible.
Or, maybe the tool could process XML directly, but that probably duplicates things from wayland-scanner. It is uncertain which approach is better in the end, or should it perhaps be even built into wayland-scanner itself.
Examples of things that break backward-compatibility:
- changing opcodes (changing the order in which requests and events are listed)
- changing interface, request and event names
- adding, removing or changing arguments to existing messages
- changing enum values
- removing enum names/values
- removing interfaces, requests or events
- ...
This tool could also verify, that interface versions get bumped properly, and that correct 'since' attributes are used.
Obviously this tool cannot check for semantical changes, and we want to allow improving documentation without being flagged as a break, so it would need to completely ignore all documentation elements.
While writing this tooling and making it detect each of the listed error types, also write tests that provoke those particular errors, so we are certain it will keep on working in the future.https://gitlab.freedesktop.org/wayland/wayland/-/issues/4Add sanity checks for libwayland-client users2024-03-28T09:19:01ZBugzilla Migration UserAdd sanity checks for libwayland-client users## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#50)](https://phabricator.freedesktop.org/T50)**
## Description
We have quite many assumptions for libwayland-client users:
- whe...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#50)](https://phabricator.freedesktop.org/T50)**
## Description
We have quite many assumptions for libwayland-client users:
- when a wl_event_queue is destroyed, we assume (or do we?) there are no objects on it
- what happens if you destroy a wl_event_queue that has queued events?
- Or move an object to a different queue while old queue has events?
- when a wl_display is destroyed, all objects, event queues etc. referencing it have already been destroyed
- the argument objects of a request come from the same wl_display as the object itself
- when you pass in two things, like wl_display and wl_event_queue, to a function as arguments, make sure they are referring to the same wl_display beneath
The checks should be as light-weight as possible. If a thing does not already have a list of all other things referencing it, we don't want to add a list just for the checking, I assume. Although, that probably would ease debugging... OTOH, Valgrind should be able to give the same information. Counters should be enough, preferably protected by existing mutexes that are already taken on that code path anyway.
The reaction to a detected error should be abort(). Using an object from a wrong wl_display is a bug right at that point. Destroying a thing that is still being used - you cannot pick between not destroying it and destroying it anyway, so better just stop right there.
These sanity checks should be accompanied by tests that trigger them.https://gitlab.freedesktop.org/wayland/wayland/-/issues/3Document Wayland XML language2024-03-28T09:19:01ZBugzilla Migration UserDocument Wayland XML language## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#49)](https://phabricator.freedesktop.org/T49)**
## Description
Currently the specification of the Wayland XML language for protoco...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#49)](https://phabricator.freedesktop.org/T49)**
## Description
Currently the specification of the Wayland XML language for protocol specifications is "what wayland-scanner does".
What that really is should be documented properly. Especially the newly proposed attributes for enums require documentation on what they really mean.
Once there is documentation, one could think about adding wayland-scanner tests as another Task.