Giter Site home page Giter Site logo

ozone-wayland's Introduction

Introduction

Ozone-Wayland is the implementation of Chromium's Ozone for supporting Wayland graphics system. Different projects based on Chromium/Blink like the Chrome Browser, Chrome OS, Crosswalk, among others can be enabled now using Wayland.

Alt text

Contents

Design

Ozone-Wayland architecture can be found here.

Howto

We use Ubuntu 14.04 LTS (Trusty Tahr), 32/64-bit but a kernel from Raring though. One can install it pretty easily just sudo apt-get install linux-generic-lts-raring. This version is needed for using Mesa master 9.3.0-devel, a requirement for Weston. Besides, make sure you have at least 25 GB of disk space to store all the sources and a few targets to be compiled (with debugging symbols).

Firstly you'd need to set up the Wayland libraries (version >= 1.4.0), and the Weston reference compositor that you will be running Chromium onto. The information on Wayland's web page should be enough for doing so:

http://wayland.freedesktop.org/building.html

Please note that at the moment support for Wayland's XDG Shell protocol only works with the 1.6 series.

Make sure everything is alright now, setting up the environment variable $XDG_RUNTIME_DIR and playing a bit with the Wayland clients, connecting them on Weston.

Then you'd need some distribution tools and development packages :

$ sudo apt-get install gperf libnss3-dev libpulse-dev libdbus-1-dev libexif-dev libpci-dev libpango1.0-dev libelf-dev libcap-dev libasound2-dev libssl-dev libcups2-dev libgconf2-dev libgnome-keyring-dev

If you are running a 64-bit Ubuntu distribution, you'd additionally need :

$ sudo apt-get install ia32-libs

Then on Chromium's side, we need to setup Chromium's tree together with the Ozone-Wayland implementation. For that you need to use gclient to clone Ozone-Wayland; but first you need to download depot_tools and configure it. Say your Chromium top-level will be in ~git/chromium, you will need:

$ mkdir -p ~git/chromium
$ cd ~git/chromium
$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
$ export PATH=`pwd`/depot_tools:"$PATH"

We support HWA Video Decoding using Libva and VAAPI. To enable the support one needs to build and install these packages. Note: This is still work in progress. You can skip these dependencies if you don’t need this support.

One needs to set the installation prefix $WLD(Below) to be same as the one used for setting up Wayland environment.

$ git clone git://anongit.freedesktop.org/libva
$ cd libva/
$ git checkout libva-1.5.0
$ ./autogen.sh --prefix=$WLD
$ make -j4 && make install
$ git clone git://anongit.freedesktop.org/vaapi/intel-driver
$ cd intel-driver/
$ git checkout 1.5.0
$ ./autogen.sh --prefix=$WLD
$ make -j4 && make install

now we can clone Ozone-Wayland and fetch all the dependencies of it, including Chromium itself:

$ gclient config ssh://[email protected]/01org/ozone-wayland.git --name=src/ozone --deps-file ".DEPS.git"
$ gclient sync 
$ export GYP_DEFINES='clang=0 use_sysroot=0 component=static_library linux_use_bundled_gold=0 use_ozone=1 ozone_auto_platforms=1 ozone_platform_wayland=1 use_xkbcommon=1' 

If you want to enable HWA Video Decoding, you need to have the following GYP_DEFINES:

 $ export GYP_DEFINES='clang=0 use_sysroot=0 component=static_library linux_use_bundled_gold=0 use_ozone=1 ozone_auto_platforms=1 ozone_platform_wayland=1 use_xkbcommon=1 proprietary_codecs=1 ffmpeg_branding=Chrome'

It may take a considerable time for downloading the trees. If everything went fine, now we're able to build.

For now, also apply some patches:

./src/ozone/patches/patch-chromium.sh

TIP: to speed up debug builds you can disable Blink debugging symbols by setting remove_webcore_debug_symbols=1 in GYP_DEFINES.

Note that in Chromium, gyp uses pkg-config for checking where are Wayland libraries on the system, so double check that you are not mixing some that was already there with latest that you just got and compiled from git.

TIP: if you followed Wayland's web page instructions, then you probably want to set the PKG_CONFIG_PATH variable as $HOME/install and add it in your .bashrc to be as default.

Now we can conclude compiling a few targets like Content Shell (content_shell) or the Chromium browser:

$ cd src/
$ ./build/gyp_chromium
$ ninja -C out/Debug -j16 chrome

(if you get any build errors, please execute "git log" and verify that the first "commit" line matches the "chromium_rev" one found in src/ozone/.DEPS.git. If it doesn't, run "git checkout $ID", apply the patches and compile again)

That's all. At this point you should be able to connect Chromium on Weston using:

$ ~/git/weston/src/weston &
$ ./out/Debug/chrome --no-sandbox --ignore-gpu-blacklist

Sandboxing

If you want to enable Sandboxing provided by Chromium, please follow the instructions from here: https://code.google.com/p/chromium/wiki/LinuxSUIDSandbox

Working with Ozone-Wayland Release branch:

Instructions can be found here: https://github.com/01org/ozone-wayland/wiki/Releasing#wiki-releasebranch

Gardening

We pin chromium to a particular revision in order to keep upstream changes from breaking our build. Updating that revision to a newer one and fixing any resulting breakage is called gardening. To sync a different version of chromium, update chromium_rev in .DEPS.git to a newer revision then run the gclient sync again. Fix any build errors, and commit both changes.

Contributing

Instructions can be found here: https://github.com/otcshare/ozone-wayland/wiki

License

Ozone-Wayland's code uses the BSD license (check the LICENSE file in the project).

Tips

Build Wayland & Weston

If you want to build and run ozone-wayland, you should install wayland and weston first. Here is the instruction using jhbuild.

Install jhbuild

Please refer to this instruction: https://developer.gnome.org/jhbuild/stable/getting-started.html.en

Install dependent packages using apt-get

$ cd ~/chromium/src
$ ozone/tools/jhbuild/install-dependencies

Build and install Wayland & Weston

$ cd ozone/tools/jhbuild
$ jhbuild -f wayland.jhbuildrc

Run Weston

$ jhbuild -f wayland.jhbuildrc shell
$ cd ~/chromium/src
$ out/wayland/root/bin/weston --fullscreen

Run ozone-wayland in Weston

Open a weston terminal

$ out/Release/chrome --no-sandbox

ozone-wayland's People

Contributors

andriyp avatar bryant1410 avatar clopez avatar dnarvaez avatar ds-hwang avatar jbrianceau avatar joone avatar kalyankondapally avatar mcatanzaro avatar michaelforney avatar mrobinson avatar mspang avatar patrickheeb avatar qjia7 avatar rakuco avatar rzr avatar shaochangbin avatar sjnewbury avatar tiagovignatti avatar tonikitoo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ozone-wayland's Issues

Restore IPC communication in case GPU process is re-spawned.

This could happen for various reasons:
1)Driver crashed.
2) Weston went into screen saver/hibernation mode.
3)GPU Process crashed.

In this case IPC Channel between display channel and host gets shut down. We need to restore the connection in this case.

Dependency: #29.
Blocks: #93.
SubTasks: None.

Fix ownership of cursordata.

Currently, we expect that cursor data is atleast called once before it's destroyed.
Assume a case when display is destroyed before cursor is created.
Problematic code:

  1. WaylandCursor::Clear() is called during destruction of wayland display.
  2. WaylandCursor::Clear() calls WaylandCursorData::GetInstance().
    3)GetInstance tries to create a new instance if we dont have one already. In this case wl_shm is null and we would always crash on wayland side.

One possible solution is to create a single instance of WaylandCursorData in waylanddisplay and cursor would always query it from wayland display. Display thus would completely own waylandcursordata.

[Wayland] Dont link against cairo libs

currently we link against pangocairo and cairo. These are mostly coming from Weston/wayland side. Investigate how much effort is it to be able to build weston without linking against cairo and upstream the changes to wayland.

Use GPU process to handle final composition.

Chromium has run time option to either use single process or multi process. Currently, we always mimic single process behaviour even when multi-process support is requested.

This task is to enable the usage of GPU process for final composition. OffScreen rendering support is not part of this task.

RPM Package

It would be good to test if Ozone-Wayland works on Tizen. Tizen-IVI(Tizen3.0 and more) has full support for Wayland. Tizen-IVI uses MiniBrowser (which is similar to content shell on chromium) to test WebKit-WRT.

Support Creation of more than one window.

Currently, we create only a root window. Ideally GetAcceleratedWidget should send a new opaque handle, Realize function should create the window mapping it to the handle and return egl window associated with the window.

ContentShell SegFault

Steps to reproduce:
1)Open Content Shell.
2)Right click address bar.
Expected Result:
3)It should open another window.
Actual Result:
Content Shell segFaults.

Build CrossWalk

Build CrossWalk with Ozone-wayland.

Add step by step instructions.

Simplify existing solution for IPC channel communication

IPC channel communication:

Background:
Gpu Process acts as the wayland client per browser instance. All realized widgets are created on GPU process side. Browser process needs to send any widget state change, e.g. Min, Max, FullScreen information to DisplayChannel. This information would be used to update wayland shell. Also, any output related information (e.g. output size) needs to be passed from GPU process to Browser process.

Current Solution:
DisplayChannelHost: Message filter on Browser process side.
DisplayChannel: Ipc listener on GPU process side.

On Browser Process Side:

We observe for any child process being forked by Browser process. If child process is GPU process, we add DisplayChannelHost as one of the BrowserMessageFilter. DisplayChannelHost listens to any messages specific to Wayland coming from GPU process side and handles them appropriately.

On GPU process side:

DisplayChannel is responsible for listening to any routed messages coming from Browser process and handles them appropriately. GPUChildThread needs to be created before DisplayChannel can be added as listener. InitializeHardware gets called very early (before GPUChildThread is created) and hence not the right place to set up DisplayChannel as listener. Thus, we use RealizeWidget to do this, which is wrong.

Issues:
1)In order to avoid changes in chromium, we have been adding work around's as to how and when listeners are installed. This has complicated the existing solution.
2)OutputSize notification is too late. The value returned by DefaultDisplaySpec is used by widget as the work area of current screen. This information needs to come from GPU side and is needed before any calculations related to widget bounds are done. With the current solutions, it's already too late as to when the listeners are setup and communication happens between them.

Proposal:
On Browser Process side:
Set DisplayChannelHost as message filter as soon as GPUProcesshost is created.
On GPU Process side:
Set DisplayChannel as IPC listener as soon as GPUChildThread is created.

Remove any un-necessary complication from the solution, even if it means having to maintain minor changes in Chromium.

Single and Multi Process should work.

Not part of this CL:
1)Handle GPU crash and re-launch. This is something we might need to handle in future.

Dependency on X11 headers

We include X headers in wayland_input_device.cc because of XKB configuration. We should avoid this. Bonus points if we learn how to compile one whole target without pulling in the X11 libraries as well.

Chrome browser segfaults when GPU context is created

"current" Chrome browser stopped to work. It starts fine but whenever a Web page is due to be opened, a shared offscreen context provider must be allocated from the main thread and the following is dumped:

[17326:17326:1008/110233:FATAL:context_provider_command_buffer.cc(299)] Check failed: lost_context_callback_.is_null() || lost_context_callback.is_null().
[0x7ffebbe833ec] base::debug::StackTrace::StackTrace()
[0x7ffebbebe6c3] logging::LogMessage::~LogMessage()
[0x7ffec0710f43] content::ContextProviderCommandBuffer::SetLostContextCallback()
[0x7ffebf66263a] content::GpuProcessTransportFactory::SharedMainThreadContextProvider()
[0x7ffebf661e1a] content::GpuProcessTransportFactory::CreateSharedSurfaceHandle()
[0x7ffebf414dff] content::RenderWidgetHostViewAura::GetCompositingSurface()
[0x7ffebf3f74b1] content::RenderWidgetHostImpl::GetCompositingSurface()
[0x7ffebf3d89df] content::RenderViewHostImpl::CreateRenderView()
[0x7ffebf4876d3] content::WebContentsImpl::CreateRenderViewForRenderManager()
[0x7ffebf6422ae] content::RenderViewHostManager::InitRenderView()
[0x7ffebf64212f] content::RenderViewHostManager::CreateRenderView()
[0x7ffebf642e5a] content::RenderViewHostManager::UpdateRendererStateForNavigate()
[0x7ffebf6404a8] content::RenderViewHostManager::Navigate()
[0x7ffebf47f556] content::WebContentsImpl::NavigateToEntry()
[0x7ffebf47f0a2] content::WebContentsImpl::NavigateToPendingEntry()
[0x7ffebf472277] content::NavigationControllerImpl::NavigateToPendingEntry()
[0x7ffebf46d700] content::NavigationControllerImpl::LoadEntry()
[0x7ffebf46ec15] content::NavigationControllerImpl::LoadURLWithParams()
[0x7ffebee7e0f2](anonymous namespace)::LoadURLInContents()
[0x7ffebee7f267] chrome::Navigate()
[0x7ffebee67495] Browser::OpenURLFromTab()
[0x7ffebf47efb2] content::WebContentsImpl::OpenURL()
[0x7ffebf485f5d] content::WebContentsImpl::RequestTransferURL()
[0x7ffebf485d36] content::WebContentsImpl::RequestOpenURL()
[0x7ffebf3df95e] content::RenderViewHostImpl::OnOpenURL()
[0x7ffebf3e8309] DispatchToMethod<>()
[0x7ffebf3e5ac2] ViewHostMsg_OpenURL::Dispatch<>()
[0x7ffebf3dcf70] content::RenderViewHostImpl::OnMessageReceived()
[0x7ffebf3c645b] content::RenderProcessHostImpl::OnMessageReceived()
[0x7ffebc5a5c03] IPC::ChannelProxy::Context::OnDispatchMessage()
[0x7ffebc5a9230] base::internal::RunnableAdapter<>::Run()
[0x7ffebc5a8d2a] base::internal::InvokeHelper<>::MakeItSo()
[0x7ffebc5a8602] base::internal::Invoker<>::Run()
[0x7ffebb236cfd] base::Callback<>::Run()
[0x7ffebbec8134] base::MessageLoop::RunTask()
[0x7ffebbec8258] base::MessageLoop::DeferOrRunPendingTask()
[0x7ffebbec877d] base::MessageLoop::DoWork()
[0x7ffebbe70163] base::MessagePumpLibevent::Run()
[0x7ffebbec7cb7] base::MessageLoop::RunInternal()
[0x7ffebbec7b70] base::MessageLoop::RunHandler()
[0x7ffebbef7240] base::RunLoop::Run()
[0x7ffebb868e67] ChromeBrowserMainParts::MainMessageLoopRun()
[0x7ffebf22164c] content::BrowserMainLoop::RunMainMessageLoopParts()
[0x7ffebf2276de] content::BrowserMainRunnerImpl::Run()
[0x7ffebf21db17] content::BrowserMain()
[0x7ffebbe6661f] content::RunNamedProcessTypeMain()
[0x7ffebbe675f0] content::ContentMainRunnerImpl::Run()
[0x7ffebbe65aaf] content::ContentMain()
[0x7ffebb0b5521] ChromeMain
[0x7ffebb0b54ec] main
[0x7ffeb692076d] __libc_start_main
[0x7ffebb0b53f9]

Error building with gcc 4.8.1

vaio% ninja -C out/Debug -j1 content_shell
ninja: Entering directory `out/Debug'
[1/4612] CXX obj/ozone/impl/wayland.desktop_root_window_host_wayland.o
FAILED: g++ -MMD -MF obj/ozone/impl/wayland.desktop_root_window_host_wayland.o.d -DANGLE_DX11 -DWTF_VECTOR_INITIAL_SIZE=4 -D_FILE_OFFSET_BITS=64 -DCHROMIUM_BUILD -DTOOLKIT_VIEWS=1 -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_OZONE=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_NSS=1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_REMOTING=1 -DENABLE_WEBRTC=1 -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1 -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_AUTOMATION=1 -DENABLE_GOOGLE_NOW=1 -DENABLE_FULL_PRINTING=1 -DENABLE_PRINTING=1 -DENABLE_SPELLCHECK=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_MANAGED_USERS=1 -DENABLE_MDNS=1 -DU_USING_ICU_NAMESPACE=0 -DU_STATIC_IMPLEMENTATION -DSK_ENABLE_INST_COUNT=0 -DSK_SUPPORT_GPU=1 '-DGR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h"' -DSK_USE_POSIX_THREADS -DSK_DEFERRED_CANVAS_USES_FACTORIES=1 -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_DEBUG -I../../third_party/khronos -I../../gpu -I../.. -I../../third_party/icu/source/i18n -I../../third_party/icu/source/common -I../../third_party/skia/src/core -I../../skia/config -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../skia/ext -fstack-protector --param=ssp-buffer-size=4 -pthread -fno-exceptions -fno-strict-aliasing -Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe -fPIC -Wno-unused-local-typedefs -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wno-format -Wno-unused-result -O0 -g -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -Wno-deprecated -c ../../ozone/impl/desktop_root_window_host_wayland.cc -o obj/ozone/impl/wayland.desktop_root_window_host_wayland.o
In file included from ../../ozone/impl/desktop_root_window_host_wayland.cc:6:0:
../../ozone/impl/desktop_root_window_host_wayland.h:58:20: error: 'typedef unsigned int ozonewayland::DesktopRootWindowHostWayland::RootWindowState' conflicts with a previous declaration
typedef unsigned RootWindowState;
^
../../ozone/impl/desktop_root_window_host_wayland.h:48:8: note: previous declaration 'enum ozonewayland::DesktopRootWindowHostWayland::RootWindowState'
enum RootWindowState {
^
In file included from ../../ozone/impl/desktop_root_window_host_wayland.cc:8:0:
../../ozone/impl/ozone_display.h:37:20: error: 'typedef unsigned int ozonewayland::OzoneDisplay::WidgetState' conflicts with a previous declaration
typedef unsigned WidgetState;
^
../../ozone/impl/ozone_display.h:26:8: note: previous declaration 'enum ozonewayland::OzoneDisplay::WidgetState'
enum WidgetState {
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Activate()':
../../ozone/impl/desktop_root_window_host_wayland.cc:306:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ |= Active;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Deactivate()':
../../ozone/impl/desktop_root_window_host_wayland.cc:314:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Active;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Maximize()':
../../ozone/impl/desktop_root_window_host_wayland.cc:326:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ |= Maximized;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:327:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Minimized;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:328:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Normal;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Minimize()':
../../ozone/impl/desktop_root_window_host_wayland.cc:336:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Maximized;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:337:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ |= Minimized;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:338:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Normal;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Restore()':
../../ozone/impl/desktop_root_window_host_wayland.cc:346:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Maximized;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:347:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Minimized;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:348:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ |= Normal;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::SetFullscreen(bool)':
../../ozone/impl/desktop_root_window_host_wayland.cc:433:12: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ |= FullScreen;
^
../../ozone/impl/desktop_root_window_host_wayland.cc:435:12: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~FullScreen;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Show()':
../../ozone/impl/desktop_root_window_host_wayland.cc:498:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ |= Visible;
^
../../ozone/impl/desktop_root_window_host_wayland.cc: In member function 'virtual void ozonewayland::DesktopRootWindowHostWayland::Hide()':
../../ozone/impl/desktop_root_window_host_wayland.cc:503:10: error: invalid conversion from 'int' to 'ozonewayland::DesktopRootWindowHostWayland::RootWindowState' [-fpermissive]
state_ &= ~Visible;
^
ninja: build stopped: subcommand failed.

Chromium browser support

Currently, we are able to build for target content_shell with Ozone-Wayland. This task is to ensure we are able to build for target Chromium browser with Ozone-Wayland.

specify a Chromium version for development

We need to sort out an smart way of developing Ozone-Wayland using a given point/version of Chromium tree that just works. At the moment we're syncing always with Chromium TiT (trunk) but that changes too frequently which requires us doing quick interventions to fix Ozone-Wayland all the time.

So far we had the following types of problems that needed to be tracked:

  1. Chromium structure of directories has changed and so the header files we use in here (e.g. 5b402e1, b0147c4, 2dd781e, e6056f6)
  2. our patches for Chromium (in patches/) get broken and don't apply anymore (e.g 8856382, 91aa42b, e6056f6)
  3. API changes (aura::RootWindowHost in 2dd781e, class DesktopActivationClient removed in 221f446, gfx::Screen in cc0cfa1, DesktopRootWindowHost in 5f93cc1)

For 1., I'd hope that it should diminish with the time (probably the Blink fork still impacting on these directory changes?) and for 2. I think we're doing quite good to be honest cause at the moment we only have four patches to be applied. So maybe the biggest problem is 3.

One idea is to have an "Ozone API" that has a version assigned on it and is bumped in Chromium whenever changes happen there. Downstream implementors would check when that version changes and track the changes accordingly. Does it help?

Ensure correct screen size is set before widget bounds are calculated.

Chrome needs the screen size quite early for calculating widget bounds. Chrome does this calculation even before GPU Process is forked. Thus, Forcing IPC communication between GPU process and Browser process at a early stage doesn't help here.

Possible solutions:
1)Have a env variable like Ozone does.
2)Read from weston.ini file or from same place wayland gets this information?
3)Create a temporary wayland client connection on browser process side, get screen output and close it ? As this is an issue only at start up.

Initialization of Factory Classes.

Currently we initialize Surfacefactory, Desktop related factory classes during pre-sandbox startup[1].

Ideally we should be able to implement custom delegate and pass it during initialization, which would give a complete control on App Initialization and termination. Also, we have more than one target to account for. i.e Aura demo, content shell, chrome, chrome os etc.
Ideally, any changes should be in GYP file of the respective target. This should be non-trivial if we even have to maintain the code on our side as the code should be minimum.

1)https://github.com/otcshare/ozone-wayland/blob/master/patches/0003-Set-Wayland-as-the-implementation-for-SurfaceFactory.patch

Repo cleanups.

Listing down issues we need to tackle to clean up the repo:
1)Namespace conflicts. We seem to be using ui/content namespace for all classes under Wayland. We should come up with a better name for namespace used by these classes.
2)Wayland.gyp isn't functional. If the intention is to have it build wayland toolkit than we should fix it or remove it from repo.
3)Remove all un-necessary includes in *.h, *.cc

Dispatcher should support synchronized flush.

There is no way to request dispatcher to handle a synchronized flush i.e immediately flush wayland events on the given thread.

This would be useful to force synchronization at browser startup.

button press doesn't get processed correctly

In content_shell, if we press any button and keep it down for awhile, weston shows the spin icon animation on the cursor -- the interpretation of such cursor's spin icon is that the client is not responding.

another problem that might be related is when content_shell is opened http://google.co.uk, then you wrap the cursor on the "More" menu on that page (top right corner); now, without moving the cursor just press the left button of the mouse. Normally the "More" menu would open and submenus would show on the screen, but that never happens unless the mouse is moved.

we are not implementing the grab/drag semantics correctly in ozone-wayland (IIRC we're not implementing at all it), or it might be just that ozone-wayland doesn't call the libwayland's dispatch() after a button event happens.

gyp: choose an specific libwayland version

We depend on Wayland, Weston, Mesa etc. More information can be found at [1]. Chromium usually keeps a stable release of third party deps and updates them regularly. We should probably do something like that. It would be nice to have a script which automates wayland/weston setup [1]. I am no expert at writing scripts.
Need to decide on stable versions we use (latest, some commit we know works etc).

Fix un-necessary window resizing.

Currently, we create a window with size 1,1, and resize it to correct size.

Problem is that host doesn't send the correct window size before it's realized. This is also due to the fact that all the IPC messages are ignored before the display channel connection is made.

This should also avoid some un-necessary changes in glsurfaceegl

Nomination of a contributor/developer to Owner status.

We should use exactly Chromium's OWNER system [1]. We are on track for it.

I Propose the following for any Owner to nominate a contributor/developer to Owner status:

  • No explicit minimum number of patches to become an OWNER.
  • Good understanding of Ozone, Aura and Wayland implementation.
  • Excellent code quality.
  • Good judgement about when to defer to other OWNERS for an LGTM.
  • At least 1 other owner should agree for the nomination. (This no should be 2 ideally.)
  1. http://www.chromium.org/developers/owners-files

Study alternative solutions to avoid sending native Input messages via ipc.

Current solution with Browser on Multi process mode:
1)Wayland input callbacks are received on GPU Process side. These are than sent to browser process via IPC channel.
2)Browser forwards these messages to Render process. If Render process doesn't handle these events than Browser process handles them as needed.

The main goal of this task is to avoid step 1. Can we somehow get native event notifications directly in Browser process side ?

Couple of options:

  1. Can we re-use existing inputs support in Ozone.
  2. Is it possible to have a wayland client handling only input callbacks in Browser process side ?

Dependency: None identified (needs study).
Blocks: None.
SubTasks: None.

DisplaySpec has wrong attributes

One can see the following warning while running content shell:

[25620:25620:0816/231825:109142035667:WARNING:desktop_screen_wayland.cc(19)] malformed display spec from SurfaceFactoryOzone::DefaultDisplaySpec

shared library compilation fails

if we use GYP_DEFINES='component=shared_library', then the compilation fails in a bunch of places. @luxtella has some ideas how to make it work -- we need to poke him.

Dependency: #165 .
Blocks: #175
Sub-Tasks: #None

Unittests.

Currently, we don't have any unit tests to check our Ozone specific changes.

Fix libwayland events handling and dispatching

We currently have too many places where display is flushed for various reasons.
1)Move all the code relevant to dispatching/flushing display to WaylandDisplay.
2)Avoid the need to flush in WaylandWindow.
3)In certain cases we need to flush display only if any pending WaylandTasks have been handled else we dont have to. Add separate apis to force flush in all cases and as needed. this is the most important issue to address here -- in particular check the commentary here https://github.com/otcshare/ozone-wayland/blob/master/event_factory_wayland.cc#L75

[Meta] Unable to set window properities (maximize, minimize, etc)

This Issue should handle the following cases:
1)Maximize and restore.
2)Minimize and restore.
3)ShowMaximizedWithBounds.
4)FullScreen.
5)Showing window with a particular state.

The following functions in DRWH should have proper support before this issue is closed:
1)ShowWindowWithState
2)ShowMaximizedWithBounds
3)GetRestoredBounds
4)Maximize
5)Minimize
6)Restore
7)SetFullscreen

Dependency: #112.
Blocks: #118 .
Sub-Tasks: #128 #194

[GPU Process] Support Off-Screen Rendering.

This task is related to adding support for offscreen rendering in GPU process. This support is mostly used by Render Process to accelerate use cases like 2D canvas, 3D canvas etc

Dependency: #14.
Blocks: #102, #93.
SubTasks: None.

contributions and applying changes in master branch

For the changes in master, I think we need to decide something and then write down so eventual developers can read and contribute easily with the project.

developers need:

  1. set up a pull request.
  2. get review from a OWNER; meaning a LGTM and wait them to merge.

owners need:

  1. unless critical build fix nothing should go into master branch without the review from another owner. Does this work?

uninitialised byte in WaylandDispatcher::DisplayRun

==13916== Thread 2:
==13916== Syscall param epoll_ctl(event) points to uninitialised byte(s)
==13916== at 0xC073EE9: syscall (syscall.S:39)
==13916== by 0x6783B6: epoll_ctl (epoll_sub.c:45)
==13916== by 0x13BA2E1: ozonewayland::WaylandDispatcher::DisplayRun(ozonewayland::WaylandDispatcher_) (dispatcher.cc:355)
==13916== by 0x13BCA45: base::internal::RunnableAdapter<void ()(ozonewayland::WaylandDispatcher)>::Run(ozonewayland::WaylandDispatcher_ const&) (bind_internal.h:171)
==13916== by 0x13BC67F: base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void ()(ozonewayland::WaylandDispatcher)>, void ()(ozonewayland::WaylandDispatcher* const&)>::MakeItSo(base::internal::RunnableAdapter<void ()(ozonewayland::WaylandDispatcher)>, ozonewayland::WaylandDispatcher* const&) (bind_internal.h:871)
==13916== by 0x13BC1F0: base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void ()(ozonewayland::WaylandDispatcher)>, void ()(ozonewayland::WaylandDispatcher_), void ()(ozonewayland::WaylandDispatcher_)>, void ()(ozonewayland::WaylandDispatcher_)>::Run(base::internal::BindStateBase_) (bind_internal.h:1169)
==13916== by 0x429A72: base::Callback<void ()()>::Run() const (callback.h:396)
==13916== by 0x5E18BF: base::MessageLoop::RunTask(base::PendingTask const&) (message_loop.cc:491)
==13916== by 0x5E19E3: base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) (message_loop.cc:503)
==13916== by 0x5E1F08: base::MessageLoop::DoWork() (message_loop.cc:617)
==13916== by 0x653E6A: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) (message_pump_libevent.cc:232)
==13916== by 0x5E1442: base::MessageLoop::RunInternal() (message_loop.cc:441)
==13916== Address 0x1209d174 is on thread 2's stack

Review Latest commits

I have pushed some un-reviewed commits, mostly removing obsolete patches and apis changes. I am unable to set up a separate request for review(dont really know how to do it with git hub). This is more to ask you to review the changes.

EGLConfig changes in glsurface are still needed. I am working on an api, so we can get rid of it. I will discuss with rjkroege before setting it up for review in upstream.

Feel free to close once we have gone through the changes.

Chromium should run with Ozone Wayland platform.

We are able to launch content shell with ozone wayland platform. This task is to handle any issues with doing the same for chrome.

ContentShell is nothing but a stripped down version of Chromium. Should be straightforward. How ever, any related tasks should be created once the work is evaluated.

Dependency: Issue 11 should be handled before this.

Add Design doc

Add a document explaining the Wayland Implementation. This should be done once all the current classes re factoring has been done.

Fix build of Aura demo.

Currently we have a lot of dependencies which Aura demo doesn't link against.
We should come up with a stripped down version or link against the dependencies while building Aura demo.

I am not sure which is the right solution as Aura demo is like a basic demo.

Continuous Integration

Low priority.

We need to think about this after we support more use cases.

Understand chromium infra structure.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.