Hi, El jue., 30 ene. 2020 a las 16:48, Pekka Paalanen (<ppaala...@gmail.com>) escribió: > > 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.
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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
