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