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: > > > El jue., 30 ene. 2020 a las 12:25, Pekka Paalanen > > (<ppaala...@gmail.com>) escribió: > > > > > > On Thu, 30 Jan 2020 11:46:59 +0100 > > > Guillermo Rodriguez <guillerodriguez....@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
