-
Change ScreenManagerOzoneExternal to be able to send out display::Display updates via ws::UserDisplayManager (which will send the display::Display to the client). For this, patch extends OzonePlatform with a method that allows its instances (X11, Wayland, etc) to query the host system its displays data (resolution only for now). ScreenManagerOzoneExternal then calls to ws::DisplayManager, which calls to ws::UserDisplayManager. In order to allow ws::DisplayManager to get display::Display and not change ws::Display in external mode, a new hook was added: ::OnHostDisplaysReady. Wayland support will come in a fixup. Issue #43 Contains fixup in ozone_platform_headless for fixing https://build-chromium.igalia.com/#builders/1/builds/149 (TEMP) fixup! Allow ws to pass display::Display data to Aura/client Fix creating ui::Display after https://codereview.chromium.org/2829733002/ is upstreamed fixup! Allow ws to pass display::Display data to Aura/client Use a non-zero value for FrameDecorationValues::normal_client_area_insets, so that the tabstrip has room to get drawn. The value '33' was picked up by mimic'ing ChromeOS's Chrome/Mash. Issue #56 Issue #43 fixup! Allow ws to pass display::Display data to Aura/client PR #50, reverted an initial hack added as part of the commit "Allow chrome launch with --mus parameter", but it left over one bit. This commits removes the left over bit, but in the next rebase this should be squashed against "Allow chrome launch with --mus parameter" commit, not "Allow ws to pass display::Display data to Aura/client". fixup! Allow ws to pass display::Display data to Aura/client null-check the pointer before dereferencing it. nullptr is deliberately pass in sometimes. Issue #43 fixup! fixup! Allow ws to pass display::Display data to Aura/client During the April/24 rebase, msisov@ hardcoded the ScreenManager creating in ws::service. This method adds a call to ws::Service::OnWillCreateTreeForWindowManager, similarly to how internal window mode does. fixup! Allow ws to pass display::Display data to Aura/client Implement OzonePlatformWayland::QueryHostDisplaysData. Note that by the time WaylandOutput is instantiated, the associated WaylandConnection object needs to be able to receive and process events, so that it can handle wl_output_listener hooks. Issue #43 fixup! Allow ws to pass display::Display data to Aura/client Now that Mus runs as a thread within the Browser process, we can not install ScreenManagerOzoneExternal's Screen instance. Instead, it is only used internally to track displays (add, remove, modify). This fixes a crash at shutdown. PR #250 fixup! Allow ws to pass display::Display data to Aura/client Stop early listen to events, when wl_output is installed. This call was causing us to enter the event loop earlier than we should, and occasional hangs at start up. Instead, when display/screen data is queried, we "ask" the server to close all pending requests associated with a given wl_display. Screen dimensions then can be queried. Issue #212 fixup! Allow ws to pass display::Display data to Aura/client Fix unittests: after the change to WaylandConnection::Initialize, the unittests started to hang on startup, because the WaylandOutput::Geometry had always been empty. The fix is to create a MockOutput, which is a global wl object on the server side, with non-empty geometry, which will be set during initializtion step. The second fix is to modify WaylandConnectionTest::Output in such a way that it would not wait in a blocking run loop. At the moment, we have a wl_display_roundtrip run until WaylandOutput::Geometry is set instead.
015f3ed1
