This may be related to 711333, but Sadrul suggested we likely want to address just this part rather than all of 711333.

I think this is happening because with --mus, the display config is happening on the UI thread but the NDD delegate is running on the mus thread yes?

sadrul@ your changes are most likely to have affected this? Care to take a look?

Namely, this is problematic line where ozone is going to UI instead of WS.

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/host/drm_gpu_platform_support_host.cc?type=cs&q=DrmGpuPlatformSupportHost::OnChannelEstablished&sq=package:chromium&l=123

With Sadrul's patch I get a hang. Specifically chrome main is blocked waiting for a sync call to finish. AFAICT this occurs because DrmDisplayHostManager::GpuHasUpdatedNativeDisplays() is no longer called with the patch. This is important as it appears GpuHasUpdatedNativeDisplays() is what triggers calling a callback that is responsible for triggering the sync call to complete. I don't know enough of the specifics of GpuHasUpdatedNativeDisplays to know why it isn't completing with Sadrul's patch.

The CL referenced in comment #5: https://chromium-review.googlesource.com/c/chromium/src/+/830749

I think kylechar@ is going to look at it?

Yep, I can look into this.

With sadruls patch the UI thread is deadlocked waiting the synchronous IPC mojom::NativeDisplayDelegate::Initialize(). An IPC response from the GPU process is routed to the UI thread, which is blocking waiting for mojom::NativeDisplayDelegate::Initialize, because the IPC is routed to the wrong thread here:

https://cs.chromium.org/chromium/src/content/browser/gpu/gpu_process_host.cc?l=696&rcl=15d5aac54f5b11b8a9feff54ecb5c450d0e60515

There are a couple of places where we end up on the UI thread instead of the mus thread. We can try to fix all of them for --mus or if the new mojo Ozone path is workable that could be a cleaner solution?

In hopes of shipping --mus sooner I'm looking to minimize risk. I suspect launching mojo ozone would bring additional risk. Is it possible to fix up the threading issues?

Is possibly shipping the current --mus configuration slightly sooner worth taking engineers off finishing ozone/drm/mojo? The mojo path makes for a much cleaner fix for this that doesn't risk destabilizing CrOS or increase code debt.

I don't think we need to wit for ozone-mojo. I have updated https://chromium-review.googlesource.com/c/chromium/src/+/830749 to include a change that I *think* is going to address the deadlock mentioned in comment #9. (but I am WFH'ing, so can't test on a device yet; but I suspect something similar should help).

I continue to think ozone-mojo should just replace ozone-legacy-ipc in all chrome, whether mus is turned on or not. Tying this with mus does not make a lot of sense to me.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/53ce638c710f10525dc55b46bcb01b6a37e775bc

commit 53ce638c710f10525dc55b46bcb01b6a37e775bc
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Thu Jan 11 00:52:46 2018

ozone/drm: Use the ctor task-runner if available.

When running with --mus, OzonePlatform instance is created after the
thread already has a task-runner. Use that as the task-runner for the
UI thread from ozone-drm. If the task runner is not available during
creation (which is the case with regular chrome), then get the task
runner from the caller of OnGpuProcessLaunched().

Also, update GpuPlatformSupportHost so that OnMessageReceived() can be
called from any thread. The implementation itself (in drm) is then
responsible for making sure the message is handled in the right thread.
This allows the message to be handled in the UI thread when not running
with mus, and from the window-service thread when mus is running.

Additionally, introduce a lock for the overlay cache, since it can now
be accessed from multiple threads with mus (UI thread by the layer
compositor, and the window-server thread for handling the relevant IPC
messages from the viz/gpu process).

BUG= 795069 

Change-Id: Ieeba8ec5a536bc180d3d8a8ca06cce03e6e39f10
Reviewed-on: https://chromium-review.googlesource.com/830749
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528509}
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/content/browser/gpu/gpu_process_host.cc
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/platform/drm/DEPS
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/platform/drm/host/drm_gpu_platform_support_host.cc
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/platform/drm/host/drm_gpu_platform_support_host.h
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/platform/drm/host/drm_overlay_manager.cc
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/platform/drm/host/drm_overlay_manager.h
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/public/gpu_platform_support_host.cc
[modify] https://crrev.com/53ce638c710f10525dc55b46bcb01b6a37e775bc/ui/ozone/public/gpu_platform_support_host.h

This is fixed now, right?

This should now be fixed, yes.