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
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
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
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
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
> > >
On the client side, it is as you said, you'll need to make the request on
the GtkWindow's wl_surface.
On the server side, in the protocol implementation you will get a
wl_resource* surface_resource which corresponds to the wl_surface object.
You can then do `weston_surface *surface =
> On 22 May 2019, at 21:36, Ilia Bozhinov wrote:
>
> If you have a panel/any UI elements, then you most probably have a protocol
> to communicate that the UI element surface is a special surface. You could
> then just extend this protocol so that you specify Z-ordering of these
> surfaces,
