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

[Guillermo Rodriguez]

Hi,

El jue., 30 ene. 2020 a las 16:48, Pekka Paalanen
(<ppaalanen at gmail.com>) escribió:
>
> On Thu, 30 Jan 2020 16:06:19 +0100
> Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
>
> > 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:
> > >
>
> > > > 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?
>
> Hi,
>
> hmm, that's a good question. Weston repository itself has some plugins
> in-tree. tests/weston-test.c is a small and rough plugin that the test
> suite uses to map test windows bypassing all normal window management.
> It implements the custom test extension from protocol/weston-test.xml.
> Confusingly, the interesting bits for you are in move_surface() which
> also maps the window.
>
> The point of the new extension protocol for an OSD would be to take a
> wl_surface and give it a new role "OSD" for example. "Role" is a term
> defined in the wl_surface specification. Looks like the test plugin
> forgets to use weston_surface_set_role() when it should.
>
> You can grep for weston_surface_set_role() to find other roles and
> their implementations.
>
> Oh, "weston_touch_calibrator" role is probably a much better example
> than the test plugin. A touch calibrator is a fullscreen window used for
> calibrating touchscreens, where the client needs to know both the raw
> touch coordinates and on-screen image coordinates. It needs to grab
> input too.

I see. I'll need to study all of this..

>
> > 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...
>
> You'd be writing some window manager bits, so in Weston you can put the
> OSD view on a layer that is always on top of everything else. Then you
> can make the real main window a proper fullscreen window, and even when
> it is active and "top-most", the OSD will still appear on top of it.

Uhm, I am not sure to understand this bit. Based on your comments
before I am assuming I would implement this as a plugin / addon,
instead of hacking shell.c.
So if my plugin / addon creates a new layer, how do I make Weston
"aware" of this layer ?

Thx,

Guillermo

>
> Weston uses the same mechanism to keep the pointer cursor view on top of
> absolutely everything. (Cursors don't have any special handling outside
> the window management, they are views just like everything else.)
>
>
> Thanks,
> pq