Forgive the long post. Tl;dr: what are the rules of object ID lifetime
and reuse in the Wayland protocol?
I am attempting to understand the rules of object ID lifetime within
the Wayland protocol in order to construct Wayland middleware (similar
to some of the tools featured on
https://wayland.fr
On Thu, 14 Sep 2023 16:32:06 +0300
Pekka Paalanen wrote:
> ...
>
> congratulations, I think you may have found everything that is not
> quite right in the fundamental Wayland protocol design. :-)
Oh, you flatter me. I'm sure there's more!
>
> As an aside, we collect unfixable issues under
>
Pekka,
After thinking more about what you said, I'm no longer optimistic.
First, you are correct that my observation about opposite-side (side
A-ranged ID vs. side B destructor) only works for middleware, and then
only if the compositor and clients already handle their issues
properly.
Secondly,
Has altering the wire format to contain all the info needed for
unambiguous decoding of each message entirely within libwayland without
needing to know the object ID -> type mapping been considered?
It would make the messages longer, but this seems like it wouldn't be
very bad for performance beca
On Mon, 18 Sep 2023 14:06:51 +0300
Pekka Paalanen wrote:
> On Sat, 16 Sep 2023 12:18:35 -0400
> jleivent wrote:
>
> > The easiest fix I can think of is to go full-on half duplex.
> > Meaning that each side doesn't send a single message until it has
> > fully p
On Tue, 19 Sep 2023 16:26:37 +0300
Pekka Paalanen wrote:
> ...
> > But aren't those fast frame updates done through shared fds? Hence
> > not part of the wire protocol, and would not be impacted by
> > increasing the length of messages on the wire?
>
> No. They are messages sent on the wire,
On Tue, 19 Sep 2023 10:02:55 -0400
jleivent wrote:
> ...
> This might help reduce those anomalous messages and be compatible with
> Wayland 1. Reduce the greediness of object ID reuse by:
>
> - not reusing any IDs unless at least some minimum number (256?)
> are free
>
On Wed, 20 Sep 2023 11:30:19 +0300
Pekka Paalanen wrote:
> ..
> > This might help reduce those anomalous messages and be compatible
> > with Wayland 1. Reduce the greediness of object ID reuse by:
> >
> > - not reusing any IDs unless at least some minimum number (256?)
> > are free
> >
> > -
On Wed, 20 Sep 2023 10:05:51 -0400
jleivent wrote:
> ...
> I'm considering forking libwayland and working on one or both of these
> fixes for my own use, because I don't want to implement some even
> crazier things in middleware to compensate for the server ID reuse
> pr
Could I have CI/CD privileges for
https://gitlab.freedesktop.org/jonleivent/wayland-idfix
Thanks
Jon
On Sat, 23 Sep 2023 09:40:20 -0400
jleivent wrote:
> Could I have CI/CD privileges for
> https://gitlab.freedesktop.org/jonleivent/wayland-idfix
>
> Thanks
> Jon
Also:
With respect to the caching scheme described in .gitlab-ci.yaml, should
I change my FDO_DISTRIBUTION_TAG to
On Wed, 20 Sep 2023 10:05:51 -0400
jleivent wrote:
> ..
> Here's a very wild suggestion that would eliminate it and still
> be compatible with Wayland 1. Add a delete_id request without
> modifying the existing protocol.
I have a delete_id request hack, enhanced zombies every
On Tue, 26 Sep 2023 11:53:07 +0300
Pekka Paalanen wrote:
> On Mon, 25 Sep 2023 12:05:30 -0400
> jleivent wrote:
>
> > How do I get CI/CD capability turned on? I tried building the unit
> > tests locally, but get errors that suggest those tests need to be
> > run in
On Wed, 27 Sep 2023 11:47:37 +0300
Pekka Paalanen wrote:
> ..
>
> You just need to tell meson where your build directory is, or cd into
> it first.
>
> $ meson test -C build
>
> or
>
> $ cd build
> $ meson test
>
Of course!
I am trying to write some tests that provoke errors in libwayland, but
it doesn't seem to me like the existing test suite provides a mechanism
to create specific event orderings that are allowed but not guaranteed
by the asynchrony of the protocol. Is that correct? It looks to me
like the tests i
On Wed, 4 Oct 2023 11:26:02 +0300
Pekka Paalanen wrote:
> ...
> For the forked clients, there is stop_display()/display_resume().
> Maybe that helps?
Maybe if I understand their usage correctly. Is this right?: A client
would send a sequence of requests followed by a stop_display request.
Anyth
On Thu, 5 Oct 2023 13:28:57 +0300
Pekka Paalanen wrote:
> ...
> If you flush the Wayland connection explicitly, you should be able to
> reliably avoid the deadlocks. Flushing is public stable API.
Thanks!
I will pattern these tests after the fd_passer display-test, since that
is constructed to
I have a new test thatt is supposed to encounter an error in
the server, causing the server to abort the client and end the test.
The client is at that point in a sleep waiting to be aborted.
Instead, the test hangs (and eventually times out).
If I run it under gdb, and Ctrl-C break during the ha
Can a single interface have an event and a request with the same name?
On Thu, 7 Dec 2023 22:06:07 +
David Edmundson wrote:
> The generated C code be full of conflicts. The
> MY_PROTOCOL_REQUESTEVENT_SINCE_VERSION define for a start.
>
> I think it might compile in C, but other generators exist that might
> not and it's making life much more confusing than it n
On Fri, 8 Dec 2023 12:54:35 +0100
Sebastian Wick wrote:
> ...
> I think a more useful thing to do would be to add this restriction (an
> interface cannot have an event and a request with the same name) to
> the documentation and to wayland-scanner.
>
Also: an event and request with the same name
I submitted this merge request on October 8th:
https://gitlab.freedesktop.org/wayland/wayland/-/merge_request/339
Is there any interest in it?
Thanks,
Jon
Sorry about the typo! It should be:
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/339
On Sun, 24 Dec 2023 15:03:04 +
Joshua Ashton wrote:
> This gives a 404 for me.
>
> On December 19, 2023 8:22:21 PM GMT, jleivent
> wrote:
> >I submitted this merge
Is it legal for a protocol message to contain an array arg where the
contents of the array are Wayland object ids? I don't see any instance
of this in any current protocol descriptions I have.
Thanks for the prompt answer!
On Wed, 27 Dec 2023 18:17:32 +
Simon Ser wrote:
> On Wednesday, December 27th, 2023 at 19:09, jleivent
> wrote:
>
> > Is it legal for a protocol message to contain an array arg where the
> > contents of the array are Wayland object
I've been looking into some of the issues about allowing the socket's
kernel buffer to run out of space, and was wondering why not simply
remove MSG_DONTWAIT from the sendmsg call in wl_connection_flush? That
should implement flow control by having the sender thread wait until
the receiver has emp
Not completely blocking makes sense for the compositor, but why not
block the client?
For the compositor, wouldn't a timeout in the sendmsg make sense?
On Wed, 21 Feb 2024 16:39:08 +0100
Olivier Fourdan wrote:
> Hi,
>
> On Wed, Feb 21, 2024 at 4:21 PM jleivent wrote:
>
>
etter than allowing it to move towards OOM (and thrash).
On Thu, 22 Feb 2024 11:52:28 +0200
Pekka Paalanen wrote:
> On Wed, 21 Feb 2024 11:08:02 -0500
> jleivent wrote:
>
> > Not completely blocking makes sense for the compositor, but why not
> > block the client?
>
> Bl
On Fri, 23 Feb 2024 12:12:38 +0200
Pekka Paalanen wrote:
> I would think it to be quite difficult for a compositor to dedicate a
> whole thread for each client.
But that means it is possible that the server cannot catch up for long
periods. And that just having a large number of otherwise frie
On Mon, 26 Feb 2024 15:12:23 +0200
Pekka Paalanen wrote:
...
> > What is the advantage to having the impacted clients grow their send
> > buffers while waiting? They wait either way.
>
> They are not waiting if they are growing their send buffers.
I meant that they must wait for the UI to up
On Tue, 27 Feb 2024 11:01:18 +0200
Pekka Paalanen wrote:
> > But suppose I'm writing a client that has the possibility of
> > sending a rapid stream of msgs to the compositor that might be,
> > depending on what other clients are doing, too fast for the
> > compositor to handle, and I'd like to
On Fri, 1 Mar 2024 11:59:36 +0200
Pekka Paalanen wrote:
> ...
> The real problem here is though, how do you architect your app or
> toolkit so that it can stop and postpone what it is doing with Wayland
> when you detect that the socket is not draining fast enough? You might
> be calling into Way
32 matches
Mail list logo
