Remove no-op grace area touch calibration code

Remove no-op grace area touch calibration code

BUG=None
TEST=None

Committed: https://crrev.com/3845fbb8f0f73e3c44137295e73cafadbd6f0068
Cr-Commit-Position: refs/heads/master@{#318993}

[pkotwicz, 2015-01-23 19:31:05]

pkotwicz@chromium.org changed reviewers:
+ skuhne@chromium.org

[pkotwicz, 2015-01-23 19:34:33]

skuhne@ PTAL

https://codereview.chromium.org/872033002/diff/1/ui/aura/window_tree_host_x11.cc
File ui/aura/window_tree_host_x11.cc (left):

https://codereview.chromium.org/872033002/diff/1/ui/aura/window_tree_host_x11...
ui/aura/window_tree_host_x11.cc:152: const int resolution_y = bounds.height();
My understanding is that the following is always true:
y < resolution_y

https://codereview.chromium.org/872033002/diff/1/ui/aura/window_tree_host_x11...
ui/aura/window_tree_host_x11.cc:183: y < resolution_y - top_ + bottom_ *
kGraceAreaFraction)
My understanding is that this if statement is never run. I think that the
ChromeOS devices with touchscreen that we ship either have no bezel or just a
bottom bezel?

[pkotwicz, 2015-01-23 19:37:23]

I think that the code that I have removed is unnecessary, but am not sure. I
believe you wrote the original implementation
(https://chromiumcodereview.appspot.com/10306014/) so was hoping to get your
feedback. https://chromiumcodereview.appspot.com/10306014/

The possible results are:
This code is not needed, Yay!
This code is needed, so ozone needs to be fixed to do this logic

[Mr4D (OOO till 08-26), 2015-01-27 13:35:45]

Please see comments!

https://codereview.chromium.org/872033002/diff/1/ui/aura/window_tree_host_x11.cc
File ui/aura/window_tree_host_x11.cc (left):

https://codereview.chromium.org/872033002/diff/1/ui/aura/window_tree_host_x11...
ui/aura/window_tree_host_x11.cc:152: const int resolution_y = bounds.height();
This has to be enabled by the TP driver. It was meant to be used for the Pixel -
however - due to bending ghost touch events we disabled these things at the
time. 

But they might come back. Please check with our touch gurus if we have decided
to not use bezel anymore.

https://codereview.chromium.org/872033002/diff/1/ui/aura/window_tree_host_x11...
ui/aura/window_tree_host_x11.cc:183: y < resolution_y - top_ + bottom_ *
kGraceAreaFraction)
At the moment only the bottom bezel is reliable. Yes. However that might be
subject to change. Do we need to keep it around for it? I guess not.

[pkotwicz, 2015-01-27 16:13:14]

pkotwicz@chromium.org changed reviewers:
+ sadrul@chromium.org

[pkotwicz, 2015-01-27 16:13:15]

+touch guru sadrul@

[sadrul, 2015-01-27 16:40:20]

There seems to be a bug about touching the bezel: crbug.com/452076 Does this
change affect that in any way?

[pkotwicz, 2015-01-27 16:44:15]

Nope, kuscher@'s bug has to do with ozone and this CL has to do with X11

[pkotwicz, 2015-01-27 16:44:16]

Nope, kuscher@'s bug has to do with ozone and this CL has to do with X11

[sadrul, 2015-01-27 16:47:06]

On 2015/01/27 16:44:16, pkotwicz wrote:
> Nope, kuscher@'s bug has to do with ozone and this CL has to do with X11

Does ozone actually need something similar to the code being removed? (ie.
https://codereview.chromium.org/872033002/#msg3)

[pkotwicz, 2015-01-27 16:57:29]

If the code in this CL cannot be removed, then ozone would need similar logic,
yes. I think that ozone does not properly handle top and left bezels so that
would need to be fixed.

[pkotwicz, 2015-01-27 16:58:53]

For completeness, I fixed the bezel bug in ozone last week. See
http://crbug.com/450086

[Mr4D (OOO till 08-26), 2015-01-27 22:27:16]

Just for the sake of completeness: This bezel code was trying to address a touch
area beyond the display (Pixel was able to give sensor information there). So if
we get devices which can do that it might be useful -but if there is no plan for
it at the time we could get rid of it.

[sadrul, 2015-01-27 23:57:46]

Cool. Assuming this doesn't cause an obvious regression, lgtm.

Ideally we would move TouchEventCalibrate elsewhere so that we don't need to
explicitly do the calibration in WindowTreeHostX11, and instead creating a
ui::TouchEvent will be auto-calibrated when appropriate.

[pkotwicz, 2015-01-28 00:04:52]

I am going to take some more time to understand how events in the bezel work on
ChromeOS. My understanding is that we use the bottom bezel on the Chromebook
Pixel

[Mr4D (OOO till 08-26), 2015-01-28 12:22:18]

That is correct - the bottom bezel is still there, but the other bezels (left
and right) were there also (I implemented them). However due to HW reasons we
turned them off.

[Mr4D (OOO till 08-26), 2015-02-04 03:45:27]

lgtm

I think that unless we have hardware which uses this, we can remove this for the
time being.

[pkotwicz, 2015-03-04 00:17:56]

Landing this CL. I looked into this some more. The grace area is incorrectly
computed for the bottom bezel. Given that only the bottom bezel's enabled, it is
worth removing the grace area code.

[pkotwicz, 2015-03-04 00:18:00]

Landing this CL. I looked into this some more. The grace area is incorrectly
computed for the bottom bezel. Given that only the bottom bezel's enabled, it is
worth removing the grace area code.

[pkotwicz, 2015-03-04 00:18:02]

Landing this CL. I looked into this some more. The grace area is incorrectly
computed for the bottom bezel. Given that only the bottom bezel's enabled, it is
worth removing the grace area code.

[pkotwicz, 2015-03-04 00:18:52]

The CQ bit was checked by pkotwicz@chromium.org

[commit-bot: I haz the power, 2015-03-04 00:19:32]

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

[commit-bot: I haz the power, 2015-03-04 01:35:11]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-04 01:36:17]

Patchset 1 (id:??) landed as
https://crrev.com/3845fbb8f0f73e3c44137295e73cafadbd6f0068
Cr-Commit-Position: refs/heads/master@{#318993}