On Thu, 30 Jan 2020 16:06:19 +0100 Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote:
> El jue., 30 ene. 2020 a las 13:33, Pekka Paalanen > (<ppaala...@gmail.com>) escribió: > > > > On Thu, 30 Jan 2020 12:49:34 +0100 > > Guillermo Rodriguez <guillerodriguez....@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
pgpuhfLaEioSV.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
