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!
On Tue, 26 Sep 2023 10:56:03 -0400
jleivent wrote:
> 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
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 CI. Issue 540 says I need t
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 CI. Issue 540 says I need to apply for the guest role - how do I do
> that?
I don't recall libway
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 everywhere, a LRU
ring f
On 9/20/23 18:29, jleivent wrote:
> 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 se
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
> problem.
>
I keep getting
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 Tue, 19 Sep 2023 10:02:55 -0400
jleivent wrote:
> 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
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
>
> - reuse the freed one
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 Mon, 18 Sep 2023 11:31:18 -0400
jleivent wrote:
> 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 sin
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 processed all messages sent to it in
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
> processed all messages sent to it in the order they arrive (thankfully,
> sockets preserve message order,
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
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,
On Thu, 14 Sep 2023 15:10:48 -0400
jleivent wrote:
> On Thu, 14 Sep 2023 16:32:06 +0300
> Pekka Paalanen wrote:
>
> >
> > As an aside, we collect unfixable issues under
> > https://gitlab.freedesktop.org/wayland/wayland/-/issues/?label_name%5B%5D=Protocol-next
> > These are issues that are eit
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
>
On Wed, 13 Sep 2023 20:16:09 -0400
jleivent wrote:
> Forgive the long post. Tl;dr: what are the rules of object ID lifetime
> and reuse in the Wayland protocol?
Hi,
congratulations, I think you may have found everything that is not
quite right in the fundamental Wayland protocol design. :-)
A
19 matches
Mail list logo
