wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2024-03-28T09:19:01Zhttps://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.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/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/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/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/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/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/13Document client threading and event queues2022-03-20T20:14:58ZBugzilla Migration UserDocument client threading and event queues## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83430)](https://bugs.freedesktop.org/show_bug.cgi?id=83430)**
## Description
Write a chapter to the "big docs" about client side threading a...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83430)](https://bugs.freedesktop.org/show_bug.cgi?id=83430)**
## Description
Write a chapter to the "big docs" about client side threading and event queues.
- dispatching a queue from more than one thread is a bad idea; explain why
- therefore, every thread that needs to dispatch should have its own queue
- also every piece of software that needs to dispatch in a controlled context needs its own queue (e.g. libEGL)
- the client API is not multi-thread-dispatch-safe (wl_display_roundtrip)
- a new wl_proxy inherits its factory's queue
- destroying a queue while wl_proxies on it exist is a mistake and may lead to use-after-free when events on that wl_proxy arrive
- wl_display contains the default queue
### Depends on
* [Bug 91767](https://bugs.freedesktop.org/show_bug.cgi?id=91767)
### Blocking
* [Bug 83429](https://bugs.freedesktop.org/show_bug.cgi?id=83429)
* [Bug 91769](https://bugs.freedesktop.org/show_bug.cgi?id=91769)https://gitlab.freedesktop.org/wayland/wayland/-/issues/15Document how serial should work2022-03-20T20:14:58ZBugzilla Migration UserDocument how serial should work## Submitted by Pekka Paalanen
Assigned to **Daniel Stone `@daniels`**
**[Link to original bug (#83488)](https://bugs.freedesktop.org/show_bug.cgi?id=83488)**
## Description
There is confusion on what the basic principles on using...## Submitted by Pekka Paalanen
Assigned to **Daniel Stone `@daniels`**
**[Link to original bug (#83488)](https://bugs.freedesktop.org/show_bug.cgi?id=83488)**
## Description
There is confusion on what the basic principles on using serials, at least in Weston, should be. Sure, Weston needs lots of fixes, but we should also document how a compositor is expected to use serials, and especially the wl_display_next_serial() API.
```
< pq> does anyone really understand how the serial (wl_display_{get,next}_serial()) system is *supposed* to be used?
< pq> when to use next_serial() vs. get_serial()
< pq> how to compare serials
< pq> when to record a valid serial for later comparison, etc.
< pq> and where to get the serial value to deliver to clients with input and other events: current value from wl_display or some custom saved value?
< pq> how do multiple wl_seats affect these?
< pq> does a pointer button-down on one wl_seat "invalidate" the button-down on another wl_seat?
< daniels> no
< daniels> ... is the short answer :P
< pq> ok, so I think all the serial tracking is at least broken to multiple wl_seats, which does not surprise me, but I think it might be broken even more
< daniels> i mean, if you have two seats (A & B) acting independently delivering to independent windows, window Y gets a button down from seat A and window Z gets a button down from seat B later, wl_shell_surface::resize with serial A on window Y should still work
< daniels> i'm absolutely astounded that multiple seats in weston work as well as they do
< daniels> it was only ever half-finished at best
< daniels> significant input events (button, key, touch) should always use next_serial; iirc, the only chaining (same-serial) event is key followed by modifier
< daniels> the intention being that it's sometimes nice to be able to relate modifier changes back to the provoking key event
< pq> and motion
< pq> okay
< daniels> right, motion isn't a significant event
< daniels> so it always sticks with current serial
< pq> but if I understood the code at all, it is sending the wl_display's current seial value to clients in events
< pq> the current value can be bumped by pretty much anything
< daniels> modifier will use the serial of a key event if it was directly provoked by that, or the next serial if it happened independently of a key event
< daniels> hmm, what bumps it other than button/key/touch?
< pq> if the serial checks compare for equal, a client might be using a serial that is too *new* and get rejected by that
< daniels> in which scenario?
< pq> I didn't identify an exact scenario yet, I was just looking at the grep results for wl_display_next_serial() and grab_serial
< daniels> do we ever bump the serial outside of button/key/touch? (don't have the source to hand, sorry)
< daniels> but yes, storing one _global_ value is going to break multi-seat completely
< daniels> or at least, multiple seats independently interacting with different surfaces
< pq> yes, a lot of places
< pq> http://pastie.org/pastes/9526487/text
< pq> one of the presumably latest additions is xdg_send_configure(), which wants to use a totally unrelated serial to match configure to ack_configure
< daniels> ugh, yes
< daniels> that's the main one i can see which is objectively broken
< pq> we only have one serial source counter in wl_display, so I think we should be wl_display_get_serial()'ing a lot less than we do now
< daniels> that really needs to be in a separate namespace
< pq> well, wouldn't we need one serial generator per wl_seat?
< pq> I mean namespace
< daniels> bumping serial on focus change is definitely broken too, though i guess probably inadvertently gets us the behaviour we want :P
< daniels> i.e. if you click on the titlebar of an unfocused window, you don't want to start a move
< daniels> so it might be that clients are trying to start moves with the button-down serial, which then gets rejected because focus is newer :P
< daniels> namespace/generator no, comparator yes
< daniels> i.e. store last_serial in wl_seat rather than wl_display, and use that to compare against
< pq> http://pastie.org/pastes/9526493/text for get_serial usage
< daniels> keymap bumping serial is a little questionable too, but trying to relate events across keymap changes is ... ugh
< pq> daniels, serials are already stored separately to be compared against, but the serials sent to clients are retrieved from wl_display, which may have advanced for unrelated reasons
< daniels> hmmm, yes
< daniels> right, so get_serial should also be retrieving from wl_seat where it relates to that
< pq> one question I had was, should the comparison be for equal, or greater or equal?
< daniels> ==
< daniels> if you're sending a serial greater than the last significant one, you've screwed something up
< pq> okay, then definitely one should be sending saved serials, not from wl_display
< daniels> hmm, i think we can actually keep using next_serial - we just need to deprecate get_serial on wl_display, and instead require that everyone who needs a serial store it somewhere appropriate, e.g. in the shell info structure
```
### Blocking
* [Bug 83429](https://bugs.freedesktop.org/show_bug.cgi?id=83429)https://gitlab.freedesktop.org/wayland/wayland/-/issues/17Protocol documentation should indicate when wl_data_offer::accept requests sh...2022-03-20T20:14:58ZBugzilla Migration UserProtocol documentation should indicate when wl_data_offer::accept requests should be sent## Submitted by Michael Catanzaro
Assigned to **Wayland bug list**
**[Link to original bug (#91946)](https://bugs.freedesktop.org/show_bug.cgi?id=91946)**
## Description
The Wayland protocol documentation does not define when wl_d...## Submitted by Michael Catanzaro
Assigned to **Wayland bug list**
**[Link to original bug (#91946)](https://bugs.freedesktop.org/show_bug.cgi?id=91946)**
## Description
The Wayland protocol documentation does not define when wl_data_offer::accept requests should be sent. It would be good to discuss this as a guide to implementors.
It only really makes sense to send these in response to wl_data_device::motion events, and then only when the result has changed for a given MIME type, so as not to spam the drag source with unnecessary accept events. It makes sense to send a separate accept event for each offered MIME type.
Version: 1.5.0
### Blocking
* [Bug 83429](https://bugs.freedesktop.org/show_bug.cgi?id=83429)
* [Bug 91948](https://bugs.freedesktop.org/show_bug.cgi?id=91948)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/21Document wl_proxy user data surprises2022-03-20T20:14:58ZBugzilla Migration UserDocument wl_proxy user data surprises## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83479)](https://bugs.freedesktop.org/show_bug.cgi?id=83479)**
## Description
People get surprised, that for a wl_proxy:
- add_listener can o...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83479)](https://bugs.freedesktop.org/show_bug.cgi?id=83479)**
## Description
People get surprised, that for a wl_proxy:
- add_listener can only be used once, so it's more a "init", not "add"
- add_listener sets the same user data as set_user_data does
Might as well review that all aspect of the user data are documented.
This should be both in the per-function doc comments picked up by Doxygen, and when a "big docs" chapter about the client side API gets started, there.
### Blocking
* [Bug 83429](https://bugs.freedesktop.org/show_bug.cgi?id=83429)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/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/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/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/28There is no way to cancel wl_display_dispatch(_pending) call without a server...2021-01-28T10:10:16ZBugzilla Migration UserThere is no way to cancel wl_display_dispatch(_pending) call without a server roundtrip## Submitted by Jonas Ådahl `@jadahl`
Assigned to **Wayland bug list**
**[Link to original bug (#91766)](https://bugs.freedesktop.org/show_bug.cgi?id=91766)**
## Description
Assuming a client is using a multi threaded UI architect...## Submitted by Jonas Ådahl `@jadahl`
Assigned to **Wayland bug list**
**[Link to original bug (#91766)](https://bugs.freedesktop.org/show_bug.cgi?id=91766)**
## Description
Assuming a client is using a multi threaded UI architecture, dispatching on more than one thread, either using the example API usage (wl_display_prepare_read(), poll(fds, 1, -1), ...) or the API helpers wl_display_dispatch() and wl_display_dispatch_queue(), there is currently now good way to make the dispatch call return so that the client can disconnect.
Calling wl_display_disconnect() simply closes the fd and frees the wl_display structure, causing the poll() call to stall and likely a segmentation fault if it leaves it.
Calling pthread_kill() does not work as is, since wl_display_dispatch_queue() will simply re-poll on EINTR.
What one can do is to set a variable causing the dispatcher thread not to continue dispatching and then call wl_display_sync(). This would make the server write data to the fd, causing the dispatcher thread to dispatch and return. This should IMHO only be considered a temporary work-around.
Potentially better solutions could be:
1) Make sure wl_display_disconnect() waits for all registered readers to finish, while making the readers using the helpers cancel using some fd signaling technique like eventfd. A problem with this is that the wl_display_dispatch(_queue) functions would need to return an error (maybe ECANCELED is a reasonable one) This has the side effect that existing clients doing poll(1, -1) and calling wl_display_disconnect() would suddenly start to dead lock. The dead lock could be avoided however by only waiting for wl_display_dispatch_pending() callers, meaning letting the other ones simply continue to deadlock and/or crash in their dispatcher thread as they would before.
2) Introduce new API for canceling wl_display_dispatch(_queue), letting wl_display_disconnect() stay thread unsafe, using some method similar to above. Similar issues as above, but without changing the behavior of wl_display_disconnect().
### Blocking
* [Bug 91769](https://bugs.freedesktop.org/show_bug.cgi?id=91769)https://gitlab.freedesktop.org/wayland/wayland/-/issues/29Misc: A "please suspend" event from the compositor2021-08-25T18:07:57ZBugzilla Migration UserMisc: A "please suspend" event from the compositor## Submitted by Darxus XXX `@darxus`
Assigned to **Wayland bug list**
**[Link to original bug (#49005)](https://bugs.freedesktop.org/show_bug.cgi?id=49005)**
## Description
A "please suspend" event from the compositor, to indicate...## Submitted by Darxus XXX `@darxus`
Assigned to **Wayland bug list**
**[Link to original bug (#49005)](https://bugs.freedesktop.org/show_bug.cgi?id=49005)**
## Description
A "please suspend" event from the compositor, to indicate to an application that it's no longer visible/active. Or maybe discard buffer, as in "wayland discarded your buffer, it's no longer visible, you can stop updating it now.", reattach, as in "oh hey, I'm about to show your buffer that I threw away, what was it again?". for wayland system compositor vt switcing, for example, to be able to throw away the surfaces in the session we're switching away from. for minimized windows that we don't want live thumb nails for. etc.https://gitlab.freedesktop.org/wayland/wayland/-/issues/34wl_array_for_each is not C++ compliant2023-10-25T19:17:09ZBugzilla Migration Userwl_array_for_each is not C++ compliant## Submitted by msisov
Assigned to **Wayland bug list**
**[Link to original bug (#101618)](https://bugs.freedesktop.org/show_bug.cgi?id=101618)**
## Description
Hi,
We've faced an issue, when we used wl_array_for_each in our C++ ...## Submitted by msisov
Assigned to **Wayland bug list**
**[Link to original bug (#101618)](https://bugs.freedesktop.org/show_bug.cgi?id=101618)**
## Description
Hi,
We've faced an issue, when we used wl_array_for_each in our C++ wayland client implementation.
The problem is that one can't use wl_array_for_each(pos, array) when
pos is passed as uint32_t*, for example, and array->data is assigned to it. In C++, one cannot just convert void* to other pointer type implicitly as in C.
Is it possible to modify the macro defined to have explicit type cast?
```
#define wl_array_for_each(pos, array) \
for (pos = (uint32_t*) (array)->data; \
```
or maybe intptr_t before (array)->data ??.
I'm not sure which one would be better, but it is to you to decide.
Br,
msisovhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/37Clipboard protocol requires keyboard2022-08-31T11:59:53ZBugzilla Migration UserClipboard protocol requires keyboard## Submitted by Jonas Ådahl `@jadahl`
Assigned to **Wayland bug list**
**[Link to original bug (#91846)](https://bugs.freedesktop.org/show_bug.cgi?id=91846)**
## Description
The current version of wl_data_device.selection (i.e. co...## Submitted by Jonas Ådahl `@jadahl`
Assigned to **Wayland bug list**
**[Link to original bug (#91846)](https://bugs.freedesktop.org/show_bug.cgi?id=91846)**
## Description
The current version of wl_data_device.selection (i.e. copy-paste offers) requires keyboard focus. In effect, this makes it a requirement to have a keyboard attached in order to copy paste. This is not a reasonable requirement, especially since various types of hardware that may want to run a Wayland compositor with copy-paste capabilities may not have nor be able to have, a keyboard.
This needs to be fixed, probably by extending wl_data_device.selection with a focus like event.
For backward compatibility, we probably need to make this focus like event equivalent to keyboard focus for when the seat has the keyboard capability; but it needs to be sent regardless whether it has or not.https://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/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/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/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/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/53SIGBUS handler for wl_shm is global state2021-07-22T08:55:30ZSimon Sercontact@emersion.frSIGBUS handler for wl_shm is global stateIt ignores SIGBUS triggered by invalid memory accesses inside one of wl_shm memory pages, and re-throws the signal otherwise.
This is an issue if other components of the compositor use mmap with a client-provided FD. In this case the co...It ignores SIGBUS triggered by invalid memory accesses inside one of wl_shm memory pages, and re-throws the signal otherwise.
This is an issue if other components of the compositor use mmap with a client-provided FD. In this case the compositor may want to ignore SIGBUS outside of wl_shm pages.
Any ideas how to handle this situation?https://gitlab.freedesktop.org/wayland/wayland/-/issues/54Widen CI coverage: 32-bit, ASan, etc2021-05-14T13:35:05ZDaniel Stonedaniel@fooishbar.orgWiden CI coverage: 32-bit, ASan, etcOur CI currently just does a very basic check that everything compiles and distcheck passes. There are a lot more checks we could potentially be running, including compiling on 32-bit (and/or big-endian?) systems, building with other com...Our CI currently just does a very basic check that everything compiles and distcheck passes. There are a lot more checks we could potentially be running, including compiling on 32-bit (and/or big-endian?) systems, building with other compilers, using static analysers, and using sanitisers as well.
https://gitlab.freedesktop.org/daniels/wayland/commits/wip/2018-08/meson-ci-asan is an incomplete attempt at doing this, which needs rebasing and potentially separating from the Meson build as well.
It takes @pq's work to enable a 32-bit build with some small tweaks. It also adds support for building with clang, using clang's static analyser, ASan (address sanitiser: valgrind-ish), and UBSan (catches C undefined behaviour, e.g. signed int underflow).
This is not yet ready to merge. Before it gets merged, we should:
* [ ] split the buildroot prep into another stage, which installs the dependencies then pushes a new container to the Docker registry, so each build stage can just reuse that instead of everything installing in parallel
* [ ] more aggressively parameterise things with variables to cut down on boilerplate
* [ ] figure out why on earth ASan is OK for me locally but fails in the Debian chroot
* [ ] fix at least the low-hanging fruit of Clang analyser warnings
* [ ] actually capture the Clang analyser output as an artifact (accidentally removed when moving to templated GitLab CI, oops)
* [ ] add support for running tests under Valgrind (pretty trivial with Meson)
I'll keep working on this in the time I have, but I'm more than happy for someone to just pick this up and run with it.Daniel Stonedaniel@fooishbar.orgDaniel Stonedaniel@fooishbar.orghttps://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).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/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/74State corruption on destruction race with server-created objects2024-02-08T12:56:33ZVictor BergerState corruption on destruction race with server-created objectsSo, this is kind of an edge case, but I found a sequence of events that consistently corrupt the protocol state, based on the races described in https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html
The flo...So, this is kind of an edge case, but I found a sequence of events that consistently corrupt the protocol state, based on the races described in https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html
The flow is:
- a client creates a `wl_data_device`
- the server creates a `wl_data_offer` and sends it to the client
- the client concurrently destroys the `wl_data_offer` via its `release` request
Now, seeing the code from wayland-client here: https://gitlab.freedesktop.org/wayland/wayland/blob/master/src/wayland-client.c#L1349-1361 we see that it silently drops events to zombie objects, meaning the event creating the newid `wl_data_offer` is never processed, and this id is never inserted in the server map.
Now next time the server tries to create a `wl_data_offer`, it'll allocate the next id in its server space and send it. But from the client point of view, this id is not a valid id, as it is not 1 past the last used, but 2 past it (as the previous never got inserted). And so this happens:
```
not a valid new object id (4278190081), message data_offer(n)
```
I guess the fix should be that wayland-client should still allocate new ids in events to zombie objects, even if it means leaking them in the long run?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/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/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/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/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/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/126default XCURSORPATH is not xdg spec compliant2022-01-05T21:41:29Zalexmodefault XCURSORPATH is not xdg spec compliantAs you can see in [xcursor.c](https://gitlab.freedesktop.org/wayland/wayland/blob/master/cursor/xcursor.c#L620), the only per-user directories for the icon themes are `~/.icons/` and `~/.cursors/`. According to the xdg base directory spe...As you can see in [xcursor.c](https://gitlab.freedesktop.org/wayland/wayland/blob/master/cursor/xcursor.c#L620), the only per-user directories for the icon themes are `~/.icons/` and `~/.cursors/`. According to the xdg base directory specification, it should at least also be looking into `~/.local/share/icons/` or `$XDG_DATA_HOME/icons/` if `$XDG_DATA_HOME` is set.https://gitlab.freedesktop.org/wayland/wayland/-/issues/129wayland server API documentation could use overall thread-safety clarification2021-07-26T08:45:19ZPlagmanwayland server API documentation could use overall thread-safety clarificationI don't have great suggestions on the wording, but just a mention that nothing is meant to be thread-safe in the Introduction section of Appendix C might save some confusion.
(some functions mention the calling thread in a way that migh...I don't have great suggestions on the wording, but just a mention that nothing is meant to be thread-safe in the Introduction section of Appendix C might save some confusion.
(some functions mention the calling thread in a way that might mislead developers into thinking the API has some thread-safety built-in)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/133First frame not perfect on HiDPI screen2023-10-26T19:41:13ZSimon Sercontact@emersion.frFirst frame not perfect on HiDPI screenWhen displaying a surface on a HiDPI screen (e.g. `wl_output.scale` = 2), the first frame rendered by clients is not perfect: it's drawn with scale = 1. This happens because compositors send `wl_surface.enter` after a surface is mapped.
...When displaying a surface on a HiDPI screen (e.g. `wl_output.scale` = 2), the first frame rendered by clients is not perfect: it's drawn with scale = 1. This happens because compositors send `wl_surface.enter` after a surface is mapped.
Right after pushing the first frame, clients will receive `wl_surface.enter` and will be able to render at the correct scale.
I'm wondering whether it would be legal for a compositor to send `wl_surface.enter` to an unmapped surface, in the case where the compositor knows on which output the surface will show up when mapped.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/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/136Timer tests can fail on stall spikes2020-09-30T02:32:57ZSimon Sercontact@emersion.frTimer tests can fail on stall spikes>Note that a 10ms stall in the wrong spot could have broken the original `event_loop_timer` test. The "correct" way to solve this, in my opinion, would be to place a few time measurements at the right spots to be able to detect such stal...>Note that a 10ms stall in the wrong spot could have broken the original `event_loop_timer` test. The "correct" way to solve this, in my opinion, would be to place a few time measurements at the right spots to be able to detect such stalls, and then modify the test framework to communicate that a test was skipped when such a delay occurs; I'd prefer to leave such changes to a future MR.
See https://gitlab.freedesktop.org/wayland/wayland/merge_requests/45#note_387651https://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/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/159Blocked clients that received too many events get destroyed even though the W...2024-03-26T14:27:06ZmagiblotBlocked clients that received too many events get destroyed even though the Wayland connection is not broken
This problem is reproducible in every DE I tried: GNOME, Plasma, weston. The most common situation where this happens is in applications blocked due to disk I/O. As can be seen in https://bugreports.qt.io/browse/QTBUG-66997 and https://...
This problem is reproducible in every DE I tried: GNOME, Plasma, weston. The most common situation where this happens is in applications blocked due to disk I/O. As can be seen in https://bugreports.qt.io/browse/QTBUG-66997 and https://bugs.kde.org/show_bug.cgi?id=392376, developers have assumed it's the application's fault for doing blocking tasks in the main GUI thread.
However, the issue can be reproduced by simply following these steps:
1. Open a Wayland application from a terminal.
2. Suspend it with Ctrl+Z.
3. Move the mouse over the application's window for a few seconds.
4. Resume the application with 'fg' and witness how it dies.
Note: this seems to happen less often in GNOME. If you cannot reproduce at the first attempt, try Kwin or weston instead.
Obviously, it wouldn't make any sense if Wayland didn't allow suspending or debugging applications. So I began to debug what was happening in libwayland and observed the following. This is with the `weston-evendemo` client on GNOME:
1. Client resumes execution after being blocked.
2. Client receives events from the server and dispatches them (`handle_display_data`: https://gitlab.freedesktop.org/wayland/weston/-/blob/bac1a7a71f5d49451ad5c6655ef4e79334ba9c38/clients/window.c#L6201).
3. Client flushes the connection (`display_run`: https://gitlab.freedesktop.org/wayland/weston/-/blob/bac1a7a71f5d49451ad5c6655ef4e79334ba9c38/clients/window.c#L6509)
4. Server receives the events and begins processing them (`wl_client_connection_data`: https://gitlab.freedesktop.org/wayland/wayland/-/blob/cc8b6aa3d937dda055cb25fdbec55d0afb6be2a0/src/wayland-server.c#L323)
5. At some point, the server finds an error and destroys the client. Only then the client's window is closed (that is, if the client never flushes its data, it is also never destroyed).
6. Client notices an error in epoll_wait (`EPOLLHUP`) and exits.
Other applications may detect the error in a different way. Qt, for example, keeps reading from the socket until `recvmsg` returns the error `Connection reset by peer` (104). libwayland handles this error in `read_events` (https://gitlab.freedesktop.org/wayland/wayland/-/blob/cc8b6aa3d937dda055cb25fdbec55d0afb6be2a0/src/wayland-client.c#L1482). Then Qt aborts in https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylanddisplay.cpp?id=00390ccf893aa02c8f51e0887624455c7e8d111d#n177.
A debug plan for this issue can be:
1. Start a Wayland session. There, open a terminal and run `weston-eventdemo`.
2. Suspend `weston-eventdemo` and hover the mouse over it for a few seconds.
3. Switch to another tty/DE or a remote shell.
4. Attach a debugger on the compositor. Set breakpoints on `wl_resource_post_error_vargs` and `destroy_client_with_error`. Let it continue.
5. Attach a debugger on `weston-eventdemo`. Set a breakpoint on `handle_display_data` if you wish to inspect how it processes the received events. Otherwise, just let it continue. The compositor should hit a breakpoint after `weson-eventdemo` performs `wl_display_flush`. Make sure the breakpoint is hit because of `weson-eventdemo` and not another client.
What happens next varies among compositors:
* In GNOME, the breakpoint is hit at `wl_resource_post_error_vargs` with `msg="invalid object %u"`.
* In weston and Kwin, the breakpoint is hit at `destroy_client_with_error`. If you repeat the experiment with a breakpoint set on `wl_client_connection_data`, you'll notice that `client->error` is already set (that is, even before the client's data is read). Then, you can do the following:
1. `set client->error=0` to dismiss the error flag.
2. `watch -l client->error` to break when the error is detected next time for this client.
3. Delete the breakpoint on `wl_client_connection_data`, let the compositor continue and detach the debugger on `weston-eventdemo`.
4. Switch back to the DE, suspend `weston-eventdemo` again from the terminal and hover the mouse over it. The breakpoint will be hit while you do this, so be sure to have a remote shell from where you can run `sudo chvt <tty>`, or run `sudo sleep 10 && sudo chvt <tty>` before switching to the DE.
5. In kwin, the breakpoint is hit at:
```cc
#0 handle_array (resource=resource@entry=0x559670da6a00, opcode=opcode@entry=2, args=args@entry=0x7ffded0f0640, send_func=0x7f157422d050 <wl_closure_send>) at ../wayland-1.18.0/src/wayland-server.c:231
#1 0x00007f157422779c in wl_resource_post_event_array (resource=resource@entry=0x559670da6a00, opcode=opcode@entry=2, args=args@entry=0x7ffded0f0640) at ../wayland-1.18.0/src/wayland-server.c:238
#2 0x00007f1574227891 in wl_resource_post_event (resource=0x559670da6a00, opcode=2) at ../wayland-1.18.0/src/wayland-server.c:253
#3 0x00007f1577630770 in () at /usr/lib/libKF5WaylandServer.so.5
#4 0x00007f1576ad2cde in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffded0f0960, r=0x55966fe499d0, this=0x559670c6c240) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#5 doActivate<false>(QObject*, int, void**) (sender=0x55966fd5f990, signal_index=8, argv=0x7ffded0f0960) at kernel/qobject.cpp:3870
#6 0x00007f1577600866 in KWayland::Server::SeatInterface::pointerPosChanged(QPointF const&) () at /usr/lib/libKF5WaylandServer.so.5
```
Because `send_func` fails. `send_func` is actually `wl_closure_send`; further inspection reveals that the error originates from `sendmsg` failing with `Resource temporally unavailable (11)`. Disabling the error setting after `send_func` (or conditioning it to `errno != EAGAIN`) seems to fix the issue, but is not necessarily a good solution. Another way would be unsetting `client->error` in `wl_client_connection_data`. In the end, if the client is able to message the server normally, I guess it doesn't deserve being destroyed? (I say this without having any knowledge about the protocol or libwayland's invariants).
This is all I could figure out. I hope it's useful.
Thank you very much!https://gitlab.freedesktop.org/wayland/wayland/-/issues/162Grabs are mentionned but never defined2021-10-25T07:52:43ZSimon Sercontact@emersion.frGrabs are mentionned but never definedIn the core protocol grabs and implicit grabs are mentioned but never defined. We should probably explain what grabs are in the protocol.In the core protocol grabs and implicit grabs are mentioned but never defined. We should probably explain what grabs are in the protocol.https://gitlab.freedesktop.org/wayland/wayland/-/issues/163Should the order of wl_keyboard::enter 'keys' be defined2020-05-24T23:05:30ZKirill ChibisovShould the order of wl_keyboard::enter 'keys' be definedRight now when client gains focus it receives the pressed keys via `keys`. So client has information that those keys are pressed and it could in theory restart repeat rate (not sure if anyone is doing that right now though), however sinc...Right now when client gains focus it receives the pressed keys via `keys`. So client has information that those keys are pressed and it could in theory restart repeat rate (not sure if anyone is doing that right now though), however since the order is not defined it has no idea what key to start repeating. Logically it seems like it should be the last pressed one, but there's no notion of the last pressed one. Compositor can in theory guarantee the order of those keys and place them in FIFO/LIFO order, so the client will know what it can repeat.
Alternatively you can say that clients must not start repeat from the keys in wl_keyboard::enter.keys.
cc @emersion since it was slightly touched on IRC.https://gitlab.freedesktop.org/wayland/wayland/-/issues/168Simultaneous requirement for code generation (wayland-scanner) and dynamic in...2021-07-01T14:19:33Zwm4Simultaneous requirement for code generation (wayland-scanner) and dynamic invocation (libffi) is unnecessarily roundabout, complicated, and problematicCurrently, it appears that using a wayland protocol requires code generation with wayland-scanner, and in addition internal dynamic dispatching with libffi. Why does it have to complex? In particular, while a wayland client doesn't have ...Currently, it appears that using a wayland protocol requires code generation with wayland-scanner, and in addition internal dynamic dispatching with libffi. Why does it have to complex? In particular, while a wayland client doesn't have to care about the fact that libffi is apparently used internally, the code generation with wayland-scanner is roundabout and complicates the build system.
It's made even worse by wayland-scanner generation two parts (a header and a .c file). Also, you can't just include all the generated .c files in a single .c file (to simplify the build process), because there are completely unnecessary symbol collisions. And even much worse, the .c files are tiny, while the .h files contain significant amounts of code (like inline functions).
If libffi is already used, why require wayland-scanner? It feels like there could be a more streamlined concept for protocol support.
I suggest one of the following alternatives:
1. Provide pre-built protocol libraries, like anyone else does it. (X11, Windows, Android, OSX, iOS, none require you to auto-generate code.)
2. Use code-generation only. Make it simpler; generate only a .h file, or make the .h file minimal so compile time and binary code is minimized. Carefully consider impact on build systems.
3. Use dynamic dispatch only.https://gitlab.freedesktop.org/wayland/wayland/-/issues/174Protocol errors are undocumented2021-09-30T08:34:14ZSimon Sercontact@emersion.frProtocol errors are undocumentedIt's not obvious protocol errors cause the client to disconnect. Neither the "Protocol" section of the docs nor the non-existing `wl_resource_post_error` docs describe the consequences of a protocol error.
Also worth documenting is the ...It's not obvious protocol errors cause the client to disconnect. Neither the "Protocol" section of the docs nor the non-existing `wl_resource_post_error` docs describe the consequences of a protocol error.
Also worth documenting is the fact that protocol errors are fatal, unrecoverable (thus should in general only be used for protocol violations, not for runtime errors).https://gitlab.freedesktop.org/wayland/wayland/-/issues/176Events from compositor for non-existing objects are silently ignored in wayla...2021-02-02T14:03:04ZVictor BergerEvents from compositor for non-existing objects are silently ignored in wayland-client`libwayland-client`, as part of its logic to handle destruction races in the protocol, silently ignores events from the compositor to objects that have already been destroyed. However, in the process it also ignores events to objects tha...`libwayland-client`, as part of its logic to handle destruction races in the protocol, silently ignores events from the compositor to objects that have already been destroyed. However, in the process it also ignores events to objects that never existed in the first place.
An example of this is if the compositor creates an object with `wl_resource_create` and then sends an event to it right away, without first sending to the client the event that would create it. In this situation, from the point of view of the client it'll look exactly as if the message had never been sent in the first place.
We discovered this in `wayland-rs`, which does a distinction between objects that have existed but are now destroyed, versus IDs that have never been assigned to an object at all. We encountered existing code that did exactly what I described in the previous paragraph, causing the `wayland-rs`-based client to consider this as a protocol error.
It looks to me like a clear misbehavior from the compositor, but in the same time simply ignoring the message rather than crashing in this case does seem sensible for the client. Is the expected behavior in such a case specified somewhere?
I understand that, due to ID reuse, it is impossible to differentiate these two cases with certainty. The only situation this can actually be observed is when this occurs on an ID that had never been allocated before. In any case, for the sake of debuggability, I'd suggest that when `libwayland-clients` drops an event, it should be signaled in the output of the `WAYLAND_DEBUG` log, rather than be completely silent. This would certainly help in detecting such compositor bugs.https://gitlab.freedesktop.org/wayland/wayland/-/issues/177Obtaining wayland-type Native Window from Xwayland2020-09-09T09:05:18ZVlad KozmyukObtaining wayland-type Native Window from XwaylandHello.
I have a very specific task: to render directly onto AWT Canvas.\
For that I am using JAWT to obtain the Display and Surface associated with that Canvas.
Under X11, it works fine. Under Wayland - it doesn't, because to my understa...Hello.
I have a very specific task: to render directly onto AWT Canvas.\
For that I am using JAWT to obtain the Display and Surface associated with that Canvas.
Under X11, it works fine. Under Wayland - it doesn't, because to my understanding under Wayland AWT works through XWayland client, and that client doesn't have a "real" Native Window and Display. I have some pointers returned to me, but I cannot initialize EGL from that.
So, what I have is:
Xwayland-type Display;
Xwayland-type Native Window.
What I need is:
Wayland-type Display. I can get it by simply obtaining the default wayland display, because it's a 1-screen system anyway.
Wayland-type Native Window associated with my AWT Element (Canvas) which is in turn an X11/XWayland client.
Alternatively, a wl-surface associated with the Canvas should suffice, but I also can't figure out how to obtain it.
Can you point me in a right direction? Please help!https://gitlab.freedesktop.org/wayland/wayland/-/issues/182Making libwayland more FFI-friendly2021-08-22T08:38:34ZVictor BergerMaking libwayland more FFI-friendlyAs maintainer of [wayland-rs](https://github.com/smithay/wayland-rs), I've been working with the API of libwayland from Rust a lot, and I've encountered a few aspects in which I believe some additions to the API could be made to make lib...As maintainer of [wayland-rs](https://github.com/smithay/wayland-rs), I've been working with the API of libwayland from Rust a lot, and I've encountered a few aspects in which I believe some additions to the API could be made to make libwayland-client more friendly to FFI bindings. Overall, it boils down to allowing more low-level access, which would solely be used by said bindings (as already exist, like the `set_disptacher` functions).
I'm opening this issue to discuss these potential additions, and would be willing to implement them if they are accepted on principle.
1. `wl_proxy_create_versioned`: This would be a trivial addition to the API of libwayland-client, I don't expect this one to be controversial. libwayland-client already provides `wl_proxy_create`, which allows a client program to manually create a proxy before sending it to the server via `wl_proxy_marshal_array`, rather than relying on its automatic creation via `wl_proxy_marshal_array_constructor`. Doing so can be useful for language bindings on several fronts: for example the proxy can be assigned to an event queue before even being sent to the server, ensuring any potential race is completely avoided. Overall, allowing the binding to be in charge of the creation of proxies (just like server-side) would be more practical, from my experience. However, the absence of `wl_proxy_create_versioned` makes it impossible to do such a thing for objects created from the registry, rendering the whole idea void.
2. Side-stepping the internal dispatch mechanism. I expect this one to be more complex and controversial. This idea would be, on an event-queue basis client side, to add a function that would just return the next available message to dispatch, instead of calling all callbacks for all available messages. This would shift the message-processing into a pull-based model, in which the FFI bindings take on the responsibility of forwarding the message to the logic responsible for handling it.
- When using this API, the role of libwayland would be limited to the serialization & deserialization of the messages, as well as maintaining the internal state of the protocol. The FFI bindings would be free to implement any message dispatching strategy as fits best the target language.
- It, of course, comes with a caveat: the event-queue on which this method is called should be entirely controlled by the FFI binding and only used in this way, as otherwise messages may be lost (and similarly for server-side). This is however in line with the best-practices of sharing a Wayland connection between different libraries: each one is expected to create its own event queue to process the events of its objects. We may consider implementing this as two different kind of event queues, to make it easier to catch errors.
- I'm not sure how feasible it would be server-side, given the absence of event-queues. Though the need for FFI-friendliness server-side is less pressing than client-side, as sharing pointers to Wayland objects between different libraries is less pervasive than in client apps.https://gitlab.freedesktop.org/wayland/wayland/-/issues/187Event sources marked with wl_event_source_check not dispatched after wl_event...2021-03-26T13:23:18ZSimon Sercontact@emersion.frEvent sources marked with wl_event_source_check not dispatched after wl_event_loop_dispatch_idleCreate an event source registered with `wl_event_source_check`, for instance an event source for a Wayland connection to a remote compositor (code taken from Weston):
```c
static int dispatch_events(int fd, uint32_t mask, void *data) {
...Create an event source registered with `wl_event_source_check`, for instance an event source for a Wayland connection to a remote compositor (code taken from Weston):
```c
static int dispatch_events(int fd, uint32_t mask, void *data) {
int count = 0;
if (mask & WL_EVENT_READABLE) {
count = wl_display_dispatch(wl->remote_display);
}
if (mask & WL_EVENT_WRITABLE) {
wl_display_flush(wl->remote_display);
}
if (mask == 0) {
count = wl_display_dispatch_pending(wl->remote_display);
wl_display_flush(wl->remote_display);
}
return count;
}
[…]
int fd = wl_display_get_fd(remote_display);
uint32_t events = WL_EVENT_READABLE;
struct wl_event_source *event_source = wl_event_loop_add_fd(loop, fd, events, dispatch_events, NULL);
wl_event_source_check(event_source);
```
Setup an idle source, and send a request to the remote compositor from the idle source:
```c
static void handle_idle(void *data) {
wl_display_sync(remote_display);
}
wl_event_loop_add_idle(loop, handle_idle, NULL);
```
The request gets queued to the Wayland internal buffer, because `WAYLAND_DEBUG=client` shows it. The request doesn't get flushed to the parent compositor, because `WAYLAND_DEBUG=server` doesn't show it. Adding `wl_display_flush` after sending the request fixes the bug.
It seems like `wl_event_loop_dispatch` dispatches idle sources twice since 5ec8062df26f21cfe7a031eaf83a1b4d99085f36. However, checked sources are only dispatched after the second idle source dispatch, not the first. Should we dispatch checked sources twice too?https://gitlab.freedesktop.org/wayland/wayland/-/issues/189wl_array arguments should be const2021-01-08T18:13:58ZSimon Sercontact@emersion.frwl_array arguments should be constlibwayland takes some `wl_array` arguments. These could have been `const`.
Unfortunately I don't think we can change that without breaking the ABI.libwayland takes some `wl_array` arguments. These could have been `const`.
Unfortunately I don't think we can change that without breaking the ABI.https://gitlab.freedesktop.org/wayland/wayland/-/issues/190No protocol error for bad wl_surface.damage rects2021-01-19T15:46:44ZSimon Sercontact@emersion.frNo protocol error for bad wl_surface.damage rectsIf a client sends a negative width/height in `wl_surface.damage` or `wl_surface.damage_buffer`, the compositor cannot let the client know the values are bogus.If a client sends a negative width/height in `wl_surface.damage` or `wl_surface.damage_buffer`, the compositor cannot let the client know the values are bogus.https://gitlab.freedesktop.org/wayland/wayland/-/issues/192Cursor hotspot can be out-of-bounds2021-02-08T09:30:37ZSimon Sercontact@emersion.frCursor hotspot can be out-of-boundsThe X11 protocol doesn't allow a hotspot outside of the cursor image. Wayland does.
Is there any use-case for this?
Found by @imirkin with a `weston-eventdemo` bug: it sets up a 10x16 cursor with a x=12 hotspot (immediately followed up...The X11 protocol doesn't allow a hotspot outside of the cursor image. Wayland does.
Is there any use-case for this?
Found by @imirkin with a `weston-eventdemo` bug: it sets up a 10x16 cursor with a x=12 hotspot (immediately followed up with another hotspot update).https://gitlab.freedesktop.org/wayland/wayland/-/issues/194Size may not be divisible by scale for cursor images2023-02-12T20:00:12ZSimon Sercontact@emersion.frSize may not be divisible by scale for cursor imagesDownstream issue: https://github.com/swaywm/sway/issues/6014
On outputs whose scale is 2, users of libwayland create a `wl_cursor_theme` with the size `preferred_size * scale`. However, internally libwayland may pick a different buffer ...Downstream issue: https://github.com/swaywm/sway/issues/6014
On outputs whose scale is 2, users of libwayland create a `wl_cursor_theme` with the size `preferred_size * scale`. However, internally libwayland may pick a different buffer size depending on the cursor theme (see `_XcursorFindBestSize`). In particular, the resulting "best size" may be odd.
In the issue, a user reports that 3 different clients using libwayland-cursor create a 9x16 buffer for the cursor surface, then set the surface scale to 2.
I'm not sure what's the best way to handle this.
Ref https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/65https://gitlab.freedesktop.org/wayland/wayland/-/issues/197Unify terminology for "double buffered state"2021-02-22T11:19:44ZPekka Paalanenppaalanen@gmail.comUnify terminology for "double buffered state"`wl_surface.commit` documentation says:
> Surface state (input, opaque, and damage regions, attached buffers, etc.) is double-buffered. Protocol requests modify the pending state, as opposed to the current state in use by the compositor...`wl_surface.commit` documentation says:
> Surface state (input, opaque, and damage regions, attached buffers, etc.) is double-buffered. Protocol requests modify the pending state, as opposed to the current state in use by the compositor. A commit request atomically applies all pending state, replacing the current state. After commit, the new pending state is as documented for each related request.
>
> On commit, a pending wl_buffer is applied first, and all other state second. This means that all coordinates in double-buffered state are relative to the new wl_buffer coming into use, except for wl_surface.attach itself. If there is no pending wl_buffer, the coordinates are relative to the current surface contents.
>
> All requests that need a commit to become effective are documented to affect double-buffered state.
>
> Other interfaces may add further double-buffered surface state.
This defines the term "double buffered state". Requests queue up pieces of state which are then made effective (applied) as a whole; atomically.
The definition of `wl_subsurface` affects the behavior of "double buffered state". It adds what I could call as "a delay slot", termed "cached state" in the specification. Cached state gets applied to a `wl_surface` when some state is applied to its parent `wl_surface`, for instance.
Other extension and compositor features may add more delay slots. If a compositor postpones applying surface state update until the associated buffer fences becomes signalled, that requires a new delay slot. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26 probably also needs new delay slots.
On the other hand, documenting state as "double-buffered" varies across protocol extension specifications. Some say double-buffered state is applied on `wl_surface.commit`, which is inaccurate given the existence of delay slots. Some might say the state is applied when... it's applied? Some might talk about latching state in. And so on. My recollection is that this is quite varied and possibly confusing.
Even the term "double-buffered" itself is not accurate, given delay slots exist.
I would like to have a standard phrase to use in protocol specifications to say that a piece of state has double-buffered semantics. Something along the lines of
```
This value is xxx state. See wl_surface.commit for details.
```
and nothing more. Especially no sentence saying it is applied on `wl_surface.commit` since it might not.
What should `xxx` be?
- double-buffered
- latching
- atomic
- delayed
- ...
Hopefully this would make it easier to word not just specifications that introduce more state, but also specifications that add more delays to applying that state.
As a recap, we currently have:
- pending state, which is what is being modified directly by requests and not being looked at by the compositor, until `wl_surface.commit`
- `wl_surface.commit` which is a sort of atomic transition or latching
- cached state and other delay slots, that might chain up
- state actively used by the compositor (i.e. immediately going to or already on screen)
By chaining up I mean you could have a sub-surface waiting for the parent commit, which might be waiting for a group transaction, and then waiting for the buffer fence to become signalled. Which delays what is a big question. Does the buffer fence being unsignalled on a synchronized sub-surface mean that also the parent surface's update must wait even though it was just committed?https://gitlab.freedesktop.org/wayland/wayland/-/issues/198Specify how clients should check for a Wayland socket availability2021-06-25T09:27:57ZSimon Sercontact@emersion.frSpecify how clients should check for a Wayland socket availabilitySome clients support multiple WSI backends, e.g. both Wayland and X11. They must decide which one to use at runtime.
There are two main ways clients do this. It would be nice to settle on one.
- Check whether `WAYLAND_DISPLAY` is set.
...Some clients support multiple WSI backends, e.g. both Wayland and X11. They must decide which one to use at runtime.
There are two main ways clients do this. It would be nice to settle on one.
- Check whether `WAYLAND_DISPLAY` is set.
- Check whether `XDG_SESSION_TYPE` is "wayland".
Some notes:
- All compositors set `WAYLAND_DISPLAY`.
- `XDG_SESSION_TYPE` may not be set (e.g. sessions started from the TTY or nested, which are end-user use-cases for some compositors).
- D-Bus services may not have access to `WAYLAND_DISPLAY` nor `XDG_SESSION_TYPE` (access to these require importing the compositor environment into the D-Bus session).
- `WAYLAND_DISPLAY` is used by libwayland, `XDG_SESSION_TYPE` is not.
Ref https://gitlab.gnome.org/GNOME/gtk/-/issues/1741https://gitlab.freedesktop.org/wayland/wayland/-/issues/202Specify what compositors should do when wl_data_device_manager::get_data_devi...2022-02-08T14:28:06ZRobert MaderSpecify what compositors should do when wl_data_device_manager::get_data_device is called multiple times for the same seatThe [data device spec](https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device) states:
> There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton.
However, the ...The [data device spec](https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device) states:
> There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton.
However, the [data device manager spec](https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device_manager) states for `wl_data_device_manager::get_data_device`:
> Create a new data device for a given seat.
So if a client calls `wl_data_device_manager::get_data_device` multiple times, it's not entirely clear what the compositor should do. If a client attached several `wl_data_device_listener`s to different data devices, should they all still receive events?
Other Wayland protocols AFAICS handle similar situations [with a protocol error](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/stable/viewporter/viewporter.xml#L45-61).
Weston and Mutter currently take only the last created data device into account, however for Mutter there's currently [a bug concerning this](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1841), causing it to toggle between data devices randomly.
I think it would be good to clarify what a client can expect in this scenario, and all compositors doing the same.
cc: @daniels, @emersion, @zzag, @carlosghttps://gitlab.freedesktop.org/wayland/wayland/-/issues/203Per-surface-commit buffer release events2024-01-19T16:16:01ZSimon Sercontact@emersion.frPer-surface-commit buffer release eventsThe linux-explicit-synchronization protocol allows the client to get per-surface-commit buffer release events. This is desirable in case the same `wl_buffer` object is re-used on multiple `wl_surface`s.
However, it's not possible for a ...The linux-explicit-synchronization protocol allows the client to get per-surface-commit buffer release events. This is desirable in case the same `wl_buffer` object is re-used on multiple `wl_surface`s.
However, it's not possible for a compositor to implement the per-surface-commit buffer release events part of linux-explicit-synchronization, without also properly handling explicit fences coming from clients.
We've talked about extracting this functionality out of linux-explicit-synchronization in the past. However @daniels has suggested something else: add a way for a client to clone/duplicate a `wl_buffer`. That way, clients can make sure they never submit the same `wl_buffer` twice, the only submit copies, and get separate `wl_buffer.release` events.https://gitlab.freedesktop.org/wayland/wayland/-/issues/214The future of event-loop2023-03-01T18:27:06ZKeegan SaundersThe future of event-loop#### Overview
Supporting non-Linux platforms in Wayland currently requires the use of epoll-shim or a kqueue backend. Further, the event loop is used at a very basic capacity inside of Wayland itself, but downstream users rely on its fu...#### Overview
Supporting non-Linux platforms in Wayland currently requires the use of epoll-shim or a kqueue backend. Further, the event loop is used at a very basic capacity inside of Wayland itself, but downstream users rely on its functionality.
Maintaining it is an issue, and adding another backend just piles onto the work.
#### Options
* Replace epoll backend with an event loop abstraction library like libuv or libev
* Con: Adds a dependency, but both are already packaged by all package managers for e.g. Node.js
* Con: May be challenging to emulate the current event loop's behaviour with a library
* Pro: Multitude of platform support that we don't have to maintain
* Deprecate the event loop
* Pro: BSD support is much easier. No need to port an event loop, it will just be a linker error and the dependent is updated
* Pro: We don't have to maintain any event loop at all
* Con: All downstream programs need to update to use their own event loop
#### Replacing epoll backend
libuv looks like a real candidate and is packaged almost everywhere already as it is used by Node.js. The main issue is making sure that we remain ABI compatible and dispatch events in the same order as is done in the epoll backend.
See: http://docs.libuv.org/en/v1.x/design.html#the-i-o-loop. It looks like the only thing out of order is that we call idle callbacks before timers, whereas libuv has timers before everything else. Is this a real issue or can we safely replace with libuv without any tricky hacks?
I am not familiar with nor have looked at any other libraries like libev.
@emersion @pqhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/217shm: support for non-zero mmap offsets2023-10-15T11:29:34ZDemi Marie Obenourdemiobenour@gmail.comshm: support for non-zero mmap offsetsCurrently, Wayland’s shared memory support requires that the file descriptor being able to be `mmap`’d starting at offset zero. This is problematic for Qubes OS, which wants to pass a file descriptor pointing to `/dev/xen/gntdev`. Such...Currently, Wayland’s shared memory support requires that the file descriptor being able to be `mmap`’d starting at offset zero. This is problematic for Qubes OS, which wants to pass a file descriptor pointing to `/dev/xen/gntdev`. Such file descriptors must be mmaped at a non-zero offset, which clients obtain via a special ioctl.https://gitlab.freedesktop.org/wayland/wayland/-/issues/218Document wl_seat.name persistence guarantees2021-07-08T14:28:29ZSimon Sercontact@emersion.frDocument wl_seat.name persistence guarantees> On one hand, I'd like to allow using the seat name in configuration files. On the other hand, I'd like to allow compositors to create temporary seats, with seat names that aren't persistent.
Ref https://gitlab.freedesktop.org/wayland/...> On one hand, I'd like to allow using the seat name in configuration files. On the other hand, I'd like to allow compositors to create temporary seats, with seat names that aren't persistent.
Ref https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/150#note_975390https://gitlab.freedesktop.org/wayland/wayland/-/issues/220Clarify that compositor must not modify attached buffers2021-07-22T08:39:40ZRobert MaderClarify that compositor must not modify attached buffersThe spec strongly indicates but arguably not explicitly mentions that a compositor should not modify the backing storage of a attached `wl_buffer` between `wl_surface.commit` and the `wl_buffer.release` event:
> Committing a pending wl_...The spec strongly indicates but arguably not explicitly mentions that a compositor should not modify the backing storage of a attached `wl_buffer` between `wl_surface.commit` and the `wl_buffer.release` event:
> Committing a pending wl_buffer allows the compositor to read the pixels in the wl_buffer. The compositor may access the pixels at any time after the wl_surface.commit request. When the compositor will not access the pixels anymore, it will send the wl_buffer.release event. Only after receiving wl_buffer.release, the client may reuse the wl_buffer.
Guaranteeing that the buffer content does not get modified has an advantage for clients: as they can still access the buffer content, they may copy content to another buffer. This allows to implement e.g. partial damage in very efficient and simple ways. Importantly, other platforms such as CoreAnimation make such guarantees. Thus implementing Wayland support in multiplatform clients becomes much easier if they can use the same approach here.
From a compositor perspective, there could be scenarios where changing buffer content in place during compositing might be desirable (changing it back before `wl_buffer.release`). I'm not aware of any real world use-case though.
If it is concluded that the spec is already explicit enough, feel free to close the issue.
cc @emersionhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/221wl_resource_find_for_client is O(n²)2023-11-28T17:38:08ZDemi Marie Obenourdemiobenour@gmail.comwl_resource_find_for_client is O(n²)wl_resource_find_for_client is O(n<sup>2</sup>) due to misusing `wl_list_for_each`. It should use a balanced tree or hash table instead.wl_resource_find_for_client is O(n<sup>2</sup>) due to misusing `wl_list_for_each`. It should use a balanced tree or hash table instead.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/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/229wl_surface.frame interactions with sub-surfaces2021-11-12T14:24:52ZSimon Sercontact@emersion.frwl_surface.frame interactions with sub-surfacesThe protocol says:
> The frame request will take effect on the next wl_surface.commit.
How does this interact with cached state? How should a compositor react when a client requests a frame callback and commits a sub-surface sync'ed wi...The protocol says:
> The frame request will take effect on the next wl_surface.commit.
How does this interact with cached state? How should a compositor react when a client requests a frame callback and commits a sub-surface sync'ed with its parent, without committing its parent?
- Should the frame callback be completed the next time it's a good time to draw for the client, or
- Should the frame callback be cached until the client commits the parent surface?
Note: this also has interactions with https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26https://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/237Mapping a lot of windows at once using wl_shm gets Xwayland killed2024-03-28T17:05:32ZOlivier FourdanMapping a lot of windows at once using wl_shm gets Xwayland killed## Description
When Xwayland cannot use glamor and GBM (typically when GL is implemented in software with LLVM as when running in a virtual machine), it falls back to `wl_shm` to pass its buffers around.
In that case, if the X11 client...## Description
When Xwayland cannot use glamor and GBM (typically when GL is implemented in software with LLVM as when running in a virtual machine), it falls back to `wl_shm` to pass its buffers around.
In that case, if the X11 clients creates a whole lot of X11 windows at once, flooding the Wayland compositor as in xorg/xserver#1222, Wayland will abort taking down `Xwayland` with the following error:
`request could not be marshaled: can't send file descriptor`
This message originates from [`wl_connection_put_fd()`](https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.16/src/connection.c#L432-435) because [`wl_connection_flush()`](https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.16/src/connection.c#L314-320) returned `-1` as it hits the error case with `errno` being `EAGAIN` (typically the Wayland compositor cannot cope and the socket got full).
Trying to reconnect (as with xorg/xserver!756) will flood the Wayland compositor even more so this is unlikely to help in that particular case.
After some discussions on irc on #wayland with @emersion, @jadahl and @DemiMarie, Jonas suggested a possible solution for now would be to have an unbound output buffer for Wayland clients (which is different from #159) as the needs for clients are different from the ones for the server, it is not the same issue.
FWIW, I tried @mstoeckl's https://gitlab.freedesktop.org/mstoeckl/wayland/-/commits/variable-connection branch but to no avail, it still fails with `EGAIN` in `sendmsg()` called from `wl_connection_flush()` so maybe that branch doesn't account for all cases.https://gitlab.freedesktop.org/wayland/wayland/-/issues/239Document wl_shm_pool creation costs2021-09-30T10:05:22ZDemi Marie Obenourdemiobenour@gmail.comDocument wl_shm_pool creation costsThe cost of creating a `wl_shm_pool` is currently underspecified. There are two possibilities:
- Creating a pool is very cheap, even if the pool is very large. This is the case for standard implementations backed by pagable virtual me...The cost of creating a `wl_shm_pool` is currently underspecified. There are two possibilities:
- Creating a pool is very cheap, even if the pool is very large. This is the case for standard implementations backed by pagable virtual memory.
- Creating a pool is expensive, and may consume resources proportional to the size of the pool, even if most of the pool is never used. This is the case if the entire pool must be locked into memory.https://gitlab.freedesktop.org/wayland/wayland/-/issues/240Provide an error for “client is using too many resources”2022-01-05T17:49:07ZDemi Marie Obenourdemiobenour@gmail.comProvide an error for “client is using too many resources”There is no clearly appropriate error for “client exhausted its quotas”. `WL_DISPLAY_ERROR_NO_MEMORY` implies that the server actually ran out of memory, which isn’t the case, and `WL_DISPLAY_ERROR_IMPLEMENTATION` means the compositor i...There is no clearly appropriate error for “client exhausted its quotas”. `WL_DISPLAY_ERROR_NO_MEMORY` implies that the server actually ran out of memory, which isn’t the case, and `WL_DISPLAY_ERROR_IMPLEMENTATION` means the compositor is buggy.https://gitlab.freedesktop.org/wayland/wayland/-/issues/241Map shared memory from the client read-only2022-07-05T07:54:55ZDemi Marie Obenourdemiobenour@gmail.comMap shared memory from the client read-onlyClients may wish to share memory with the server that the server is not able to write, such as memory-mapped files the server does not have write permission for. Additionally, having the server be able to write to shared memory is a foo...Clients may wish to share memory with the server that the server is not able to write, such as memory-mapped files the server does not have write permission for. Additionally, having the server be able to write to shared memory is a footgun on the server side.https://gitlab.freedesktop.org/wayland/wayland/-/issues/243Reducing the number of objects doesn’t release all of the memory2021-10-08T17:04:09ZDemi Marie Obenourdemiobenour@gmail.comReducing the number of objects doesn’t release all of the memoryIf a client instantiates (say) $10^7$ objects, and then destroys all of them, the `wl_map` that stores the object list will not shrink. This can be fixed with a fancier data structure, such as an interval tree.If a client instantiates (say) $10^7$ objects, and then destroys all of them, the `wl_map` that stores the object list will not shrink. This can be fixed with a fancier data structure, such as an interval tree.https://gitlab.freedesktop.org/wayland/wayland/-/issues/245Proposal: require destructor events to be annotated2021-10-18T09:09:31ZDemi Marie Obenourdemiobenour@gmail.comProposal: require destructor events to be annotatedDestructor events can be annotated in the XML, but this is currently not required. By requiring destructor events to be annotated, several benefits ensue. These include, but are not limited to:
1. wayland-scanner can check that every ...Destructor events can be annotated in the XML, but this is currently not required. By requiring destructor events to be annotated, several benefits ensue. These include, but are not limited to:
1. wayland-scanner can check that every object has either a destructor request (named either “release” or “destroy”) or a destructor event (and no requests).
2. libwayland-server can detect more errors, such as destroying an object without either sending a destructor event or having received a destructor request.
3. Since an object can now be destroyed only by a destructor request or event on that object itself, it is possible for libwayland-client to automatically destroy objects created by events sent to zombie objects.https://gitlab.freedesktop.org/wayland/wayland/-/issues/246Proposal: Add a `destroy-with="request-name"` attribute for events that creat...2021-10-24T21:42:12ZDemi Marie Obenourdemiobenour@gmail.comProposal: Add a `destroy-with="request-name"` attribute for events that create objectsThis will allow libwayland-client to send destructor requests to objects created by events sent to zombies.This will allow libwayland-client to send destructor requests to objects created by events sent to zombies.https://gitlab.freedesktop.org/wayland/wayland/-/issues/247Notes for protocol-next design2023-03-19T22:58:12ZPekka Paalanenppaalanen@gmail.comNotes for protocol-next designThis is a random collection of ideas or more like open questions for the next major revision of Wayland protocol and libraries. The Wayland architecture for the graphics stack should remain as is.
**Disclaimer:**
> I probably cannot wor...This is a random collection of ideas or more like open questions for the next major revision of Wayland protocol and libraries. The Wayland architecture for the graphics stack should remain as is.
**Disclaimer:**
> I probably cannot work on this any more than filing this issue. I am also not sure doing this would be worth the effort either. There are no plans to work on this.
However, we should still collect a list of things that cannot be made nice without breaking libwayland ABI or Wayland protocol, just in case the pressure builds up high enough to make the work worthwhile. So here goes.
----
Let's call the next generation set of libraries and protocol Wayland 2.0.
- Wayland 2.0 must be able to co-exist with Wayland 1.0 in the same system and in the same compositor instance.
- Maybe Wayland 2.0 should have a different socket file name, so that clients can choose.
- Wayland 2.0 probably needs a new, independent set of libwayland libraries, so that we can drop all existing ABI we do not want to carry around, like the event loop API.
- Wayland 1.0 and Wayland 2.0 libraries must be able to co-exist and be used in the same process and thread.
- Wayland 2.0 should support 64-bit types on the wire. We already have use for them.
- Somehow, it should be easy to add Wayland 2.0 support in compositors and toolkits while keeping Wayland 1.0 support.
- For C language bindings, maybe keep the current design?
- Existing Wayland XML files need to usable with both Wayland 1.0 and Wayland 2.0. We do not want to duplicate those just for the sake of Wayland 2.0 when they are not specifically depending on Wayland 2.0 features like 64-bit types. We can require backward-compatible changes in XML files to make them Wayland 2.0 compatible, but they still need to work with Wayland 1.0.
- New XML files can be written to be Wayland 2.0 exclusive, to e.g. make use of new wire types.
- A new code generator.
- Do not special-case C language bindings, use the same low level API for all languages.
- Drop dependency to libffi. This means we need to generate more code for dispatch.
- Do not special-case `wayland.xml`. All user projects (compositors and toolkits/apps) need to use the code generator even for the core interfaces. This avoids exporting interface data symbols from the Wayland 2.0 libraries, which has been a bit of a pain with Wayland 1.0. We also get less special-cases to consider when augmenting the ABI later.
- Make sure user projects generate their Wayland code as private, to avoid accidental conflicts between binaries in a process.
- Make core protocol more symmetric.
- Make `delete_id` messaging fully symmetric.
- Fix the problems around server created protocol objects.
- Protocol errors still make sense to keep server→client only.
- Object id tracking rewrite.
- Eradicate zombies? Or at least make them fully symmetric.
- Replace `wl_map`?
- Aggressive id re-use? Limited new id allocation range like it is in Wayland 1.0?
- How to keep EGL and Vulkan WSI working?
- With independent libraries, you cannot just pass a Wayland 2.0 object to API that expects a Wayland 1.0 object.
- Inter-operating between Wayland 1.0 and Wayland 2.0 libraries is likely infeasible, certainly unwanted from implementation point of view.
- Passing objects from one library to the other inside a process.
- Using the same connection with both libraries.
- Having one library on one side of a connection and the other library on the other side of the connection.
- Negotiate root object version on connection.
- Is the equivalent of being able to version `wl_display` of Wayland 1.0.
- Still need to offer client API that does not block on connection initialization.
- Eventually, it should be possible to have a Wayland 2.0 -only system, assuming one does not need software that was not ported.https://gitlab.freedesktop.org/wayland/wayland/-/issues/248can't close client in client created listener2021-10-28T07:48:02ZSebastian Wickcan't close client in client created listenerIf the compositor runs into an error condition in a client created listener (`wl_display_add_client_created_listener`) it is not possible to call `wl_client_destroy` since the listeners are called from inside wl_client_create which in tu...If the compositor runs into an error condition in a client created listener (`wl_display_add_client_created_listener`) it is not possible to call `wl_client_destroy` since the listeners are called from inside wl_client_create which in turn would return a pointer to the already freed client memory.https://gitlab.freedesktop.org/wayland/wayland/-/issues/253Broken man pages containing C macros2021-11-11T12:51:31ZNicolai DagestadBroken man pages containing C macrosHi,
It the man pages for wl_array and wl_list both contain documentation on C macros, and from what I gathered it seems to be generating these pages from the header files by including the value of the macro. By doing this they add baslas...Hi,
It the man pages for wl_array and wl_list both contain documentation on C macros, and from what I gathered it seems to be generating these pages from the header files by including the value of the macro. By doing this they add baslashes ("\\") that escape the newline in the roff source.
I haven't understood exactly how the man pages are generated yet so this is reported as an issue instead of sending a patch fixing the problem, if somebody could point me in the right direction I'd be happy to try and fix it though 🙃
Attached screenshot of the current output and the expected one
![current](/uploads/d345b7b166eb79adb3fafb3071323f63/current.png)
![expected](/uploads/494b3eeb5cd344cd2d266f7d8e471b3b/expected.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/255Allow multiple wl_keyboards, wl_pointer, etc. under single wl_seat2022-10-27T08:23:43ZRoman GilgAllow multiple wl_keyboards, wl_pointer, etc. under single wl_seatThe current paradigm for input devices is that under one wl_seat all physical devices are grouped together to single wl_keyboard, wl_pointer, etc. instances.
This was meant as a simplification in comparison to the old X11 device handlin...The current paradigm for input devices is that under one wl_seat all physical devices are grouped together to single wl_keyboard, wl_pointer, etc. instances.
This was meant as a simplification in comparison to the old X11 device handling but has led to some issues. For example having multiple keyboards connected with different keymaps connected under a single wl_seat is in principle not possible. One can connect such and the compositor updates the keymap in between, but this breaks if keys are pressed simultaneously.
With !62 there is an attempt to solve this through logical keyboard groups, but it would be better to directly allow, maybe if not currently possible in a Wayland 2.0 version, compositors to create multiple wl_keyboards, etc. under a single seat and let clients handle the multiplexing.https://gitlab.freedesktop.org/wayland/wayland/-/issues/258avoid the wl_surface.frame callback mechanism for protocol-next2021-11-26T00:28:09ZSebastian Wickavoid the wl_surface.frame callback mechanism for protocol-nextThe frame callback mechanism is relatively unspecified and leaves a lot of room for different implementations. Different compositors send the callback event at different points in their refresh cycle which makes the timing of clients rat...The frame callback mechanism is relatively unspecified and leaves a lot of room for different implementations. Different compositors send the callback event at different points in their refresh cycle which makes the timing of clients rather unpredictable on different compositors. Some compositors try (have tried?) to dynamically adjust when the event is sent to reduce latency but some clients also try to reduce latency by adjusting their rendering relative to the frame callback event which results in a bad feedback loop.
On the next version replacing the frame callback mechanism with a better frame scheduling mechanism should be considered.https://gitlab.freedesktop.org/wayland/wayland/-/issues/259provide an atomic transaction primitive for all surface state in protocol-next2021-11-19T11:48:44ZSebastian Wickprovide an atomic transaction primitive for all surface state in protocol-nextThe way surface state propagates through a surface tree is slightly underspecified and not the most intuitive. Furthermore some use cases require committing multiple surface trees atomically (https://gitlab.freedesktop.org/wayland/waylan...The way surface state propagates through a surface tree is slightly underspecified and not the most intuitive. Furthermore some use cases require committing multiple surface trees atomically (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26) which further complicates the logic.
For the next version surface commits could be removed. All (non-sub-)surfaces which should be committed together is instead added to a transaction object which, on commit, takes a snapshot of all (pending) state of all surface trees.https://gitlab.freedesktop.org/wayland/wayland/-/issues/260Auto-Type in login form2024-02-12T18:42:30ZXylleAuto-Type in login formHello,
since I switched to wayland the KeepassXC software can't fill in the forms automatically.
Before Wayland with the same version of gnome-shell, this software did its job very well.
After some research it appears that the problem c...Hello,
since I switched to wayland the KeepassXC software can't fill in the forms automatically.
Before Wayland with the same version of gnome-shell, this software did its job very well.
After some research it appears that the problem comes from wayland.
Considering the complexity of the passwords, this is a real setback in terms of security. For some software there are some workarounds but they are not optimal. For the rest of the software there is no solution.
Having a key combination that automatically fills in a login form is a real plus in terms of security. It is easy to define a password per site/software and of a more than correct complexity.
Could you implement a solution that would allow software such as KeepassXC to have access to the window title and to send keystrokes.
Sincerely Xyllehttps://gitlab.freedesktop.org/wayland/wayland/-/issues/266Clarifications around wl_surface.frame and opaque subsurfaces2023-11-25T00:19:22ZRobert MaderClarifications around wl_surface.frame and opaque subsurfacesThe spec says:
> A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.
If compositors implement this strictly (AFAI...The spec says:
> A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.
If compositors implement this strictly (AFAIK only Mutter does ATM), clients using subsurfaces to build an UI have a hard time using `wl_surface.frame`, as they often need to request a frame for every (partly) opaque subsurface individually.
Consider e.g. a client that use subsurfaces as overlays - examples here are Firefox and the Gstreamer Wayland sink - and has a big parent surface that is supposed to handle input. `wl_surface.set_input_region()` provides a decent way to make the subsurfaces not consume input events. The same unfortunately is not true for `wl_surface.frame`. If the client wants a single source for frame callbacks, it can not just request them on the parent surface, as each opaque subsurface may block them.
GTK3 now has a workaround for such issues, allowing multiple callbacks to be requested via `gdk_wayland_window_add_frame_callback_surface()`. This however adds overhead and complexity both in the application and the compositor[^1].
I wonder if we can find a more elegant solution for this problem. The most obvious solutions that came to my mind so far came are:
1. Change the core spec to state that surfaces occluded by descendant subsurfaces should still receive callbacks.
2. Add a new protocol that allows to make "recursive" callbacks in some way.
I'd happily work on 2. if that's deemed the best solution, but first wanted to hear opinions if a core spec change is not more straight forward (or other ideas come up). So - I'd be supper happy about comments :)
CC: @jadahl, @pq, @daniels, @emersion, @zzag
---
[^1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1735494https://gitlab.freedesktop.org/wayland/wayland/-/issues/267Clarify wl_surface.damage[_buffer] behavior when no buffer is attached2022-01-21T01:26:10ZRobert MaderClarify wl_surface.damage[_buffer] behavior when no buffer is attachedCertain clients currently call `wl_surface_damage_buffer()` even if no buffer is attached - i.e. neither a new one, nor one that is still hold by the compositor.
Strictly speaking, right now the call only makes sense if a buffer is pend...Certain clients currently call `wl_surface_damage_buffer()` even if no buffer is attached - i.e. neither a new one, nor one that is still hold by the compositor.
Strictly speaking, right now the call only makes sense if a buffer is pending:
> This request is used to describe the regions where the pending buffer is different from the current surface contents
In Mutter we currently print a error to the journal but don't inform the client that this is arguably invalid behavior. I think we should clarify this situation by either:
1. adding a new `wl_surface.error` for this case
2. explicitly allowing it and
1. requiring compositors to ignore the call in this case
2. requiring compositors to repaint the damaged region on screen
AFAIK there's only one use-case where 2.2. is actually useful: when using shm-buffer in combination with `wp_viewporter.src_rect`. In this case a client may change the `src_rect.[x.y]`, changing what should be displayed on screen while neither changing the buffer content nor surface size, likely not triggering a repaint. There *are* scenarios where this could be useful, but arguably such highly optimized clients shouldn't use shm-buffers in the first place *and* we could require compositors to update the surface area in such cases (arguably this is already the case).
Opinions?https://gitlab.freedesktop.org/wayland/wayland/-/issues/273[Feature request] Add support to wl_keyboard for wayland to send xkb RMLVO tu...2022-01-17T04:40:27ZWeng Xuetian[Feature request] Add support to wl_keyboard for wayland to send xkb RMLVO tuple.The use case this is intended for input method.
In input method, one use case that we want to use the layout/variant specified by user, re-use xkb options from the system. Right now we only have keymap fd which only contains some raw da...The use case this is intended for input method.
In input method, one use case that we want to use the layout/variant specified by user, re-use xkb options from the system. Right now we only have keymap fd which only contains some raw data. It would ideal to have the same thing like _XKB_RULES_NAMES under X11.
zwp_input_method_v1 is reusing wl_keyboard interface; zwp_input_method_v2 in the wild is following the interface of wl_keyboard. So I'd like to have the support in wl_keyboard first.https://gitlab.freedesktop.org/wayland/wayland/-/issues/274Add 'float' wire data type?2023-10-31T09:09:12ZPekka Paalanenppaalanen@gmail.comAdd 'float' wire data type?I started thinking, what would it take to add a floating point data type to the argument types on the wire, and it seems doable for 32-bit float.
Let's say we add float support in libwayland version 1.k. It needs to be recognized in XML...I started thinking, what would it take to add a floating point data type to the argument types on the wire, and it seems doable for 32-bit float.
Let's say we add float support in libwayland version 1.k. It needs to be recognized in XML and emitted by scanner. It needs a new message signature character. It needs to be added in `union wl_argument`. That's all?
The reason we cannot add any 64-bit types (easily) is that on 32-bit architectures, they would change the size of `union wl_argument`.
The float type could be used in new protocol extensions. Adding it to existing protocol extensions would be discouraged, because it means that an extension that used to be buildable with wayland-scanner version < 1.k no longer builds. IOW, you cannot upgrade wayland-protocols without upgrading libwayland - although, is that something we want to explicitly support? For scanners for other languages, I think adding `float` to an existing extension would be disruptive.
Obviously both server and client libwayland on the two sides of a Wayland connection must both support `float` for it to work. Ensuring this is simple:
- If client uses an old libwayland, it cannot use an extension needing `float`, so never binds it.
- If server uses an old libwayland, it will not advertise an extension needing `float`.
Furthermore, it doesn't matter if wayland-protocols gets *new* extensions using `float`. All users of existing extensions can just keep on using old libwayland, since they never attempt to build new extensions needing `float`.
A project that uses an extension that need `float` will strictly require libwayland version >= 1.k. It cannot be built with an older version, and after building it cannot be run with an older version. But I think we already assume that you won't run with an older libwayland that what scanner you used for building.
A user for `float` types could obviously be wayland/wayland-protocols!14, but we can also work around the lack of float with integers too.
----
What do you think of extending wire types like this?
Would you have use for `float` on the wire?https://gitlab.freedesktop.org/wayland/wayland/-/issues/276Attaching wl_data_source multiple times concurrently2022-02-12T08:23:18ZJulian OrthAttaching wl_data_source multiple times concurrentlySome applications, such as those based on GDK, require `wl_data_source::cancelled` to be sent to them to recognize that a received `wl_data_offer` was created by another client. If they don't receive `wl_data_source::cancelled` after att...Some applications, such as those based on GDK, require `wl_data_source::cancelled` to be sent to them to recognize that a received `wl_data_offer` was created by another client. If they don't receive `wl_data_source::cancelled` after attaching a `wl_data_source` to a seat, they will never call `wl_data_offer::receive` because they assume that the data offer refers to their own `wl_data_source`.
Therefore sending `wl_data_source::cancelled` is required. However I could not find any language in the spec explaining when exactly this event should be sent. The spec does not prohibit clients from attaching one data source for multiple purposes at the same time, e.g., attaching them to multiple seats or for both DnD and selection. Should `cancelled` be sent as soon as at least one of these attachments gets replaced? If so then what is the behavior of the other attachments?https://gitlab.freedesktop.org/wayland/wayland/-/issues/278Clarification on `axis_discrete` specification2022-02-13T23:57:20ZMax XiongClarification on `axis_discrete` specificationThe axis_discrete specification for wl_pointer contains this sentence:
> Note that the protocol allows for other events to occur between the axis_discrete and its coupled axis event, including other axis_discrete or axis events.
Can any...The axis_discrete specification for wl_pointer contains this sentence:
> Note that the protocol allows for other events to occur between the axis_discrete and its coupled axis event, including other axis_discrete or axis events.
Can any of the other events use the same axis as the first event? If they do how does one pair the events?https://gitlab.freedesktop.org/wayland/wayland/-/issues/280Clarification on wl_pointer.leave and currently held buttons2023-05-23T09:55:33ZDavid EdmundsonClarification on wl_pointer.leave and currently held buttonsIn the wl_keyboard protocol it explicitly says when we get a wl_keyboard.leave event "the client should assume all keys are lifted."
wl_pointer has no matching statement for button state.
---
The reason it came up is right now in Qt cl...In the wl_keyboard protocol it explicitly says when we get a wl_keyboard.leave event "the client should assume all keys are lifted."
wl_pointer has no matching statement for button state.
---
The reason it came up is right now in Qt clients we do clear up pressed buttons on pointer leave.
This causes us a minor user-facing bug that it's an apparently established X11 practice to right click hold, open a context menu, then select the entry when the mouse on release. This is broken with the above behaviour.
However not resetting the button state on wl_pointer.leave would cause us bigger issues if a compositor doesn't clean up button state explicitly when leaving.
However we want it to work would benefit from a spec clarification.https://gitlab.freedesktop.org/wayland/wayland/-/issues/281scanner: more convenient callbacks2022-03-09T09:21:39ZSimon Sercontact@emersion.frscanner: more convenient callbacksI'm not sure this is worth fixing, just opening an issue in the spirit of #247.
Right now the generated callback function signatures aren't very convenient to use. Some parameters aren't really necessary, and including them makes it so ...I'm not sure this is worth fixing, just opening an issue in the spirit of #247.
Right now the generated callback function signatures aren't very convenient to use. Some parameters aren't really necessary, and including them makes it so the argument lists are longer, easy to get wrong and less readable.
### Server-side
```c
struct wl_display_interface {
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
// could be
struct wl_display_interface {
void (*sync)(struct wl_resource *resource,
uint32_t callback);
};
```
Because `client = wl_resource_get_client(resource)`.
### Client-side
```c
struct wl_display_listener {
void (*error)(void *data,
struct wl_display *wl_display,
void *object_id,
uint32_t code,
const char *message);
};
// could be
struct wl_display_listener {
void (*error)(struct wl_display *wl_display,
void *object_id,
uint32_t code,
const char *message);
};
```
Because `void *data = wl_proxy_get_user_data(wl_display)`.https://gitlab.freedesktop.org/wayland/wayland/-/issues/283server: global filter not taken into account when creating/destroying globals2022-03-23T09:29:43ZSimon Sercontact@emersion.frserver: global filter not taken into account when creating/destroying globalsRef https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/148:
> if a client connects and binds a registry, and then the server adds a global afterwards, the client will always get a `wl_registry.global` message for it even if...Ref https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/148:
> if a client connects and binds a registry, and then the server adds a global afterwards, the client will always get a `wl_registry.global` message for it even if binding that global would result in failure.