ccing Stephane. I wonder if this could be related in any way to b/36702888

As per dcastagna@, disable HW overlays (!--enable-hardware-overlays in /etc/chrome_dev.conf) makes the problem go away.

58 is stable now, is this going to get any attention?

+gurchetansingh in case this is related to b/36201018

+tfiga as FYI since he's been helping out on random graphics stuff on Kevin.

Hmm, maybe this is related to the fact that we're switching CRTCs when plugging an external monitor and that only one CRTC has enough planes to support overlays and it's the same one that also supports AFBC. Any possibility that Chrome gets confused and tries scheduling things as overlays for the other CRTC?

If I understand correctly the report says that the Android app is displayed on the external screen. kevin can drive the external monitor only with the big VOP (AFBC + a bunch of planes).
This means Chrome is scheduling more than one plane on the CRTC that supports multiple overlays, thus I don't think Chrome is confused in this case.

Weirdly, I couldn't seem to reproduce this on R60.

dianders@: What did you test it with? It seems like android apps are now smaller by default when you open them, and I can't reproduce it when that is the case (youtube by default seems to open in portrait mode now).
If I try Alto with a maximized window I still see a lot of issues, in particular when moving the cursor on the top of the screen and the title bar appears.

@9: Ah, that's probably it then.  Yes, the play store window was smaller.  I should have mentioned that.

This is higher priority now that external display support went in for Android ? (I haven't yet had a chance to see what it looks like now)
 
The previous workaround was not to display Android apps on external display (and sometimes Android notification caused an issue but that was livable)

This is quite a complicated task, because it involves coordination between multiple layers of the stack. In particular, allocating a buffer the way we do it right now doesn't ensure that it is going to be displayable on an external display.

Just a random idea: Can we just disable overlays for external displays for the time being? Comment #3 clearly states that without overlays things are working well and this is expected given that we don't move any surfaces between the screens anymore (they are only used by GPU compositor).

@14: I think that's pretty much what is happening now (right now we always add an extra compositing stage so no overlays and no fullscreen optimization). I would expect this bug is about fixing these.

As per discussion with marcheu@, I don't think we should disable overlays on external displays.

From Chrome point of view Ozone tests and submits HW overlays on the same CRTC in both scenarios (with or without an external monitor), since we use the big VOP to drive the external monitor when present, and big VOP for the main screen when there isn't an external monitor.

If when big VOP is associated to a different connector (or encoder) than eDP it can't handle a specific configuration of HW overlays, DRM_MODE_ATOMIC_TEST_ONLY should reject that configuration.

I suspect the issue is in the rockchip driver since it should handle HW overlays the DP or at least reject the configuration.

While working on a workaround we noticed the issue is not limited to the external monitor.
HW overlays downscaled by a factor of 2 are causing issues (the whole screen blinking). This happens on the primary monitor too.
We noticed it on external displays since android content is produce with a scale factor of 2 on kevin, and downscaled when moved to an external monitor.

Surprisingly, downscaling to a different factor seems to be OK.
Stephane pointed out this is likely a bug in rockchip drivers.

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

commit 8aa1867fdd801c9b01367a02253ece99346adfbc
Author: Daniele Castagna <dcastagna@chromium.org>
Date: Tue Jul 04 01:15:43 2017

ozone: Reject overlays downscaled by a factor of 2.

Downscaling overalys by a factor of 2 is causing serious issues
on rk3399 platforms.
This CL disables the downscaling on the Chrome side while we work
on a fix in the rockchip module.

Bug:  709105 
Test: wayland_simple_client  --use-drm=rockchip --scale=4
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I08e3dcaaf138dff343a7714618f0400037b29b72
Reviewed-on: https://chromium-review.googlesource.com/555770
Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#484035}
[modify] https://crrev.com/8aa1867fdd801c9b01367a02253ece99346adfbc/ui/ozone/platform/drm/gpu/hardware_display_plane_atomic.cc

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+josafat for manual review.

Assigning to Josafat to get extra attention.

Over to Daniele to actually do the merge.

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

commit 0534e1efe7da4feb5292e7e1935b397c770afe75
Author: Daniele Castagna <dcastagna@chromium.org>
Date: Wed Jul 12 20:57:51 2017

ozone: Reject overlays downscaled by a factor of 2.

Downscaling overalys by a factor of 2 is causing serious issues
on rk3399 platforms.
This CL disables the downscaling on the Chrome side while we work
on a fix in the rockchip module.

TBR=dcastagna@chromium.org

(cherry picked from commit 8aa1867fdd801c9b01367a02253ece99346adfbc)

Bug:  709105 
Test: wayland_simple_client  --use-drm=rockchip --scale=4
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I08e3dcaaf138dff343a7714618f0400037b29b72
Reviewed-on: https://chromium-review.googlesource.com/555770
Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#484035}
Reviewed-on: https://chromium-review.googlesource.com/568847
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#599}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/0534e1efe7da4feb5292e7e1935b397c770afe75/ui/ozone/platform/drm/gpu/hardware_display_plane_atomic.cc

Tested ToT(61) build on kevin, and observation is that apps do not transfer to external display at time primary display switch is done. If you drag an app to extended display first, and then switch the primary - the app comes to onboard screen, and if do it again - goes back to external.
After switching the app(Temple run) stops responding. sontis@ will link logs in next update.

Screenshots and logs are present at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cros/709105/?debugUI=CLOUD

@#27: The issues you're describing don't seem to be what this bug is about (while they're in the way of testing it).

This bug, AFAIU, is related to the whole screen blinking and flickering to black when an android app is scanned out as an overlay an scaling by a factor of two is used.
This frequently happens on external monitor.

The same issue also happens if you change the internal display resolution on the main panel when no external monitor is attached (ctrl + - twice.)

Thanks for the clarification. We'll file a separate issue(c#27,28).

This is Fixed then, right?

kalin: if you can please post a comment with the bug number of the new bug you filed, that'd be super useful for those trying to follow this.  Thanks!  :)

From what I tested, it seemed fixed. We're now doing compositing in those cases where scanning out a scaled overlay by a factor of two seemed to cause the whole screen to flicker.

If someone else can verify it, I'd feel more confident about it.
It's easy to reproduce without an external monitor.
Just run an android app (playstore) on kevin with the screen resolution set to 2400x1600. Half of the screen will go black. After the fix, that shouldn't happen.

Attaching a screenshot to show how it looks on the primary screen.

Deleted: IMG_20170713_123644.jpg 1.6 MB

	IMG_20170713_123644.jpg 1.6 MB View Download

Filed  crbug.com/745998  to properly fix the scaling issue and remove the workaround.

DS, this has nothing to do with 743277. This was a specific rockchip issue about scaling by 2.