Fullscreen window (Re: Thread safety when rendering on a separate thread)

[Guillermo Rodriguez]

El jue., 30 ene. 2020 a las 13:33, Pekka Paalanen
(<ppaalanen at gmail.com>) escribió:
>
> On Thu, 30 Jan 2020 12:49:34 +0100
> Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
>
> > El jue., 30 ene. 2020 a las 12:25, Pekka Paalanen
> > (<ppaalanen at gmail.com>) escribió:
> > >
> > > On Thu, 30 Jan 2020 11:46:59 +0100
> > > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> > >
> > > > Just tried this but found that fullscreen windows seem to be made
> > > > fully opaque (black surface behind), which does not work for me.
> > >
> > > Yes, that is very intentional.
> > >
> > > > I have two "pseudo full screen" windows, one is stacked on top of the
> > > > other, and the topmost window needs to have transparent areas.
> > >
> > > The same process or separate processes?
> > >
> > > The same client or separate clients?
> > >
> > > Usually that is managed by making one of the windows a sub-surface for
> > > the other, but that only works within the same client.
> >
> > Yes, but this is not possible in my case. These are two separate
> > applications; one of them (the "main" application) controls the other
> > (a OSD style component which stays on top) by sending commands to it
> > through a CLI.
> > So I cannot easily make one window a sub-surface of the other.
> >
> > >
> > > > So I guess I will need to stick with a toplevel surface and rely on
> > > > Weston keeping the whole window visible..
> > >
> > > That is very unfortunate. We cannot even attempt to keep that working
> > > from upstream side. You are depending on luck for window positioning
> > > and stacking order. Wouldn't a user hitting Mod+Tab or Alt+Tab already
> > > break your setup?
> >
> > Well, there's no keyboard :-)
> >
> > >
> > > Do you prevent pointer and touch input to one of the windows completely
> > > via input regions?
> >
> > Yes; the OSD app does not accept any input.
> >
> > >
> > > Sounds like fixing that properly could mean an architectural re-design
> > > for your application.
> >
> > If that means combining the two applications into one -- I'd rather
> > not do that; there are multiplea reasons why these are designed as
> > independent applications.
> > Ideally I should be able to find a way to setup Wayland to fit the
> > requirements rather than the opposite (tweak the requirements to fit
> > Wayland :-)
>
> Right. Since this is now obviously not about a desktop use case anymore
> but a quite a specialised use case with probably even a closed system,
> you do not have to settle for the normal desktop extensions of Wayland.
>
> The OSD is not a "normal desktop client", so it could use a different
> Wayland extension for managing its window. I believe wlroots has some
> extensions that could apply, and you can always write your own custom
> extensions. Both have the caveat that you need to write the Weston
> implementation as well. The benefit is that then you will have
> guaranteed behaviour: the compositor knows what the OSD actually is and
> has code to specifically keep it where it belongs.
>
> Since the OSD probably does not interact with any other window
> management, I think it might be possible to implement the protocol
> extension as a downstream Weston plugin rather than hacking e.g.
> desktop-shell/shell.c in weston.
>
> If the OSD is actually fullscreen-sized right now but you only need a
> sub-part of that area, meaning that most of the OSD window is completely
> transparent, then with a suitable protocol extension you could avoid
> having the completely transparent areas. Transparent areas still need
> to be composited one way or another, so not having them could be a
> a win in performance or power consumption.

Yes, that makes sense. Is there any documentation or examples on how
to write custom protocol extensions and/or Weston plugins?

Anyway this only solves half of the problem, doesn't it?
I mean: Even if I have a custom protocol extension or plugin to handle
the positioning/ of the OSD window, the "main" application (which also
needs to be fullscreen-sized) still needs to be a regular toplevel
surface, as otherwise it would be shown on top of all other surfaces,
including the OSD window...

BR,

Guillermo Rodriguez Garcia