Adding some references from offline discussion.

If we enable reprojection surfaces we lose the ability to sample the texture and do any ambient lighting in the vr shell environment (which currently is working in a prototype).

On the other hand secure content (DRM level 1) would work for free using the GVR reprojection surface (but we still wouldn't be able to sample it for lighting).

There may be something we could do if we had access to the GVR rendering implementation, but we would be blocked on them.

+Bill to correct me if I'm making stuff up about the secure content, and +skonig for his opinion on the relative priorities.

Is it ok if ambient lighting doesn't work, or do we need to find a solution that supports it?

Note that https://codereview.chromium.org/2613543002/ disables VrShell testing config and will need to be re-enabled after this issue is resolved.  See  issue 678018  for more context.

Removing this as a blocker of Chrome VR now that a better fix is in place for  issue 654851  (and testing config has already been re-enabled).

Does this constitute and aspirational goal?  Should we move it to go/chrome-vr-backlog?

This is separate from the GVR quad layer for content.  There's a protected external texture path for video.