[4/4][Ozone-Drm] Keep track of DRM devices in browser process

[Ozone-Drm] Keep track of DRM devices in browser process

Keeping the DRM devices open in the browser process means the kernel
doesn't need to clean up the display state when the GPU process crashes,
eliminating the flicker caused by the kernel disabling the CRTCs on GPU
crashes.

BUG=445773
Committed: https://crrev.com/7eb5cd9c17165102b9b25805c1f97cfde260aed8
Cr-Commit-Position: refs/heads/master@{#327557}

[dnicoara, 2015-04-27 14:22:20]

dnicoara@chromium.org changed reviewers:
+ spang@chromium.org

[dnicoara, 2015-04-27 16:46:55]

https://codereview.chromium.org/1064453003/diff/20001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_native_display_delegate.cc (right):

https://codereview.chromium.org/1064453003/diff/20001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:247:
drm_devices_.add(event.path(), handle.Pass());
Hmm, this will be problematic since the handle may be accessed by
OnChannelEstablished() while the worker thread is opening it.

[spang, 2015-04-27 22:23:15]

https://codereview.chromium.org/1064453003/diff/40001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_device_handle.cc (right):

https://codereview.chromium.org/1064453003/diff/40001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_device_handle.cc:35: file_ = base::File(path,
base::File::FLAG_OPEN | base::File::FLAG_READ |
The base::File abstraction provides little to no benefit here and has real
downsides (such as hiding the error code).

I think we should just call open().

[dnicoara, 2015-04-28 16:26:16]

https://codereview.chromium.org/1064453003/diff/40001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_device_handle.cc (right):

https://codereview.chromium.org/1064453003/diff/40001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_device_handle.cc:35: file_ = base::File(path,
base::File::FLAG_OPEN | base::File::FLAG_READ |
On 2015/04/27 22:23:15, spang wrote:
> The base::File abstraction provides little to no benefit here and has real
> downsides (such as hiding the error code).
> 
> I think we should just call open().

Done.

https://codereview.chromium.org/1064453003/diff/80001/ui/ozone/platform/drm/h...
File ui/ozone/platform/drm/host/drm_native_display_delegate.cc (right):

https://codereview.chromium.org/1064453003/diff/80001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:93: for (auto it =
drm_devices_.begin(); it != drm_devices_.end(); ++it) {
Added async close of the DRM handles.

https://codereview.chromium.org/1064453003/diff/100001/ui/ozone/platform/drm/...
File ui/ozone/platform/drm/host/drm_native_display_delegate.cc (right):

https://codereview.chromium.org/1064453003/diff/100001/ui/ozone/platform/drm/...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:352: proxy_->Send(new
OzoneGpuMsg_AddGraphicsDevice(
Also made sure the primary device is IPC-ed first.

[spang, 2015-04-28 17:05:38]

do you need to rebase?

https://codereview.chromium.org/1064453003/diff/100001/ui/ozone/platform/drm/...
File ui/ozone/platform/drm/host/drm_device_handle.cc (right):

https://codereview.chromium.org/1064453003/diff/100001/ui/ozone/platform/drm/...
ui/ozone/platform/drm/host/drm_device_handle.cc:57:
CHECK(!S_ISDIR(file_info.st_mode));
what's this for?

If it's a directory open() fails with EISDIR.

[dnicoara, 2015-04-28 18:06:50]

Yep, needed a rebase ... done.

https://codereview.chromium.org/1064453003/diff/100001/ui/ozone/platform/drm/...
File ui/ozone/platform/drm/host/drm_device_handle.cc (right):

https://codereview.chromium.org/1064453003/diff/100001/ui/ozone/platform/drm/...
ui/ozone/platform/drm/host/drm_device_handle.cc:57:
CHECK(!S_ISDIR(file_info.st_mode));
On 2015/04/28 17:05:38, spang wrote:
> what's this for?
> 
> If it's a directory open() fails with EISDIR.

Doh, you're right, removed.

[spang, 2015-04-28 18:23:36]

lgtm

[dnicoara, 2015-04-29 18:25:01]

The CQ bit was checked by dnicoara@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-04-29 18:26:45]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1064453003/140001

[commit-bot: I haz the power, 2015-04-29 18:56:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-04-29 18:56:39]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[dnicoara, 2015-04-29 19:11:17]

The CQ bit was checked by dnicoara@chromium.org to run a CQ dry run

[dnicoara, 2015-04-29 19:11:18]

The patchset sent to the CQ was uploaded after l-g-t-m from spang@chromium.org
Link to the patchset: https://codereview.chromium.org/1064453003/#ps160001
(title: "Update due to change in ScopedPtrHashMap definition")

[commit-bot: I haz the power, 2015-04-29 19:12:40]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1064453003/160001

[dnicoara, 2015-04-29 20:47:51]

The CQ bit was unchecked by dnicoara@chromium.org

[dnicoara, 2015-04-29 20:47:55]

The CQ bit was checked by dnicoara@chromium.org

[commit-bot: I haz the power, 2015-04-29 20:49:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1064453003/160001

[commit-bot: I haz the power, 2015-04-29 21:28:05]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-04-29 21:29:18]

Patchset 9 (id:??) landed as
https://crrev.com/7eb5cd9c17165102b9b25805c1f97cfde260aed8
Cr-Commit-Position: refs/heads/master@{#327557}