To be clear, the patch does break backwards compatibility with compositor
behavior -- it only weakens a guarantee by saying that transparent
fullscreen content is undefined. Existing compositor behavior is still
allowed.
However, it does mean that clients might not get the output they desire
under
Hi,
Some compositors and client toolkits do rely on the existing wording. Occlusion
culling is used for (obvious) performance reasons in fullscreen cases. If the
fullscreen surface is not opaque, clients can still rely on the compositor's
handling of fullscreen states using the current wording
On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> This changes the semantics in a non-backward compatible way; clients
> relying on the currently defined behavior would break, so I'll have to
> nack this change. You'd have to add a `set_fullscreen_translucent` or
> something like that if the des
Followed-up off-list while fixing issues with my mail client, copying
summary here for posterity:
On Wed Jun 19, 2019 at 5:08 PM Jonas Ådahl wrote:
> Lets not be childish; noone is trying to weasel anything here, and I
> don't understand what you're trying to accomplish by implying that.
I didn't
On Fri, 21 Jun 2019 07:40:12 +
Theo BUENO wrote:
> Yes, unfortunately it is unlikely that open-source drivers with DRM
> support will happen anytime soon for my use-case.
>
> Do you have an idea of the amount of work required to make multi-seat
> and touchscreen binding work on the fbdev bac
On Thu, 2019-06-20 at 12:22 +0300, Pekka Paalanen wrote:
> On Thu, 20 Jun 2019 05:19:09 +
> "Ray, Ian (GE Healthcare)" wrote:
>
> > > On 17 Jun 2019, at 17.45, Theo BUENO wrote:
> > >
> > > Hello everyone,
> > >
> > > I am (relatively) new Weston user working with industrial
> > > embedded
