Re: Same ilm surface on multiple layer support

Hi Emre, Could you please suggest on this blocking behavior of LayerManagerControl with multi screen/layer? Thank You. Best Regards, Vikash On Wed, Apr 11, 2018 at 11:35 AM, Vikas Patil wrote: > Hi Emre Ucan, > > Thanks a lot for your quick response. I am able to show

Re: [PATCH v2 0/3] Deal with destroy signal use after free issues

On 2018-04-16 04:29 PM, Markus Ongyerth wrote: > Hi, > > Thanks for getting to this. I was waiting for the release, but I'm currently > not at full capacity, so you got it before me. > > The commit message of patch 1 contains a lie. The second paragraph should > contain "IF there was only one

Re: [PATCH v2 0/3] Deal with destroy signal use after free issues

Hi, Thanks for getting to this. I was waiting for the release, but I'm currently not at full capacity, so you got it before me. The commit message of patch 1 contains a lie. The second paragraph should contain "IF there was only one listener object", which the testcase in Patch 3 shows. But I

Re: [PATCH v2 2/3] server: Add special case destroy signal emitter

> In the past much code (weston, efl/enlightenment, mutter) has > freed structures containing wl_listeners from destroy handlers > without first removing the listener from the signal. As the > destroy notifier only fires once, this has largely gone > unnoticed until recently. > > Other code does

[PATCH v2 3/3] tests: Add free-without-remove test

From: Markus Ongyerth [Derek Foreman moved this into resources-test] --- I moved this behind Markus' back, so let's not go landing it if he's not ok with that change. I think it's a great illustration of the problem and would like to see it land though.

[PATCH v2 2/3] server: Add special case destroy signal emitter

In the past much code (weston, efl/enlightenment, mutter) has freed structures containing wl_listeners from destroy handlers without first removing the listener from the signal. As the destroy notifier only fires once, this has largely gone unnoticed until recently. Other code does not (Qt,

[PATCH v2 0/3] Deal with destroy signal use after free issues

Now that the release is out, I'd like to dig back into this mess. This is a round up of some patches that were on list shortly before the release to deal with a problem where many existing libwayland users don't delete their destroy signal listeners before freeing them. These leads to a bit of a

[PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

This tries to align with the X.org communities's long-standing tradition of trying to be an inclusive community and handing out commit rights fairly freely. We also tend to not revoke commit rights for people no longer regularly active in a given project, as long as they're still part of the

Re: [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

On 2018-04-13 06:00 AM, Daniel Vetter wrote: > This tries to align with the X.org communities's long-standing > tradition of trying to be an inclusive community and handing out > commit rights fairly freely. > > We also tend to not revoke commit rights for people no longer > regularly active in a

Re: [PATCHv4] Add name event to xdg-output

On 2018-04-16 2:57 PM, Jonas Ådahl wrote: > I'd still like a bit more clarification about what to expect of this > string. What I'm trying to avoid is one compositor sending "eDP-1" while > another sends "Built-in Display". For example, the first is suitable for > command line interfaces (e.g.

Re: [PATCHv4] Add name event to xdg-output

On Sat, Apr 14, 2018 at 10:15:08AM -0400, Drew DeVault wrote: > Signed-off-by: Drew DeVault > Reviewed-by: Simon Ser > --- > This revision addresses Pekka's feedback, specifying that the output > name will not change over the lifetime of the xdg_output. This

Re: [PATCHv4] Add name event to xdg-output

On 2018-04-16 10:53 AM, Pekka Paalanen wrote: > That's very clear, but is it precisely your intention? Would it make > more sense to define that the name does not change during the lifetime > of the wl_output global instead? That would guarantee that the name > will stay the same for the same

Re: [PATCHv3] Add name event to xdg-output

On 2018-04-16 10:36 AM, Pekka Paalanen wrote: > that's seems contradictory to what you replied here: You're right, it does. > > You could do this but it would be exceedingly silly of you considering > > that the other xdg_output requests furnish the client with layout > > information anyway. >

Re: [PATCHv3] Add name event to xdg-output

On Fri, 13 Apr 2018 16:16:34 +0200 Jonas Ådahl wrote: > On Fri, Apr 13, 2018 at 10:05:39AM -0400, Drew DeVault wrote: > > On 2018-04-13 4:02 PM, Jonas Ådahl wrote: > > > > > > > - Xwayland can name the X11 outputs based on their genuine names rather > > > > than

Re: [PATCHv4] Add name event to xdg-output

Hi, one elementary detail I have missed is that you have no commit message. For the record, you should give a justification for why xdg_output needs a name event added. On Sat, 14 Apr 2018 10:15:08 -0400 Drew DeVault wrote: > Signed-off-by: Drew DeVault >

Re: [PATCHv3] Add name event to xdg-output

On Sat, 14 Apr 2018 10:08:35 -0400 Drew DeVault wrote: > On 2018-04-13 4:33 PM, Pekka Paalanen wrote: > > The other events have more precise wording here, allowing the event to > > be sent again if the information changes. > > This is deliberate - I don't think the name