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

[Pekka Paalanen]

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.

> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200130/0a1ac8c0/attachment.sig>