[1/4][Ozone-Drm] Process display hotplug events sequentially

[Ozone-Drm] Process display hotplug events sequentially

If add,remove or add,add (scanning for devices) events are delivered
fast enough, the remove/add event would be processed before the first
add event. In the first case the state would be incorrect while in the
second case it would cause the device to be opened multiple times
(causing permission errors in one of the events). To avoid this, use a
sequenced worker pool to properly order events. The device path is used
to group events for the same device.

This CL also keeps track of the active devices such that we can ignore
duplicate events (possible due to device scanning) and reduce the number
of display configurations performed.

BUG=477792, 476728
Committed: https://crrev.com/e037bbf79d760921ed56cb0694b1defc598edadc
Cr-Commit-Position: refs/heads/master@{#327321}

[dnicoara, 2015-04-22 17:05:04]

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

[dnicoara, 2015-04-23 21:22:15]

Added a wrapper around WorkerPool to keep the sequential processing of events
for the same device.

[spang, 2015-04-27 21:54:33]

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

https://codereview.chromium.org/1072193008/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:250: while
(!event_queue_.empty()) {
I think it would be clearer to do:

while (!event_queue.empty() && !task_pending_) {
  // ....
}

.. for appropriately set task_pending.

Then call ProcessEvent() unconditionally.

https://codereview.chromium.org/1072193008/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:251: DisplayEvent
event = event_queue_.front();
Why can't you pop here?

[dnicoara, 2015-04-28 14:53:04]

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

https://codereview.chromium.org/1072193008/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:250: while
(!event_queue_.empty()) {
On 2015/04/27 21:54:33, spang wrote:
> I think it would be clearer to do:
> 
> while (!event_queue.empty() && !task_pending_) {
>   // ....
> }
> 
> .. for appropriately set task_pending.
> 
> Then call ProcessEvent() unconditionally.

Done.

https://codereview.chromium.org/1072193008/diff/60001/ui/ozone/platform/drm/h...
ui/ozone/platform/drm/host/drm_native_display_delegate.cc:251: DisplayEvent
event = event_queue_.front();
On 2015/04/27 21:54:33, spang wrote:
> Why can't you pop here?

The event would act as the |task_pending_| bool.

[spang, 2015-04-28 15:11:54]

lgtm

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

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

[commit-bot: I haz the power, 2015-04-28 16:26:47]

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

[commit-bot: I haz the power, 2015-04-28 17:20:45]

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

[commit-bot: I haz the power, 2015-04-28 17:20:46]

Dry run: This issue passed the CQ dry run.

[dnicoara, 2015-04-28 17:55:45]

The CQ bit was checked by dnicoara@chromium.org

[commit-bot: I haz the power, 2015-04-28 17:56:33]

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

[commit-bot: I haz the power, 2015-04-28 17:58:49]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-04-28 17:59:45]

Patchset 5 (id:??) landed as
https://crrev.com/e037bbf79d760921ed56cb0694b1defc598edadc
Cr-Commit-Position: refs/heads/master@{#327321}