Add z-order control into kiosk-shell?

[Hoosier, Matt]

Eventually, it was decided that the patch proposed here isn't really appropriate for inclusion into the officially maintained Weston distribution. The clincher was that there's some language in the xdg-shell spec which forbids any surfaces positioned underneath an XDG surface set in fullscreen mode, from showing through.

That discussion spawned a couple of recommendations about how downstream users like me can implementing this style of use-case:


  *   Separately maintain useful -- but technically noncompliant -- patches such as this for public consumption.

  *   Maybe consider making some kind of vaguely kiosk-like shell which has a bunch of internally hooks which can be manipulated by user-defined scripts (perhaps in Lua) to achieve whatever scene-graph manipulations are wanted.

I wanted to float an idea for a third option: using a Wayland-on-Wayland architecture. For lack of better terms, I'm going to refer to the two compositors involved here as "inner" (runs the hardware DRM backend) and "outer" (feeds stuff to the inner compositor) to distinguish this situation from the traditional nested compositor that does all composition directly using the GPU. The inner compositor, which directly runs the physical DRM backend, would be Weston using fullscreen_shell. The outer compositor would be a very thin user-supplied compositor implementing whatever desired project-specific logic. The outer compositor would bind Weston's fullscreen_shell and directly model all application surfaces as subsurfaces of the singular toplevel surface allowed by fullscreen_shell.

Compared to classical nested compositing, this would offer strictly better access to hardware acceleration and 2D hardware optimizations, would require almost no internal bookkeeping in the outer compositor, and would allow us downstream people to write the outer compositor in whatever language seems convenient without intermixing with the raw Weston codebase.

I remember reading somewhere that fullscreen_shell was originally intended to be used in this way, with GDM running the DRM compositor and Mutter doing all its work using Wayland-on-Wayland. That seems to have fizzled out. Does anybody know why? Am I overlooking some obvious show-stopper here?

From: Guillermo Rodriguez <guillerodriguez.dev at gmail.com>
Date: Friday, October 22, 2021 at 7:04 AM
To: "Hoosier, Matt" <Matt.Hoosier at garmin.com>
Cc: "wayland-devel at lists.freedesktop.org" <wayland-devel at lists.freedesktop.org>
Subject: Re: Add z-order control into kiosk-shell?

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.




Hi Matt,

Mi use case is exactly the same as you describe: embedded systems where the output is generated from separate apps. In my case there is:

- The main app with its UI (bottom layer)
- Video output from gstreamer should be rendered on top (I don't want to embed gstreamer in the main app for reliability reasons -- I prefer to keep them as separate processes)
- An OSD may sometimes be needed above the video layer (again this is a separate process; not using gstreamer's OSD facilities for several reasons)

I'm currently using the desktop shell for this but with a number of hacks and patches.

So your proposal sounds really great.

I had originally dismissed kiosk-shell because I thought it only supported a single top-level surface, same as the fullscreen shell. Now I see that I was wrong.

So in summary I think your proposal looks great and adding this functionality into kiosk-shell makes a lot of sense to me.

Guillermo

El vie, 1 oct 2021 a las 21:32, Hoosier, Matt (<Matt.Hoosier at garmin.com<mailto:Matt.Hoosier at garmin.com>>) escribió:
I've been very happy to see kiosk-shell get introduced in the past year or so. It seems to tick nearly every box that I frequently find myself wanting when trying to do embedded deployment of pre-existing Wayland apps which expect to use the customary desktop-centric shells:


  *   declarative control over which output gets which surface
  *   force the apps full-screen by default
  *   no new protocols needed

So this is really nice. Much lower barrier to entry than IVI Shell, and certainly a better re-use story for off-the-rack applications.

But there's a niche that doesn't have any obvious answer yet: controlling the stacking order of different toplevel apps. It's fairly common to construct an embedded system using distributed rendering from separate programs. This means you need a way to control which things go above or below each other to achieve the overall effect.

Would there be any interest in a contribution to enhance kiosk-shell to support configurable stacking orders? This might take the form of either relative specifications ("desktop surface XYZ always goes above desktop surface UWV") or absolute z-order specifications ("desktop surface XYZ's surfaces go into weston_layer #17").

I haven't thought deeply yet about how the syntax for setting the stacking-order configuration in weston.ini would look. Maybe some kind of subscript annotation following the surface ID?

    [output]
    name=LVDS1
    # app1 goes in weston_layer 0. app2 goes in weston_layer 1
    app-ids=org.domain.app1[0],com.domain.app2[1]

Or maybe allow more than one "app-ids" line, keyed by a subscript?

    [output]
    name=LVDS1
    app-ids[layer0]=org.domain.app1,...
    app-ids[layer1]=org.domain.app3,...

-Matt

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20211116/00b9b6a9/attachment-0001.htm>