can subsurface and shell surface be used together to manage surfaces

[zou lan]

Hi Daniel

Thank you for reply my question about 'SPURV'.

If 'SPURV' only support one active application on one display, does it
consider to support multiple displays?
can I ask if there is any plan to update 'SPURV' to match hwc2 or the
latest Android version?

Thank you!

Best Regards
Nancy

Daniel Stone <daniel at fooishbar.org> 于2020年4月29日周三 下午5:11写道：

> Hi,
>
> On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Mon, 27 Apr 2020 15:07:20 +0800 zou lan <nancy.lan.zou at gmail.com>
> wrote:
> > > I read some documents about chrome OS run Android Apks such as
> > >
> https://qiangbo-workspace.oss-cn-shanghai.aliyuncs.com/2019-09-10-chromeos-with-android-app/Arcpp_Graphics.pdf
> > >  As far as I known, chrominum could run upon wayland,  I just
> wondering how
> > > it handle Android windows on wayland.
> > > I think the surface of Android apks could be wayland surface in linux,
> the
> > > window could be the shell surface.
> > >  Since all the android apks are still running on android container,
> android
> > > window manager will manage these windows, in wayland, the relationship
> of
> > > these surfaces should be parent-       subsurface that map to android
> > > windows. That's a little of problem, as you are confirmed, one wl
> surface
> > > can't be both subsurface and shell surface.
> > > If each android apks are not subsurfaces, I am confused how Android to
> > > handle the input events from wayland.
> >
> > you'll have to ask or wait for someone who knows ARC++ to answer. I
> > don't dare extrapolate details based on that one simple PDF alone.
> >
> > Android window management is very different from desktop window
> > management, and I don't even know if CrOS window management is close
> > to either. Using custom Wayland extensions is always a possibility, it
> > happens even on the desktops, e.g. GNOME/GTK.
> >
> > Look at the slide titled "Chromium Wayland Interfaces", for instance.
>
> ARC++ is proprietary, and I haven't seen its source code either.
>
> But looking at
> https://github.com/chromium/chromium/blob/master/components/exo/wayland/protocol/aura-shell.xml
> I would very much expect that the ARC++ client implementation uses
> this as an extra to support Android applications running under
> Chromium - for example, the titlebar-colour request is certainly
> fulfilling an Android need.
>
> Integrating Android into a desktop system is non-trivial. You will
> have to make quite a lot of changes along the way: Android assumes
> that you have one, or maybe two, applications open, and a status bar,
> and maybe a button bar, and that's it. If you want to make Android
> behave more like a desktop, then you're going to have to change
> Android to fit your desktop, and you're going to have to change your
> desktop to accommodate Android.
>
> I believe the ARC++ solution of using multiple top-level windows, and
> having the window management be primarily done by the host compositor,
> is a better option than trying to use subsurfaces to invert
> responsibility and effectively control the window management from
> Android.
>
> However, there is no out-of-the-box solution. Whatever you do is going
> to require custom development and experimentation. 'SPURV' is a
> periodically-refreshed effort from Collabora to see what this
> integration would look like, however we never addressed the idea of
> having multiple active applications, as it requires too many changes
> in Android, such as deep changes to the Android activity manager to
> deal with more than one application being current at one time.
>
> Cheers,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200515/81f2e362/attachment.htm>