Igalia/chromium forked from mirror/chromium

…-acceleration-kodama-3

Ozone wayland dev try hw video acceleration

Various fixes to our clipboard impl

Added unittest support to Clipboard related code (namely
wayland_data_*).

The unittest is simple for now: it performs a write and a read
operator against compositor's clipboard.

It needed lots of extensions in our FakeServer machinary:
MockDataDeviceManager, MockDataDevice, MockDataSource, MockDataOffer
were all implemented.

Issue=369

Slighly more elegant way of writing 3 lines of code.

Issue=369

Style fixes pointed by 'git cl format'.

Issue=369

CL makes the Wayland clipboard read operation really async.
It installed a wl_callback (watcher) for the wl_display_flush,
ensuring that all data has been written on the server side.

Upon invoked, the callback proceeds with reading data from the system
clipboard, as before.

Wayland clipboard operations are asynchronous. CL passes
callbacks to be invoked upon completion of each ClipboardBridge
methor (read, write, get clipboard).

Issue=369

CL removes an unneed call to IsSelectionOwner. Today
WaylandConnection::GetSelectionData is only called from
WaylandDataSource. When we have a WaylandDataSource instance,
it meants we (chrome) "own" the selection.

Issue=369

%s/ShouldGetClipboardDataFromWMClipboard/IsSelectionOwner/g

The new name better reflects the purpose of the method.

BUG=369

fixup! [gpu-split][ozone/wayland] Use nested compositor approach when…

… mus!=viz.

Remove debugging check from wayland surface canvas

TBR=tonikitoo@igalia.com

Implement wayland nested compositor

This patch enables hardware assisted video decoding via the
Chromium V4L2VDA. Including changes when Linux is used. In
order to use this, use_linux_v4l2_only flag should be set
to true.

Signed-off-by: Ryo Kodama <ryo.kodama.vz@renesas.com>

Implement wayland nested compositor

This required creation of wl_surface and storing them into vector.
There is still a todo: we don't have a way to know if real wl_surface
has been destroyed (WaylandWindow), and we keep the surface resource
in nested compositor alive. It will be fixed in follow up cls.

This is a first set of patches for gpu-split work.

It was decided to first use nested compositor approach to allow out
of browser process gpu service to work with wayland.

That is, there was no mean of communication between gpu wayland EGL and
browser side wayland connection.

The nested compositor approach resolves the problem by acting as
intermediate compositor, which creates wl_surface for a gpu client,
which is capable to attach egl buffer to that surface. Once eglSwapBuffers
happens, surface_commit method, which is implemented on nested compositor
side, does the trick to handle buffers data further to real host compositor
using real wl_surface representing a window on browser side.

It added event->stopped_propagation() to avoid inserting character
when stopped_propagation is set while DispatchKeyEventPostIME is
working.

Issue #389

fixup! Added stopped_propagation condition before inserting character

It added input_method_minimal_unittests.cc and introduced
'InputMethodMinimalTest.StopPropagationTest' to verify that
character's not inserted to text input when the event is
set with stopped_propagation.

Issue #389

CL makes Chromium/Wayland able to share clipboard data from
other applications on the system.

It makes use of wl interfaces like wl_data_source_, wl_data_offer,
wl_data_device and wl_data_device_manager.
It also introduces to classes to allow the communication between
Mus and Ozone: ClipboardDataBridge and ClipboardDelegate.

Issue #369

fixup! [ozone/wayland] Add clipboard support

[ozone/wayland] Add missing algorithm declaration in WaylandDataOffer

WaylandDataOffer is using the algorithms std::find and std::any_of,
both declared in #include <algorithm>. But the include was missing.

This should be squashed against "[ozone/wayland] Add clipboard support"

Modify browser's IMEDriver so we have access to
ui::InputMethodAuraLinux functionality in mus

This CL:
- Modifies ui::InputMethodAuraLinux so it can call an ack callback after
  processing events.
- Introduces InputMethodBridge to acts as a bridge between
  ui::mojom::InputMethod and ui::InputMethodAuraLinux.
- Modifies content_browser's IMEDriver implementation to use
  ui::InputMethodAuraLinux via InputMethodBridge.
- Some unittests to verify that InputMethodBridge works correctly.

fixup! IME for Mus: Add ui::InputMethodAuraLinux logic to ime driver

Introduce Ozone Wayland IME integration.

This CL:
- Implements Ozone wayland specific Linux input method
  context service interface and integrates it with
  zwp_text_input_v1 protocol.
- Introduces new runtime flag --enable-wayland-ime to
  enable this feature (by default false).

Bug: 791920

fixup! IME for Wayland: Ozone Wayland IME integration

Fixed conflict from rebase on 19/Mar

This is a prerequisite to get Wayland IME for Ozone-Wayland working. Will be used
by an external window mode.

Bug: 791970, 791920
Change-Id: I1f2f09b8eafe5ff33d2ad6e1ca6f975ca4d6c051

Servification of Linux IME context allows implementing
IME context in Mus environment. This can be adopted to
existing LinuxInputMethodContext implementations and is
also an enabler for backends which need to run IME context
out of browser thread. Mainly targeted for Ozone Wayland
external mode that will run IME context in MUS thread.

This CL:
- Introduces LinuxInputMethodContext and
  LinuxInputMethodContextDelegate mojo service interfaces.
- Implements LinuxInputMethodContextMus and
  LinuxInputMethodContextFactoryMus.
- Groups ui/base/ime common types into their own GN component
  (ime_types) to break a dependency cycle on ChromeOS that
  this CL would cause otherwise.

mus.mojom.KeyboardCode.KEY_DELETE conflicts
with KEY_DELETE macro in /usr/include/linux/input-event-codes.h.

https://codereview.chromium.org/1527183003 was supposed to
rename original mus.mojom.KeyboardCode.DELETE to DELETE_KEY but
it got renamed to KEY_DETELE which now conflicts.

This CL:
- mus.mojom.KeyboardCode.KEY_DELETE became DELETE_KEY

This propagates accelerated widget to WTHM in order to allow
surface initialization to work further without mus hosting viz.
It's done in the same way as ChromeOS, but uses WindowTreeClient
instead of WindowManager when calling from WindowTree.

fixup! Override WTHM with accelerated widget to make viz work without mus

Don't rely on window manager state, but instead notify a tree
for external winodw mode about available widget.

As an experiment, call ScreenManager::Init in ui/service.cc as soon
as ScreenManager::Create is called. Thus, we don't wait before
gpu is initialized (it's initialized right after ui/service and
other mojo stuff is initialized in BrowserMainLoop), and avoid
a problem, when GpuProcessHost (used when mus!=viz) has to call
to ScreenManager about initalized gpu, which starts quering of
display data, which quite tricky, because we can't set right
delegate at that time.

This cl extends ShellBrowserMainParts and makes content_browsertests
to work with mus. The content_shell can be partly run, but they lack
proper keyboard input and some other stuff.

fixup! Make content_browsertests and content_shell work with mus.

Remove LOG(FATAL) as long as second zygote process takes the same
path, but doesn't include mus flag, which triggers LOG(FATAL) and
content_shell crashes.

TBR=tonikitoo@igalia.com

fixup! Make content_browsertests and content_shell work with mus.

Adapt to launch content_shell with --enable-features=Mash.

$ <out>/content_shell --enable-features=Mash --ozone-platform=wayland

Issue #266

When using NativeCursorManagerMus in chromeos/mash, the only
information used to build a ui::CursorData instance is ui::CursorType
(see ::SetCursor ui/views/mus/desktop_window_tree_host_mus.cc).
This is because in Mash builds, the platform specific 'PlatformCursor'
and scale factor values are only set on Ozone side.

This cursor type information is used to set the native cursor type as
part of
the call chain to ui::ws::WindowTree::SetCursor.

  #0 0x558900d0e038 ui::(anonymous namespace)::SearchTable()
  #1 0x558900d0eaaa ui::GetCursorDataFor()
  #2 0x558900d0e1d2 ui::GetCursorBitmap()
  #3 0x558900d09fa3 ui::BitmapCursorFactoryOzone::GetDefaultCursorInternal()
  #4 0x558900d09e62 ui::BitmapCursorFactoryOzone::GetDefaultCursor()
  #5 0x558900d0eb51 ui::CursorLoaderOzone::SetPlatformCursor()
  #6 0x558902b5812a ui::ws::(anonymous namespace)::SetCursorOnResourceThread()
  #7 0x558902b58bdd ui::ThreadedImageCursors(..)
  (...)

In frame #4, BitmapCursorFactoryOzone::GetDefaultCursor is called only
with CursorType. The type passes through frame #3, and in frame #2
it is used to implicitly construct an ui::Cursor instance.

When the implicit ui::Cursor ctor is used, device_scale_factor defaults
to 0.0. Down the road, ::SearchTable ends up using "2x resources",
although the scale factor is not explicitly set to '2.0'. This causes
the cursor surface ends up offset'ed in both ChromeOS/Mash X11 and
Wayland builds.

Patch fixes this by only using 2x resource when a) device scale factor
is set to 2.0, and 2x resources are available. By default, hence, it
uses 1x resources, fixing the offset issue.

Issue #166

If user places the pointer/mouse on any end of a browser window, cursor
type changes accordingly, to indicated a possible interactive resize operation.

If the user crosses the browser window bounds through the same end, the mouse
type stored in ui::CursorManager isn't reset. If pointer reenters the
window through the same end, Aura tries to set the cursor type to the
same as previously (to indicate it is over the same end). During the
call chain, CursorManager::SetCursor compares the last Cursor stored
and the new one and updates the cursor instance if they differ.

In case of regular Chrome/x11 builds, the check passes because
CursorData is set to the Cursor instance, and values always differ
from the CursorData cached by CursorManager.
In case of Linux/Ozone builds, CursorData is only set on Ozone side,
so the call bail out and cursor is not updated.

Patch fixes it by resetting the cursor type whenever pointer leaves
the browser window. This ensures, when reentering from the same end, the
comparison in CursorManager::SetCursor passes, and cursor gets updated.

Issue #317

This CL fixes a case, when a new native window is created and
all the events (including a button up event) go to that new window.

Before this CL, when a new window was created, the previous
window's EventDispatcher state was left with a button down
state, which caused events to be sent to a wrong target.

As of now, when a native window looses a capture, an EventDispatcher
is explicitly reset to make it possible to continue consuming events.

Issue #318

fixup! Reset ui::ws::EventDispatcher's states when capture is lost.

EventDispatcher -> EventProcessor.

Bug: When using chrome with builtin window decoration (not
WindowManager's), tooltips stop showing after an interactive window
dragging or resize, until the next mouse down/up events.

Reason: whenever one clicks down with mouse,
aura::Env::mouse_button_flags_
is undistinguished set by
EnvInputStateController::UpdateStateForMouseEvent.
The flag remains set 'till the respective mouse up event happens, and it
is reset.
This allows at anytime/anywhere in the code to query whether a mouse is
up/down.

Problem is that when entering an interactive window dragging or
resize, X11 (and Wayland FWIW) delegates the host window manager
to perform the action. At the end, the window manager does not notify
the action is ended (for example, with a mouse release event). Browser,
then, gets stuck with non-zero aura::Env::mouse_button_flags_ until the
next mouse down/up.
TooltipController::OnMouseEvent, for instance, checks this flag before
showing
a tooltip, and after an interactive drag/resize, the flags are
erroneously set,
cause TooltipController to bail out earlier and not show the tooltips.

CL fixes this by not setting aura::Env mouse flags when clicking on the
non-client
area, similarly to how WindowEventDispatcher::PreDispatchMouseEvent
does not set 'mouse_pressed_handler_' when one is clicking on the
non-client area.

Issue #300

In external window mode, we can not rely on display::Display::id_
as a valid ws::Display identifier.
In order to fix this, patch (ab)uses the WindowId returned from
ws::DisplayManger, at creation time, and builds an unique identifier
token off of it.

This value is return by ws::Display::GetId method.

Issue #296

In Ozone/Chrome, DesktopWindowTreeHostMus installs a basic
NonClientFrameView instance (ClientSideNonClientFrameView), and relies
on Ash to fill in its content. This is not the case of Ozone/Linux
build.

For Chrome window decoration we are fine, since BrowserFrame
reimplements ::CreateNonClientFrameView [1], but for other Widgets
(including TaskManager), we end up without a proper window decoration.

Patch defaults DesktopWindowTreeHostMus::auto_update_client_area_ to 'false'
in Ozone/Linux builds, so that built-in default window decorations are provided.

We still need to make the Windows-looking theme of the decoration area
(light blue) to look better but this will be left over as a follow up.

Issue #260

[1] //chrome/browser/ui/views/frame/browser_frame.cc

CL changes ui/platform_window/x11 so that native
windows can have its bounds changed without being shown.
This matches the behavior in DesktopWindowTreeHostX11.

Issue #86

fixup! [ozone/x11] Implement Tooltip support

CL adds support for LeaveNofity in ui/platform_window/x11.
This is needed for hiding the tooltip when pointer moves out
of a chrome window.

Patch left separate for now for easy upstreaming.

Issue #86

fixup! [ozone/x11] Implement Tooltip support

1) Change in ui/events/platform/x11/x11_event_source_libevent.cc
has been upstreamed: https://crrev.com/c/790611

2) Change in ui/platform_window/x11/x11_window_base.cc is under review.
https://crrev.com/c/791290.
The proposed patch aligns our downstream code with the patch being
reviewed, and makes the delta against upstream way smaller.

Issue #266

CL uses the subsurface concept to implement support for tooltips.

Issue #86

fixup! [ozone/wayland] Implement Tooltip using subsurface

Fix crash on gnome shell by destroying a subsurface only after a
buffer is detached.

fixup! [ozone/wayland] Implement Tooltip using subsurface

This CL takes care of two issues:

1) By the time one hovers mouse over something that creates a tooltip,
a message is sent from the client (browser/aura) to the server (mus).
It is async call, so when mus actually gets the message and starts
the logic that creates/shows a tooltip window, user might have already
moved the mouse off the window bound.
When pointer moves off-window, WaylandWindow::GetParentWindow will return NULL.
Patch turns the existing DCHECK into an early return check.

2) When one moves the mouse off the chrome window, emit a ET_MOUSE_EXITED
mouse event, so that ToolTipController has (see view::corewm::GetTooltipTarget).

Issue #295

fixup! [ozone/wayland] Implement Tooltip using subsurface

We are now emitting ET_MOUSE_EXITED upon pointer leaving WL events.
CL updates the associated unittest's expectation: WaylandPointerTest::Leave.

Issue #295

In stock chrome/x11 code, appearance of actual platform windows
is triggered by DesktopWindowTreeHostX11::ShowWithState calls.
Patch makes chrome/mus follow the same behavior: instead of
PlatformWindow::Show to be called by default from PlatformDisplayDefault::Init,
tie it to PlatformDisplayDefault::SetNativeWindowState.

This is important for tooltips.

Issue #86

fixup! Let the client control appearance of ws::Display's

mus_demo must also set its visibility state manually.