Re: can subsurface and shell surface be used together to manage surfaces
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 于2020年4月29日周三 下午5:11写道： > Hi, > > On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen wrote: > > On Mon, 27 Apr 2020 15:07:20 +0800 zou lan > 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 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
Hi, On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen wrote: > On Mon, 27 Apr 2020 15:07:20 +0800 zou lan 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
On Mon, 27 Apr 2020 15:07:20 +0800 zou lan 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. Hi, 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. Thanks, pq pgp4mAhmB3Usi.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
Hi pekka > >>Another compositor? Do you mean another client? > Another compositor means compositor such as HWC or netsed compositor. > > >>What are you trying to do? > > >>Do you have some sort of middle-man compositor as a third player here? > > >>I don't understand at all. > 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. Thank you! Best Regards Nancy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
On Sun, 12 Apr 2020 17:13:04 +0800 zou lan wrote: > Hi Matt > > yes, I want to bind a wl_surface to a subsurface first, then create a shell > surface for it. No, you can't do that. > I want to do that is because if the wl surface is created by another > compositor, it had been declared as a subsurface to map its position of Another compositor? Do you mean another client? > original compositor. Then weston shell can't > manage the surface as a window directly, I was just wondering how can make > weston shell could manage these kind of surfaces as separate windows too. > It seems create shell surface for each wl surface is not a good idea in > this case. Thank you for confirmation! What are you trying to do? Do you have some sort of middle-man compositor as a third player here? I don't understand at all. Thanks, pq pgp2RRrFoI8i2.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
Hi Matt yes, I want to bind a wl_surface to a subsurface first, then create a shell surface for it. I want to do that is because if the wl surface is created by another compositor, it had been declared as a subsurface to map its position of original compositor. Then weston shell can't manage the surface as a window directly, I was just wondering how can make weston shell could manage these kind of surfaces as separate windows too. It seems create shell surface for each wl surface is not a good idea in this case. Thank you for confirmation! Best Regards Nancy Matt Hoosier 于2020年4月11日周六 下午9:38写道： > If you’re asking whether it’s possible to migrate a given wl_surface from > being a subsurface (initially) to later being a shell surface, this isn’t > allowed. This has to do with the immutability of a surface’s so-called > “role.” (Surfaces are only ever allowed to be registered with one given > role. ) > > -Matt > > On Fri, Apr 10, 2020 at 5:43 AM zou lan wrote: > >> Hi pekka & all >> >> I want to use subsurface to manage the initial position of each surface >> on screen, then I want to create shell surface for each wl surface to >> manage them seperately, such as response touch event, ivi-shell can modify >> the z-order of each surface and move each ivi surface to different displays. >> >> Is it ok to use subsurface like this? If the shell surfaces' z-order have >> been modified by desktop shell or ivi-shell, will the z-order of >> subsurfaces be modified too? >> >> thank you! >> >> Best Regards >> Nancy >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
If you’re asking whether it’s possible to migrate a given wl_surface from being a subsurface (initially) to later being a shell surface, this isn’t allowed. This has to do with the immutability of a surface’s so-called “role.” (Surfaces are only ever allowed to be registered with one given role. ) -Matt On Fri, Apr 10, 2020 at 5:43 AM zou lan wrote: > Hi pekka & all > > I want to use subsurface to manage the initial position of each surface on > screen, then I want to create shell surface for each wl surface to manage > them seperately, such as response touch event, ivi-shell can modify the > z-order of each surface and move each ivi surface to different displays. > > Is it ok to use subsurface like this? If the shell surfaces' z-order have > been modified by desktop shell or ivi-shell, will the z-order of > subsurfaces be modified too? > > thank you! > > Best Regards > Nancy > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
