Discussion:
[ozone-dev] Re: [chromium-dev] Chrome with custom ozone implementation on Linux
Antonio Gomes
2017-10-19 13:07:43 UTC
Permalink
cc: ozone-dev
bcc: chromium-dev (subject deviates slightly chromium-dev, since
chromium/wayland is still a downstream work, but I kept BCC for the
sake of our future intent to upstream)

Quick check are you launching with --mash or --mus parameter? (from
the error it seems like you are trying the former, whereas the later
should be used.

FTR, here is my launch command line:

$ <out>/chrome --mus --ozone-platform=wayland -user-data-dir=~/tmp <urls>

... and here is my GN flags:

is_debug = false
is_component_build = false
symbol_level = 1
dcheck_always_on = true

use_ozone = true
ozone_platform_wayland = true
ozone_platform_x11 = true
ozone_platform_gbm = false
ozone_platform_headless = true
ozone_auto_platforms = false

use_xkbcommon = true

enable_package_mash_services = true

use_sysroot = true
treat_warnings_as_errors = false
is_clang = true

enable_nacl = false
remove_webcore_debug_symbols = true

use_jumbo_build = true

proprietary_codecs = true
ffmpeg_branding = "Chrome"

Please let me know,
Hi Antonio,
I did try https://github.com/Igalia/chromium with my platform. It builds
[3886:3893:0103/032058.840266:184830803554:ERROR:service_manager.cc(156)]
Connection InterfaceProviderSpec prevented service: quick_launch from
binding interface: ui::mojom::ExternalWindowTreeFactory exposed
by: ui
I'm not sure it's relevant but it's not running, it seems to stuck
somewhere.
Regards,
Vlad
пятница, 13 октября 2017 г., 15:53:05 UTC+3 пользователь Antonio Gomes
Hi Vlad.
TL;DR: The state of Ozone/Linux in ToT is not so useful to your needs
today. There is a buildbot [0], and it builds 'chrome mash:all
services_unitests and ozone_unittests' targets, but only runs a
handful of other unittests at the moment, obviously, making use of
Mus/Ozone codepath.
$ <out>/mash --service=mus_demo --ozone-platform={x11,wayland}
Please have a look at [1]. This is an ongoing effort ran by Igalia
whose goal is to extend both Ozone and Mus to support what we are
calling 'external window mode***', targeting Linux. Note that Chrome
itself isn't changed, since it works as it ought to in both 'internal'
and 'external' window modes.
Project is stable, and our implementation is pretty much functional
today: we have a well defined rebase and contribution policies, where
we rebase against ToT in a weekly basis, run unittests (namely
services_unittests, ozone_unittests, mus_demo) as well perform
continuous integration in our bot [2]. You can see the progresses here
[3][4].
In Q3, we worked a lot in stabilizing our implementation, and for Q4,
the Ozone bits are going to be proposed upstream. MUS changes are also
going to be discussed here in chromium-dev later this quarter.
I welcome you to try and provide feedback of our implementation, as we
work out its upstreaming plan.
*** 'internal window mode' is is the terminology being used when an
application runs within the Ash shell environment, the built-in Window
Manager (WM) that powers ChromeOS builds. Applications in this mode do
not interact with the host WM.
***Analogously, external window mode is the terminology being used to
represent a regular desktop application on Linux, where the host
Window Manager (WM) takes care of windowing actions like maximize,
minimize, restore and fullscreen of the application window. Also, the
application itself reacts to content size changes accordingly.
[0]
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux?numbuilds=200
[1] https://github.com/Igalia/chromium
[2] https://build-chromium.igalia.com/
[3]
(chromium/ozone/wayland)
[4]
(chromium/ozone/x11)
Hi All,
I was wondering if anybody could clarify for me current status of chrome
running on Linux with Ozone as UI interface. I had my own platform
(embedded) for which I have implemented Ozone porting. I had used it a
long
time ago with Chromium 43 and it worked fine. Now I want to switch to
version 62. I can see new concept appearing like Mus and Mash. I also
can
see, that for instance build with X11 as Ozone implementation should
work,
but I struggle to understand how. I basically generate build with
following
gn args out/Release_GN_x64 --args="use_ozone=true
enable_package_mash_services=true ozone_platform_myplatform=true" + more
parameters to set custom toolchain
and ozone_platform_myplatform is properly defined in gn and gni files
and
ninja -C out/Release_GN_x64 chrome mus_demo mash:all chrome_sandbox
services/ui/demo
It builds fine, but when I run it on target device, it crashes in
BrowserFrame::InitBrowserFrame when doing
NativeBrowserFrameFactory::CreateNativeBrowserFrame because factory for
ozone (native_browser_frame_factory_ozone.cc) says that
it can only create frame if aura::Env::GetInstance()->mode() ==
aura::Env::Mode::MUS and log is "For Ozone builds, only --mash launch is
supported for now.". Now, I tried running it with "--mash" option as
suggested before and it does not help, because as far as I understand,
the
only way for environment to be MUS is set in chrome_main.cc, but it is
guarded by #ifdef OS_CHROMEOS. Does it mean it never works for Linux?
I'm
puzzled with this one.
I can manually remove some checks for environment to be MUS to make it
go
further but it didn't help much. With "--mus" as a running parameter, ui
service is not running, so nothing is showing, but it seems to run (e.g.
dev
tools works). When removing some checks, "--mash" also works partially
but
it seems to hang somewhere. So, in general I think it's not the way to
patch
the code like this. What worries me is that at
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/ozone_overview.md
instruction says it should work (for X11) but considering that check
with
#if defined(OS_CHROMEOS), I have no idea how, it can never pass that not
implemented part in native_browser_frame_factory_ozone.cc.
Much appreciate any input on this problem
Vlad
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google
Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/643651ba-fb20-4595-b2cc-b3e224c2d10a%40chromium.org.
--
--Antonio Gomes
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e960db4f-196f-42de-821b-684a7794f880%40chromium.org.
--
--Antonio Gomes
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Vlad Bezuglyy
2017-10-20 09:44:37 UTC
Permalink
Hi Antonio,

You're right, with --mus it works (sort of). By works I mean that it
launches, no crash, I can see by remote debugging that page is loaded in
dev tools and elements have non-zero size. But it does not draw anything. I
can see in logs that my ozone platform is created and surface factory is
created (InitializeUI is called). I had a question yesterday whether it
should work with --use-skia-renderer? For now I only have implemented CreateCanvasForWidget
from SurfaceFactoryOzone, also I have some stubs
in GetAllowedGLImplementations, GetGLOzone, I don't have my own gl
implementation. My surface is SurfaceOzoneCanvas and implements ResizeCanvas
and PresentCanvas, but I dont see CreateCanvasForWidget called at all.

I also tried to run mus_demo, same result and logs I have:
[1598:1598:0101/184049.887739:67220851080:ERROR:screen_base.cc(44)] Not
implemented reached in virtual display::Display
display::ScreenBase::GetDisplayNearestWindow(gfx::NativeWindow) const
[1598:1598:0101/184051.888435:67222851715:ERROR:layer_tree_host_impl.cc(2405)]
Forcing zero-copy tile initialization as worker context is missing
[1598:1598:0101/184051.905120:67222868406:ERROR:layer_tree_host_impl.cc(2405)]
Forcing zero-copy tile initialization as worker context is missing


Regads,
Vlad

четверг, 19 Пктября 2017 г., 16:09:11 UTC+3 пПльзПватель Antonio Gomes
Post by Antonio Gomes
cc: ozone-dev
bcc: chromium-dev (subject deviates slightly chromium-dev, since
chromium/wayland is still a downstream work, but I kept BCC for the
sake of our future intent to upstream)
Quick check are you launching with --mash or --mus parameter? (from
the error it seems like you are trying the former, whereas the later
should be used.
$ <out>/chrome --mus --ozone-platform=wayland -user-data-dir=~/tmp <urls>
is_debug = false
is_component_build = false
symbol_level = 1
dcheck_always_on = true
use_ozone = true
ozone_platform_wayland = true
ozone_platform_x11 = true
ozone_platform_gbm = false
ozone_platform_headless = true
ozone_auto_platforms = false
use_xkbcommon = true
enable_package_mash_services = true
use_sysroot = true
treat_warnings_as_errors = false
is_clang = true
enable_nacl = false
remove_webcore_debug_symbols = true
use_jumbo_build = true
proprietary_codecs = true
ffmpeg_branding = "Chrome"
Please let me know,
Hi Antonio,
I did try https://github.com/Igalia/chromium with my platform. It
builds
[3886:3893:0103/032058.840266:184830803554:ERROR:service_manager.cc(156)]
Connection InterfaceProviderSpec prevented service: quick_launch from
binding interface: ui::mojom::ExternalWindowTreeFactory exposed
by: ui
I'm not sure it's relevant but it's not running, it seems to stuck
somewhere.
Regards,
Vlad
пятМОца, 13 Пктября 2017 г., 15:53:05 UTC+3 пПльзПватель Antonio Gomes
Hi Vlad.
TL;DR: The state of Ozone/Linux in ToT is not so useful to your needs
today. There is a buildbot [0], and it builds 'chrome mash:all
services_unitests and ozone_unittests' targets, but only runs a
handful of other unittests at the moment, obviously, making use of
Mus/Ozone codepath.
$ <out>/mash --service=mus_demo --ozone-platform={x11,wayland}
Please have a look at [1]. This is an ongoing effort ran by Igalia
whose goal is to extend both Ozone and Mus to support what we are
calling 'external window mode***', targeting Linux. Note that Chrome
itself isn't changed, since it works as it ought to in both 'internal'
and 'external' window modes.
Project is stable, and our implementation is pretty much functional
today: we have a well defined rebase and contribution policies, where
we rebase against ToT in a weekly basis, run unittests (namely
services_unittests, ozone_unittests, mus_demo) as well perform
continuous integration in our bot [2]. You can see the progresses here
[3][4].
In Q3, we worked a lot in stabilizing our implementation, and for Q4,
the Ozone bits are going to be proposed upstream. MUS changes are also
going to be discussed here in chromium-dev later this quarter.
I welcome you to try and provide feedback of our implementation, as we
work out its upstreaming plan.
*** 'internal window mode' is is the terminology being used when an
application runs within the Ash shell environment, the built-in Window
Manager (WM) that powers ChromeOS builds. Applications in this mode do
not interact with the host WM.
***Analogously, external window mode is the terminology being used to
represent a regular desktop application on Linux, where the host
Window Manager (WM) takes care of windowing actions like maximize,
minimize, restore and fullscreen of the application window. Also, the
application itself reacts to content size changes accordingly.
[0]
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux?numbuilds=200
[1] https://github.com/Igalia/chromium
[2] https://build-chromium.igalia.com/
[3] http://youtu.be/bPK966yHQM4
(chromium/ozone/wayland)
[4] http://youtu.be/FlsnQopAMJk (chromium/ozone/x11)
Hi All,
I was wondering if anybody could clarify for me current status of
chrome
running on Linux with Ozone as UI interface. I had my own platform
(embedded) for which I have implemented Ozone porting. I had used it
a
long
time ago with Chromium 43 and it worked fine. Now I want to switch to
version 62. I can see new concept appearing like Mus and Mash. I also
can
see, that for instance build with X11 as Ozone implementation should
work,
but I struggle to understand how. I basically generate build with
following
arguments (the build is on Linux machine, cross-compiling to arm
gn args out/Release_GN_x64 --args="use_ozone=true
enable_package_mash_services=true ozone_platform_myplatform=true" +
more
parameters to set custom toolchain
and ozone_platform_myplatform is properly defined in gn and gni files
and
ninja -C out/Release_GN_x64 chrome mus_demo mash:all chrome_sandbox
services/ui/demo
It builds fine, but when I run it on target device, it crashes in
BrowserFrame::InitBrowserFrame when doing
NativeBrowserFrameFactory::CreateNativeBrowserFrame because factory
for
ozone (native_browser_frame_factory_ozone.cc) says that
it can only create frame if aura::Env::GetInstance()->mode() ==
aura::Env::Mode::MUS and log is "For Ozone builds, only --mash launch
is
supported for now.". Now, I tried running it with "--mash" option as
suggested before and it does not help, because as far as I
understand,
the
only way for environment to be MUS is set in chrome_main.cc, but it
is
guarded by #ifdef OS_CHROMEOS. Does it mean it never works for Linux?
I'm
puzzled with this one.
I can manually remove some checks for environment to be MUS to make
it
go
further but it didn't help much. With "--mus" as a running parameter,
ui
service is not running, so nothing is showing, but it seems to run
(e.g.
dev
tools works). When removing some checks, "--mash" also works
partially
but
it seems to hang somewhere. So, in general I think it's not the way
to
patch
the code like this. What worries me is that at
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/ozone_overview.md
instruction says it should work (for X11) but considering that check
with
#if defined(OS_CHROMEOS), I have no idea how, it can never pass that
not
implemented part in native_browser_frame_factory_ozone.cc.
Much appreciate any input on this problem
Vlad
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/643651ba-fb20-4595-b2cc-b3e224c2d10a%40chromium.org.
--
--Antonio Gomes
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google
Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e960db4f-196f-42de-821b-684a7794f880%40chromium.org.
--
--Antonio Gomes
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Maksim Sisov
2017-10-20 12:27:32 UTC
Permalink
Hi,

To make things clear - after a chat in a private channel it turned out
that Vlad uses own ozone implementation, which is based on
ozone-wayland-dev-betaXXX release that we have in
https://github.com/Igalia/chromium . He doesn't use ozone/wayland that
we currently have, but has some sort of own implementation with own
backend. He is able to partly initialize it, but surface is not drawn.

Br,
Maksim
Hi Antonio,
You're right, with --mus it works (sort of). By works I mean that it
launches, no crash, I can see by remote debugging that page is loaded
in dev tools and elements have non-zero size. But it does not draw
anything. I can see in logs that my ozone platform is created and
surface factory is created (InitializeUI is called). I had a question
yesterday whether it should work with --use-skia-renderer? For now I
only have implemented CreateCanvasForWidget from SurfaceFactoryOzone,
also I have some stubs in GetAllowedGLImplementations, GetGLOzone, I
don't have my own gl implementation. My surface is SurfaceOzoneCanvas
and implements ResizeCanvas and PresentCanvas, but I dont see
CreateCanvasForWidget called at all.
[1598:1598:0101/184049.887739:67220851080:ERROR:screen_base.cc(44)]
Not implemented reached in virtual display::Display
display::ScreenBase::GetDisplayNearestWindow(gfx::NativeWindow) const
[1598:1598:0101/184051.888435:67222851715:ERROR:layer_tree_host_impl.cc(2405)]
Forcing zero-copy tile initialization as worker context is missing
[1598:1598:0101/184051.905120:67222868406:ERROR:layer_tree_host_impl.cc(2405)]
Forcing zero-copy tile initialization as worker context is missing
Regads,
Vlad
четверг, 19 октября 2017 г., 16:09:11 UTC+3
Post by Antonio Gomes
cc: ozone-dev
bcc: chromium-dev (subject deviates slightly chromium-dev, since
chromium/wayland is still a downstream work, but I kept BCC for the
sake of our future intent to upstream)
Quick check are you launching with --mash or --mus parameter? (from
the error it seems like you are trying the former, whereas the later
should be used.
$ <out>/chrome --mus --ozone-platform=wayland -user-data-dir=~/tmp <urls>
is_debug = false
is_component_build = false
symbol_level = 1
dcheck_always_on = true
use_ozone = true
ozone_platform_wayland = true
ozone_platform_x11 = true
ozone_platform_gbm = false
ozone_platform_headless = true
ozone_auto_platforms = false
use_xkbcommon = true
enable_package_mash_services = true
use_sysroot = true
treat_warnings_as_errors = false
is_clang = true
enable_nacl = false
remove_webcore_debug_symbols = true
use_jumbo_build = true
proprietary_codecs = true
ffmpeg_branding = "Chrome"
Please let me know,
Hi Antonio,
I did try https://github.com/Igalia/chromium [1] with my
platform. It builds
fine but still not running. I do get some strange error message
[3886:3893:0103/032058.840266:184830803554:ERROR:service_manager.cc(156)]
Post by Antonio Gomes
Connection InterfaceProviderSpec prevented service: quick_launch
from
binding interface: ui::mojom::ExternalWindowTreeFactory exposed
by: ui
I'm not sure it's relevant but it's not running, it seems to stuck
somewhere.
Regards,
Vlad
пятница, 13 октября 2017 г., 15:53:05 UTC+3
пользователь Antonio Gomes
Hi Vlad.
TL;DR: The state of Ozone/Linux in ToT is not so useful to your
needs
today. There is a buildbot [0], and it builds 'chrome mash:all
services_unitests and ozone_unittests' targets, but only runs a
handful of other unittests at the moment, obviously, making use
of
Mus/Ozone codepath.
$ <out>/mash --service=mus_demo --ozone-platform={x11,wayland}
Please have a look at [1]. This is an ongoing effort ran by
Igalia
whose goal is to extend both Ozone and Mus to support what we are
calling 'external window mode***', targeting Linux. Note that
Chrome
itself isn't changed, since it works as it ought to in both
'internal'
and 'external' window modes.
Project is stable, and our implementation is pretty much
functional
today: we have a well defined rebase and contribution policies,
where
we rebase against ToT in a weekly basis, run unittests (namely
services_unittests, ozone_unittests, mus_demo) as well perform
continuous integration in our bot [2]. You can see the progresses
here
[3][4].
In Q3, we worked a lot in stabilizing our implementation, and for
Q4,
the Ozone bits are going to be proposed upstream. MUS changes are
also
going to be discussed here in chromium-dev later this quarter.
I welcome you to try and provide feedback of our implementation,
as we
work out its upstreaming plan.
*** 'internal window mode' is is the terminology being used when
an
application runs within the Ash shell environment, the built-in
Window
Manager (WM) that powers ChromeOS builds. Applications in this
mode do
not interact with the host WM.
***Analogously, external window mode is the terminology being
used to
represent a regular desktop application on Linux, where the host
Window Manager (WM) takes care of windowing actions like
maximize,
minimize, restore and fullscreen of the application window. Also,
the
application itself reacts to content size changes accordingly.
[0]
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux?numbuilds=200
Post by Antonio Gomes
[2]
[1] https://github.com/Igalia/chromium [1]
[2] https://build-chromium.igalia.com/ [3]
[3] http://youtu.be/bPK966yHQM4 [4]
(chromium/ozone/wayland)
[4] http://youtu.be/FlsnQopAMJk [5]
(chromium/ozone/x11)
On Fri, Oct 13, 2017 at 3:56 AM, Vlad Bezuglyy
Hi All,
I was wondering if anybody could clarify for me current status
of chrome
running on Linux with Ozone as UI interface. I had my own
platform
(embedded) for which I have implemented Ozone porting. I had
used it a
long
time ago with Chromium 43 and it worked fine. Now I want to
switch to
version 62. I can see new concept appearing like Mus and Mash.
I also
can
see, that for instance build with X11 as Ozone implementation
should
work,
but I struggle to understand how. I basically generate build
with
following
arguments (the build is on Linux machine, cross-compiling to
gn args out/Release_GN_x64 --args="use_ozone=true
enable_package_mash_services=true
ozone_platform_myplatform=true" + more
parameters to set custom toolchain
and ozone_platform_myplatform is properly defined in gn and gni
files
and
ninja -C out/Release_GN_x64 chrome mus_demo mash:all
chrome_sandbox
services/ui/demo
It builds fine, but when I run it on target device, it crashes
in
BrowserFrame::InitBrowserFrame when doing
NativeBrowserFrameFactory::CreateNativeBrowserFrame because
factory for
ozone (native_browser_frame_factory_ozone.cc) says that
it can only create frame if aura::Env::GetInstance()->mode() ==
aura::Env::Mode::MUS and log is "For Ozone builds, only --mash
launch is
supported for now.". Now, I tried running it with "--mash"
option as
suggested before and it does not help, because as far as I
understand,
the
only way for environment to be MUS is set in chrome_main.cc,
but it is
guarded by #ifdef OS_CHROMEOS. Does it mean it never works for
Linux?
I'm
puzzled with this one.
I can manually remove some checks for environment to be MUS to
make it
go
further but it didn't help much. With "--mus" as a running
parameter, ui
service is not running, so nothing is showing, but it seems to
run (e.g.
dev
tools works). When removing some checks, "--mash" also works
partially
but
it seems to hang somewhere. So, in general I think it's not the
way to
patch
the code like this. What worries me is that at
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/ozone_overview.md
Post by Antonio Gomes
[6]
instruction says it should work (for X11) but considering that
check
with
#if defined(OS_CHROMEOS), I have no idea how, it can never pass
that not
implemented part in native_browser_frame_factory_ozone.cc.
Much appreciate any input on this problem
Vlad
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev [7]
---
You received this message because you are subscribed to the
Google
Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/643651ba-fb20-4595-b2cc-b3e224c2d10a%40chromium.org
Post by Antonio Gomes
[8].
--
--Antonio Gomes
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev [7]
---
You received this message because you are subscribed to the Google
Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e960db4f-196f-42de-821b-684a7794f880%40chromium.org
Post by Antonio Gomes
[9].
--
--Antonio Gomes
--
You received this message because you are subscribed to the Google
Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send
------
[1] https://github.com/Igalia/chromium
[2]
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux?numbuilds=200
[3] https://build-chromium.igalia.com/
[4] http://youtu.be/bPK966yHQM4
[5] http://youtu.be/FlsnQopAMJk
[6] https://chromium.googlesource.com/chromium/src/+/lkcr/docs/ozone_overview.md
[7] http://groups.google.com/a/chromium.org/group/chromium-dev
[8]
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/643651ba-fb20-4595-b2cc-b3e224c2d10a%40chromium.org
[9]
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e960db4f-196f-42de-821b-684a7794f880%40chromium.org
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Vlad Bezuglyy
2017-10-23 07:20:52 UTC
Permalink
Hi Antonio, Maksim,

I have also tried to use "headless" platfrom from Igalia port (branch
ozone-wayland-beta-62.0.3202.29-release). It doesn't seem to work for me
(i.e. it does not produce any dump files). I was wondering if software
rendering path is implemented in your port. Could you comment on this?

Regards,
Vlad

четверг, 19 Пктября 2017 г., 16:09:11 UTC+3 пПльзПватель Antonio Gomes
Post by Antonio Gomes
cc: ozone-dev
bcc: chromium-dev (subject deviates slightly chromium-dev, since
chromium/wayland is still a downstream work, but I kept BCC for the
sake of our future intent to upstream)
Quick check are you launching with --mash or --mus parameter? (from
the error it seems like you are trying the former, whereas the later
should be used.
$ <out>/chrome --mus --ozone-platform=wayland -user-data-dir=~/tmp <urls>
is_debug = false
is_component_build = false
symbol_level = 1
dcheck_always_on = true
use_ozone = true
ozone_platform_wayland = true
ozone_platform_x11 = true
ozone_platform_gbm = false
ozone_platform_headless = true
ozone_auto_platforms = false
use_xkbcommon = true
enable_package_mash_services = true
use_sysroot = true
treat_warnings_as_errors = false
is_clang = true
enable_nacl = false
remove_webcore_debug_symbols = true
use_jumbo_build = true
proprietary_codecs = true
ffmpeg_branding = "Chrome"
Please let me know,
Hi Antonio,
I did try https://github.com/Igalia/chromium with my platform. It
builds
[3886:3893:0103/032058.840266:184830803554:ERROR:service_manager.cc(156)]
Connection InterfaceProviderSpec prevented service: quick_launch from
binding interface: ui::mojom::ExternalWindowTreeFactory exposed
by: ui
I'm not sure it's relevant but it's not running, it seems to stuck
somewhere.
Regards,
Vlad
пятМОца, 13 Пктября 2017 г., 15:53:05 UTC+3 пПльзПватель Antonio Gomes
Hi Vlad.
TL;DR: The state of Ozone/Linux in ToT is not so useful to your needs
today. There is a buildbot [0], and it builds 'chrome mash:all
services_unitests and ozone_unittests' targets, but only runs a
handful of other unittests at the moment, obviously, making use of
Mus/Ozone codepath.
$ <out>/mash --service=mus_demo --ozone-platform={x11,wayland}
Please have a look at [1]. This is an ongoing effort ran by Igalia
whose goal is to extend both Ozone and Mus to support what we are
calling 'external window mode***', targeting Linux. Note that Chrome
itself isn't changed, since it works as it ought to in both 'internal'
and 'external' window modes.
Project is stable, and our implementation is pretty much functional
today: we have a well defined rebase and contribution policies, where
we rebase against ToT in a weekly basis, run unittests (namely
services_unittests, ozone_unittests, mus_demo) as well perform
continuous integration in our bot [2]. You can see the progresses here
[3][4].
In Q3, we worked a lot in stabilizing our implementation, and for Q4,
the Ozone bits are going to be proposed upstream. MUS changes are also
going to be discussed here in chromium-dev later this quarter.
I welcome you to try and provide feedback of our implementation, as we
work out its upstreaming plan.
*** 'internal window mode' is is the terminology being used when an
application runs within the Ash shell environment, the built-in Window
Manager (WM) that powers ChromeOS builds. Applications in this mode do
not interact with the host WM.
***Analogously, external window mode is the terminology being used to
represent a regular desktop application on Linux, where the host
Window Manager (WM) takes care of windowing actions like maximize,
minimize, restore and fullscreen of the application window. Also, the
application itself reacts to content size changes accordingly.
[0]
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux?numbuilds=200
[1] https://github.com/Igalia/chromium
[2] https://build-chromium.igalia.com/
[3] http://youtu.be/bPK966yHQM4
(chromium/ozone/wayland)
[4] http://youtu.be/FlsnQopAMJk (chromium/ozone/x11)
Hi All,
I was wondering if anybody could clarify for me current status of
chrome
running on Linux with Ozone as UI interface. I had my own platform
(embedded) for which I have implemented Ozone porting. I had used it
a
long
time ago with Chromium 43 and it worked fine. Now I want to switch to
version 62. I can see new concept appearing like Mus and Mash. I also
can
see, that for instance build with X11 as Ozone implementation should
work,
but I struggle to understand how. I basically generate build with
following
arguments (the build is on Linux machine, cross-compiling to arm
gn args out/Release_GN_x64 --args="use_ozone=true
enable_package_mash_services=true ozone_platform_myplatform=true" +
more
parameters to set custom toolchain
and ozone_platform_myplatform is properly defined in gn and gni files
and
ninja -C out/Release_GN_x64 chrome mus_demo mash:all chrome_sandbox
services/ui/demo
It builds fine, but when I run it on target device, it crashes in
BrowserFrame::InitBrowserFrame when doing
NativeBrowserFrameFactory::CreateNativeBrowserFrame because factory
for
ozone (native_browser_frame_factory_ozone.cc) says that
it can only create frame if aura::Env::GetInstance()->mode() ==
aura::Env::Mode::MUS and log is "For Ozone builds, only --mash launch
is
supported for now.". Now, I tried running it with "--mash" option as
suggested before and it does not help, because as far as I
understand,
the
only way for environment to be MUS is set in chrome_main.cc, but it
is
guarded by #ifdef OS_CHROMEOS. Does it mean it never works for Linux?
I'm
puzzled with this one.
I can manually remove some checks for environment to be MUS to make
it
go
further but it didn't help much. With "--mus" as a running parameter,
ui
service is not running, so nothing is showing, but it seems to run
(e.g.
dev
tools works). When removing some checks, "--mash" also works
partially
but
it seems to hang somewhere. So, in general I think it's not the way
to
patch
the code like this. What worries me is that at
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/ozone_overview.md
instruction says it should work (for X11) but considering that check
with
#if defined(OS_CHROMEOS), I have no idea how, it can never pass that
not
implemented part in native_browser_frame_factory_ozone.cc.
Much appreciate any input on this problem
Vlad
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/643651ba-fb20-4595-b2cc-b3e224c2d10a%40chromium.org.
--
--Antonio Gomes
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google
Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e960db4f-196f-42de-821b-684a7794f880%40chromium.org.
--
--Antonio Gomes
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Kyle Charbonneau
2017-10-23 15:54:25 UTC
Permalink
Running ./chrome --mus or ./chrome --mash is not compatible with the
software rendering path (at least not in ToT Chrome). It will end up using
whatever GLOzone is associated with the first implementation listed
in GetAllowedGLImplementations() by default.
Post by Vlad Bezuglyy
Hi Antonio, Maksim,
I have also tried to use "headless" platfrom from Igalia port (branch
ozone-wayland-beta-62.0.3202.29-release). It doesn't seem to work for me
(i.e. it does not produce any dump files). I was wondering if software
rendering path is implemented in your port. Could you comment on this?
Regards,
Vlad
четверг, 19 Пктября 2017 г., 16:09:11 UTC+3 пПльзПватель Antonio Gomes
Post by Antonio Gomes
cc: ozone-dev
bcc: chromium-dev (subject deviates slightly chromium-dev, since
chromium/wayland is still a downstream work, but I kept BCC for the
sake of our future intent to upstream)
Quick check are you launching with --mash or --mus parameter? (from
the error it seems like you are trying the former, whereas the later
should be used.
$ <out>/chrome --mus --ozone-platform=wayland -user-data-dir=~/tmp <urls>
is_debug = false
is_component_build = false
symbol_level = 1
dcheck_always_on = true
use_ozone = true
ozone_platform_wayland = true
ozone_platform_x11 = true
ozone_platform_gbm = false
ozone_platform_headless = true
ozone_auto_platforms = false
use_xkbcommon = true
enable_package_mash_services = true
use_sysroot = true
treat_warnings_as_errors = false
is_clang = true
enable_nacl = false
remove_webcore_debug_symbols = true
use_jumbo_build = true
proprietary_codecs = true
ffmpeg_branding = "Chrome"
Please let me know,
Hi Antonio,
I did try https://github.com/Igalia/chromium with my platform. It
builds
[3886:3893:0103/032058.840266:184830803554:ERROR:service_manager.cc(156)]
Connection InterfaceProviderSpec prevented service: quick_launch from
binding interface: ui::mojom::ExternalWindowTreeFactory exposed
by: ui
I'm not sure it's relevant but it's not running, it seems to stuck
somewhere.
Regards,
Vlad
пятМОца, 13 Пктября 2017 г., 15:53:05 UTC+3 пПльзПватель Antonio Gomes
Hi Vlad.
TL;DR: The state of Ozone/Linux in ToT is not so useful to your needs
today. There is a buildbot [0], and it builds 'chrome mash:all
services_unitests and ozone_unittests' targets, but only runs a
handful of other unittests at the moment, obviously, making use of
Mus/Ozone codepath.
$ <out>/mash --service=mus_demo --ozone-platform={x11,wayland}
Please have a look at [1]. This is an ongoing effort ran by Igalia
whose goal is to extend both Ozone and Mus to support what we are
calling 'external window mode***', targeting Linux. Note that Chrome
itself isn't changed, since it works as it ought to in both 'internal'
and 'external' window modes.
Project is stable, and our implementation is pretty much functional
today: we have a well defined rebase and contribution policies, where
we rebase against ToT in a weekly basis, run unittests (namely
services_unittests, ozone_unittests, mus_demo) as well perform
continuous integration in our bot [2]. You can see the progresses here
[3][4].
In Q3, we worked a lot in stabilizing our implementation, and for Q4,
the Ozone bits are going to be proposed upstream. MUS changes are also
going to be discussed here in chromium-dev later this quarter.
I welcome you to try and provide feedback of our implementation, as we
work out its upstreaming plan.
*** 'internal window mode' is is the terminology being used when an
application runs within the Ash shell environment, the built-in Window
Manager (WM) that powers ChromeOS builds. Applications in this mode do
not interact with the host WM.
***Analogously, external window mode is the terminology being used to
represent a regular desktop application on Linux, where the host
Window Manager (WM) takes care of windowing actions like maximize,
minimize, restore and fullscreen of the application window. Also, the
application itself reacts to content size changes accordingly.
[0]
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20L
inux?numbuilds=200
[1] https://github.com/Igalia/chromium
[2] https://build-chromium.igalia.com/
[3] http://youtu.be/bPK966yHQM4
(chromium/ozone/wayland)
[4] http://youtu.be/FlsnQopAMJk (chromium/ozone/x11)
Hi All,
I was wondering if anybody could clarify for me current status of
chrome
running on Linux with Ozone as UI interface. I had my own platform
(embedded) for which I have implemented Ozone porting. I had used it
a
long
time ago with Chromium 43 and it worked fine. Now I want to switch
to
version 62. I can see new concept appearing like Mus and Mash. I
also
can
see, that for instance build with X11 as Ozone implementation should
work,
but I struggle to understand how. I basically generate build with
following
arguments (the build is on Linux machine, cross-compiling to arm
gn args out/Release_GN_x64 --args="use_ozone=true
enable_package_mash_services=true ozone_platform_myplatform=true" +
more
parameters to set custom toolchain
and ozone_platform_myplatform is properly defined in gn and gni
files
and
ninja -C out/Release_GN_x64 chrome mus_demo mash:all chrome_sandbox
services/ui/demo
It builds fine, but when I run it on target device, it crashes in
BrowserFrame::InitBrowserFrame when doing
NativeBrowserFrameFactory::CreateNativeBrowserFrame because factory
for
ozone (native_browser_frame_factory_ozone.cc) says that
it can only create frame if aura::Env::GetInstance()->mode() ==
aura::Env::Mode::MUS and log is "For Ozone builds, only --mash
launch is
supported for now.". Now, I tried running it with "--mash" option as
suggested before and it does not help, because as far as I
understand,
the
only way for environment to be MUS is set in chrome_main.cc, but it
is
guarded by #ifdef OS_CHROMEOS. Does it mean it never works for
Linux?
I'm
puzzled with this one.
I can manually remove some checks for environment to be MUS to make
it
go
further but it didn't help much. With "--mus" as a running
parameter, ui
service is not running, so nothing is showing, but it seems to run
(e.g.
dev
tools works). When removing some checks, "--mash" also works
partially
but
it seems to hang somewhere. So, in general I think it's not the way
to
patch
the code like this. What worries me is that at
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/o
zone_overview.md
instruction says it should work (for X11) but considering that check
with
#if defined(OS_CHROMEOS), I have no idea how, it can never pass that
not
implemented part in native_browser_frame_factory_ozone.cc.
Much appreciate any input on this problem
Vlad
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-de
v/643651ba-fb20-4595-b2cc-b3e224c2d10a%40chromium.org.
--
--Antonio Gomes
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google
Groups
"Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/chromium-de
v/e960db4f-196f-42de-821b-684a7794f880%40chromium.org.
--
--Antonio Gomes
--
You received this message because you are subscribed to the Google Groups
"Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Antonio Gomes
2017-10-23 16:01:14 UTC
Permalink
Hi Vlad.
Post by Vlad Bezuglyy
Hi Antonio, Maksim,
I have also tried to use "headless" platfrom from Igalia port (branch
ozone-wayland-beta-62.0.3202.29-release). It doesn't seem to work for me
(i.e. it does not produce any dump files). I was wondering if software
rendering path is implemented in your port. Could you comment on this?
The only Ozone backends we have developed as part of this project are
Wayland and X11. What you run in 'headless' is essentially the same as
what is available at ToT Chromium.

As per Kyle's comment, Mus does not support SW rendering at the moment
(nor in ToT nor in our fork). Maybe one alternative could be using
MESA's GL/SW rendering implementation, so that Chromium would not know
the underlying system lacks proper GL support(?).
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Vlad Bezuglyy
2017-10-25 08:24:07 UTC
Permalink
Hi All,

Thanks for your help and comments, indeed after I'd ported egl on my
platform it's started drawing.

Regards,
Vlad
Hi Vlad.
Post by Vlad Bezuglyy
Hi Antonio, Maksim,
I have also tried to use "headless" platfrom from Igalia port (branch
ozone-wayland-beta-62.0.3202.29-release). It doesn't seem to work for me
(i.e. it does not produce any dump files). I was wondering if software
rendering path is implemented in your port. Could you comment on this?
The only Ozone backends we have developed as part of this project are
Wayland and X11. What you run in 'headless' is essentially the same as
what is available at ToT Chromium.
As per Kyle's comment, Mus does not support SW rendering at the moment
(nor in ToT nor in our fork). Maybe one alternative could be using
MESA's GL/SW rendering implementation, so that Chromium would not know
the underlying system lacks proper GL support(?).
--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+***@chromium.org.
Loading...