Fast ink code behaves in a similar way to Exo. If Exo works then there's no major reason for fast ink to not also work.

FYI, the fast ink code uses zero-copy GMBs and and single buffer mode for low-latency rendering. It should work without native GMB support and without HW overlays but it won't be efficient.

I can repro also on linux with target_os="chromeos".

* Apply https://chromium-review.googlesource.com/#/c/chromium/src/+/739957 to get around a thread restriction DCHECK ( issue 778734 ) and add logging.
* Run xinput list and get your mouse ID. It should be a number like 10.
* autoninja -C out/Debug -j500 -l60 chrome && out/Debug/chrome --ash-host-window-bounds="1280x768" --user-data-dir=/w/udd --ash-dev-shortcuts --ash-debug-shortcuts --use-first-display-as-internal --has-internal-stylus --force-enable-stylus-tools --pen-devices=10
* Tap stylus icon in shelf, then tap laser pointer

Under classic ash, you see the red point/line.

Add --mus to the command line and you don't see the point/line anymore.

The ash and views code seems OK -- it's turning the tool on, creating the FastInkView, has appropriate transforms, etc. I also don't see any early exits being hit for things like failures to allocate buffers.

[19388:19388:1026/111104.375105:ERROR:fast_ink_view.cc(227)] JAMES new FastInkView transform [ +1.0000 +0.0000 +0.0000 +0.0000  
  +0.0000 +1.0000 +0.0000 +0.0000  
  +0.0000 +0.0000 +1.0000 +0.0000  
  +0.0000 +0.0000 +0.0000 +1.0000 ]
[19388:19388:1026/111104.386927:ERROR:laser_pointer_view.cc(332)] JAMES DrawCircle 1128.000000,592.000000 num 1
[19388:19388:1026/111104.442333:ERROR:laser_pointer_view.cc(332)] JAMES DrawCircle 1128.000000,592.000000 num 2
[19388:19388:1026/111104.443745:ERROR:laser_pointer_view.cc(332)] JAMES DrawCircle 1128.000000,592.000000 num 7
<snip>
[19388:19388:1026/111104.580943:ERROR:laser_pointer_view.cc(332)] JAMES DrawCircle 1128.000000,592.000000 num 3
[19388:19388:1026/111104.597150:ERROR:laser_pointer_view.cc(332)] JAMES DrawCircle 1128.000000,592.000000 num 2
[19388:19388:1026/111104.613403:ERROR:laser_pointer_view.cc(332)] JAMES DrawCircle 1128.000000,592.000000 num 2
[19388:19388:1026/111104.645824:ERROR:fast_ink_view.cc(234)] JAMES del FastInkView

I sometimes see this after turning off the laser pointer:

[19388:20772:1026/111124.458851:ERROR:surface_manager.cc(482)] Old/orphaned temporary reference to SurfaceId(FrameSinkId(2, 45), LocalSurfaceId(1, (E6650B228396E6F67DC4D236C27A085)lu))

I see the same behavior and logs on device on caroline with --mus. I can open the Play Store, so I suspect exo is working. Maybe this is some kind of viz problem?

Passing along to Peng since this is closer to an area he's currently working in.

FYI. With CL[1], laser pointer starts drawing the red pointer on screen, but after several frames, the laser pointer stops updating. 

[1]https://chromium-review.googlesource.com/c/chromium/src/+/753292

With CL https://crrev.com/c/753292 and below workaround, the laser pointer will work correctly. 
reveman@ Do you have any idea why we need below workaround for mus? Thanks.

diff --git a/ash/fast_ink/fast_ink_view.cc b/ash/fast_ink/fast_ink_view.cc
index 6d8692d29b7f..d4537a80ff33 100644
--- a/ash/fast_ink/fast_ink_view.cc
+++ b/ash/fast_ink/fast_ink_view.cc
@@ -412,7 +412,11 @@ void FastInkView::UpdateSurface() {
 
   if (resource->image) {
     gles2->ReleaseTexImage2DCHROMIUM(GL_TEXTURE_2D, resource->image);
-  } else {
+    gles2->DestroyImageCHROMIUM(resource->image);
+    resource->image = 0;
+  }
+
+  if (!resource->image) {
     resource->image = gles2->CreateImageCHROMIUM(
         gpu_memory_buffer_->AsClientBuffer(), buffer_size.width(),
         buffer_size.height(), SK_B32_SHIFT ? GL_RGBA : GL_BGRA_EXT);

As my understanding, without workaround in comment 6. Mus will not pick up the changes (pixels) in the gpu_memory_buffer_, it will continue using the texture with stale data. I am not sure it is an issue in viz or it is a GL related issue.

Turn out it is because fast ink sends unverified sync tokens to compositor. It only works when fast ink and the compositor share the same GPU channel. But for mus and mash, fast ink is running in the ash process. It uses a diferent GPU channel.

I think probably we should add debug checks in CompositorFrameSink to catch this kind of issues.

Are we not doing the same for exo? That is, sends unverified sync tokens to compositor.

Exo was doing the same, but we fixed it with CL https://chromium-review.googlesource.com/c/chromium/src/+/716663/7/components/exo/surface_tree_host.cc

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

commit c71a0a9f01350b2ee64140e23bf732a263b820e5
Author: Peng Huang <penghuang@chromium.org>
Date: Mon Nov 06 22:21:18 2017

fast_ink: Fix the no update issue with mus and mash.

With mus and mash, the FastInkView is running in ash process. It doesn't
share the GPU channel with the compositor. So the compositor can not
consume unverified sync tokens generated by fast ink. It casues the
problem. Fix the problem by using verfied sync tokens with mus and mash.

Bug:  778322 
Change-Id: I4c501f07a050996f39ae33be57f0b5571f39f8c2
Reviewed-on: https://chromium-review.googlesource.com/755098
Reviewed-by: David Reveman <reveman@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514256}
[modify] https://crrev.com/c71a0a9f01350b2ee64140e23bf732a263b820e5/ash/fast_ink/fast_ink_view.cc

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

commit c4d1051e3d95f8cd9fbddd3b0223dd3bb72f3a4a
Author: Peng Huang <penghuang@chromium.org>
Date: Mon Nov 06 22:32:57 2017

mus: Fix the stylus laser pointer issue.

The FastInkView resizes the aura::Window to screen size first, and then
create FrameSink from it. In that case, the last_surface_size_in_pixels_
is 0x0, so the PrimarySurfaceInfo will not be set correctly. This CL fixes
the problem by setting the last_surface_size_in_pixels_ to the size of
the aura::Window during creating the FrameSink.

Bug:  778322 
Change-Id: Ia70f6c77383a8416347e2c7bf85e90b44cea74ea
Reviewed-on: https://chromium-review.googlesource.com/753292
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514262}
[modify] https://crrev.com/c4d1051e3d95f8cd9fbddd3b0223dd3bb72f3a4a/ui/aura/local/window_port_local.cc
[modify] https://crrev.com/c4d1051e3d95f8cd9fbddd3b0223dd3bb72f3a4a/ui/aura/mus/window_port_mus.cc
[modify] https://crrev.com/c4d1051e3d95f8cd9fbddd3b0223dd3bb72f3a4a/ui/aura/window_unittest.cc

Migrating from Internals>Viz to Internals>Services>Viz.