[WIP][Ozone] Support external touchscreens

[WIP][Ozone] Support external touchscreens

BUG=425258

[dnicoara, 2014-10-20 19:37:19]

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

[dnicoara, 2014-10-20 19:37:20]

There are a few things that I think require attention, but I'd like to discuss
first and make sure this is going in the right direction.

TODOs:
1) --ash-host-window-bounds isn't supported since display configuration is
completely bypassed when the flag is passed in.
2) Non-CrOS builds won't have touch support since:
  a) there is no NativeDisplayDelegate,
  b) nothing to create the display <-> touchscreen mapping.

(2) can be solved by adding a default mapping within the DRI platform. A bit
annoying since we'd start duplicating code. And I think we want to leave the
mapping to Ash since that logic can get more complicated (as in might require
user interaction) as we add support for multiple external monitors.

(1) can be supported by implementing the above solution for (2).

[spang, 2014-10-21 22:38:22]

I'm not enthusiastic about this.. I find it fairly impenetrable.

Why are we pushing the association down into DeviceDataManager, only to get it
back out again somewhere bizarrely later, necessitating a lot of complexity
(caching..)?

[dnicoara, 2014-10-22 14:37:13]

On 2014/10/21 22:38:22, spang wrote:
> I'm not enthusiastic about this.. I find it fairly impenetrable.
> 
> Why are we pushing the association down into DeviceDataManager, only to get it
> back out again somewhere bizarrely later, necessitating a lot of complexity
> (caching..)?

The association happens in Ash. I'd like to leave the association outside of
Ozone since matching displays and touchscreens will likely get more complex as
we start supporting multiple external touchscreen displays and will likely
require user interaction to properly associate them.

[spang, 2014-10-22 14:58:32]

On 2014/10/22 14:37:13, dnicoara wrote:
> On 2014/10/21 22:38:22, spang wrote:
> > I'm not enthusiastic about this.. I find it fairly impenetrable.
> > 
> > Why are we pushing the association down into DeviceDataManager, only to get
it
> > back out again somewhere bizarrely later, necessitating a lot of complexity
> > (caching..)?
> 
> The association happens in Ash. I'd like to leave the association outside of
> Ozone since matching displays and touchscreens will likely get more complex as
> we start supporting multiple external touchscreen displays and will likely
> require user interaction to properly associate them.

Even supposing we leave association entirely to ash (and I'm not actually
convinced), the way the current patch does that is unnecessarily roundabout.

This patch is moving state between 2 components by means of a 3rd component
(events), that simply implements an otherwise unneeded global object. Please
don't do it this way.

You can call into ui/ozone/public from ash without restriction.

[dnicoara, 2014-10-22 18:00:08]

On 2014/10/22 14:58:32, spang wrote:
> On 2014/10/22 14:37:13, dnicoara wrote:
> > On 2014/10/21 22:38:22, spang wrote:
> > > I'm not enthusiastic about this.. I find it fairly impenetrable.
> > > 
> > > Why are we pushing the association down into DeviceDataManager, only to
get
> it
> > > back out again somewhere bizarrely later, necessitating a lot of
complexity
> > > (caching..)?
> > 
> > The association happens in Ash. I'd like to leave the association outside of
> > Ozone since matching displays and touchscreens will likely get more complex
as
> > we start supporting multiple external touchscreen displays and will likely
> > require user interaction to properly associate them.
> 
> Even supposing we leave association entirely to ash (and I'm not actually
> convinced), the way the current patch does that is unnecessarily roundabout.
> 
> This patch is moving state between 2 components by means of a 3rd component
> (events), that simply implements an otherwise unneeded global object. Please
> don't do it this way.
> 
> You can call into ui/ozone/public from ash without restriction.

So we're making a 4th component because DDM is a singleton? We'll just end up
writing an Ozone version of DDM.

Regardless of which level we put the logic in, it'll be about the same amount of
complexity. Even if all of the mapping logic is in Ozone, Ash still needs access
to it since touchscreens are treated differently.

The one thing that I'd like to simplify is adding the display bounds in pixels
and native resolution to gfx::Display so that I can use gfx::Screen to find the
display associated with a PlatformWindow. That would drop the requirement of
needing an internal DisplayManager.

[spang, 2014-10-22 18:38:24]

On 2014/10/22 18:00:08, dnicoara wrote:
> On 2014/10/22 14:58:32, spang wrote:
> > On 2014/10/22 14:37:13, dnicoara wrote:
> > > On 2014/10/21 22:38:22, spang wrote:
> > > > I'm not enthusiastic about this.. I find it fairly impenetrable.
> > > > 
> > > > Why are we pushing the association down into DeviceDataManager, only to
> get
> > it
> > > > back out again somewhere bizarrely later, necessitating a lot of
> complexity
> > > > (caching..)?
> > > 
> > > The association happens in Ash. I'd like to leave the association outside
of
> > > Ozone since matching displays and touchscreens will likely get more
complex
> as
> > > we start supporting multiple external touchscreen displays and will likely
> > > require user interaction to properly associate them.
> > 
> > Even supposing we leave association entirely to ash (and I'm not actually
> > convinced), the way the current patch does that is unnecessarily roundabout.
> > 
> > This patch is moving state between 2 components by means of a 3rd component
> > (events), that simply implements an otherwise unneeded global object. Please
> > don't do it this way.
> > 
> > You can call into ui/ozone/public from ash without restriction.
> 
> So we're making a 4th component because DDM is a singleton? We'll just end up
> writing an Ozone version of DDM.
> 
> Regardless of which level we put the logic in, it'll be about the same amount
of
> complexity. Even if all of the mapping logic is in Ozone, Ash still needs
access
> to it since touchscreens are treated differently.
> 
> The one thing that I'd like to simplify is adding the display bounds in pixels
> and native resolution to gfx::Display so that I can use gfx::Screen to find
the
> display associated with a PlatformWindow. That would drop the requirement of
> needing an internal DisplayManager.

Okay, well, I'm strongly against landing this as written.

We need to work torwards a sane division of labor between ash/athena/mojo and
ozone here instead of taking the existing boundary as fixed.

Michael