Revert of compositor: Fix texture flipping for SW mirroring with surfaceless

Revert of compositor: Fix texture flipping for SW mirroring with surfaceless (patchset #13 id:240001 of https://codereview.chromium.org/846063002/)

Reason for revert:
The original patch breaks software mirroring mode on at least veyron_jerry,
and quite possibly all non-freon systems.

BUG=451804
Original issue's description:
> compositor: Fix texture flipping for SW mirroring with surfaceless
> 
> Ozone-surfaceless renders the scene flipped, so the texture contents are
> inverted from what they should be. This fixes the mirroring logic to
> un-flip the texture when needed, and also to send the right sub-buffer
> update rect.
> 
> BUG=434115
> 
> Committed: https://crrev.com/c6a481fe79e0c4851a576495105edf2600bfe5be
> Cr-Commit-Position: refs/heads/master@{#312979}

TBR=danakj@chromium.org,achaulk@chromium.org
BUG=434115

[Daniel Kurtz, 2015-01-28 18:06:54]

Created Revert of compositor: Fix texture flipping for SW mirroring with
surfaceless

[commit-bot: I haz the power, 2015-01-28 18:07:35]

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

[commit-bot: I haz the power, 2015-01-28 18:07:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-28 18:07:36]

No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Daniel Kurtz, 2015-01-28 18:07:38]

djkurtz@chromium.org changed reviewers:
+ marcheu@chromium.org, oshima@chromium.org, waihong@chromium.org,
ykk@rock-chips.com

[oshima, 2015-01-28 18:20:26]

Can you remove

NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

? then lgtm.

It's still good idea to go through CQ given because this is 4 days old change,
and you want to avoid build breakage.

[Daniel Kurtz, 2015-01-28 18:21:36]

On 2015/01/28 18:20:26, oshima wrote:
> Can you remove
> 
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> 
> ? then lgtm.
> 
> It's still good idea to go through CQ given because this is 4 days old change,
> and you want to avoid build breakage.

done.

[Daniel Kurtz, 2015-01-28 18:21:59]

The CQ bit was checked by djkurtz@chromium.org

[commit-bot: I haz the power, 2015-01-28 18:22:59]

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

[commit-bot: I haz the power, 2015-01-28 18:29:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-28 18:29:28]

Try jobs failed on following builders:
  android_chromium_gn_compile_dbg on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)

[oshima, 2015-01-28 19:55:45]

The CQ bit was checked by oshima@chromium.org

[commit-bot: I haz the power, 2015-01-28 19:56:14]

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

[commit-bot: I haz the power, 2015-01-28 20:02:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-28 20:02:09]

Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)

[oshima, 2015-01-28 20:11:38]

On 2015/01/28 20:02:09, I haz the power (commit-bot) wrote:
> Try jobs failed on following builders:
>   android_chromium_gn_compile_rel on tryserver.chromium.linux
>
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)

Looks like you need to revert #313074 as well

[achaulk, 2015-01-28 20:21:47]

I am still seeing the crash even with this reverted

[achaulk, 2015-01-28 20:23:50]

Also, from what I can tell the crash only exists when you are logged in, if you
mirror from the login screen it works

[oshima, 2015-01-28 21:00:45]

On 2015/01/28 20:23:50, achaulk wrote:
> Also, from what I can tell the crash only exists when you are logged in, if
you
> mirror from the login screen it works

According to daniel, reverting fixed the bot issue. There is a chance that there
are multiple issues caused by multiple CL.
Let's revert this and see if bots really turns green. If you could repro the
crash even w/o the original change, could you
please file a bug with the stack?

I believe login or not login doesn't really matter. My impression is that this
is due to some kind of
race, so the condition may vary depending on the other factors. For example, I
couldn't repro this
crash using daisy_spring with the display I was using (both before/after login
and I confirmed that it's using SW mirroring).

[achaulk, 2015-01-28 21:07:54]

On 2015/01/28 21:00:45, oshima wrote:
> On 2015/01/28 20:23:50, achaulk wrote:
> > Also, from what I can tell the crash only exists when you are logged in, if
> you
> > mirror from the login screen it works
> 
> According to daniel, reverting fixed the bot issue. There is a chance that
there
> are multiple issues caused by multiple CL.
> Let's revert this and see if bots really turns green. If you could repro the
> crash even w/o the original change, could you
> please file a bug with the stack?
> 
> I believe login or not login doesn't really matter. My impression is that this
> is due to some kind of
> race, so the condition may vary depending on the other factors. For example, I
> couldn't repro this
> crash using daisy_spring with the display I was using (both before/after login
> and I confirmed that it's using SW mirroring).

I'm don't know, but I just built back at rev 312978, one before my CL and
mirroring crashed

[oshima, 2015-01-28 21:16:43]

On 2015/01/28 21:07:54, achaulk wrote:
> On 2015/01/28 21:00:45, oshima wrote:
> > On 2015/01/28 20:23:50, achaulk wrote:
> > > Also, from what I can tell the crash only exists when you are logged in,
if
> > you
> > > mirror from the login screen it works
> > 
> > According to daniel, reverting fixed the bot issue. There is a chance that
> there
> > are multiple issues caused by multiple CL.
> > Let's revert this and see if bots really turns green. If you could repro the
> > crash even w/o the original change, could you
> > please file a bug with the stack?
> > 
> > I believe login or not login doesn't really matter. My impression is that
this
> > is due to some kind of
> > race, so the condition may vary depending on the other factors. For example,
I
> > couldn't repro this
> > crash using daisy_spring with the display I was using (both before/after
login
> > and I confirmed that it's using SW mirroring).
> 
> I'm don't know, but I just built back at rev 312978, one before my CL and
> mirroring crashed

Can you bisect then? I combined two CLs, so it should be easy to  revert the
revert if you found the culprit.

[oshima, 2015-01-28 21:24:06]

On 2015/01/28 21:16:43, oshima wrote:
> On 2015/01/28 21:07:54, achaulk wrote:
> > On 2015/01/28 21:00:45, oshima wrote:
> > > On 2015/01/28 20:23:50, achaulk wrote:
> > > > Also, from what I can tell the crash only exists when you are logged in,
> if
> > > you
> > > > mirror from the login screen it works
> > > 
> > > According to daniel, reverting fixed the bot issue. There is a chance that
> > there
> > > are multiple issues caused by multiple CL.
> > > Let's revert this and see if bots really turns green. If you could repro
the
> > > crash even w/o the original change, could you
> > > please file a bug with the stack?
> > > 
> > > I believe login or not login doesn't really matter. My impression is that
> this
> > > is due to some kind of
> > > race, so the condition may vary depending on the other factors. For
example,
> I
> > > couldn't repro this
> > > crash using daisy_spring with the display I was using (both before/after
> login
> > > and I confirmed that it's using SW mirroring).
> > 
> > I'm don't know, but I just built back at rev 312978, one before my CL and
> > mirroring crashed
> 
> Can you bisect then? I combined two CLs, so it should be easy to  revert the
> revert if you found the culprit.

and let's continue the discussion on the bug

[oshima, 2015-01-30 19:00:56]

On 2015/01/28 21:24:06, oshima wrote:
> On 2015/01/28 21:16:43, oshima wrote:
> > On 2015/01/28 21:07:54, achaulk wrote:
> > > On 2015/01/28 21:00:45, oshima wrote:
> > > > On 2015/01/28 20:23:50, achaulk wrote:
> > > > > Also, from what I can tell the crash only exists when you are logged
in,
> > if
> > > > you
> > > > > mirror from the login screen it works
> > > > 
> > > > According to daniel, reverting fixed the bot issue. There is a chance
that
> > > there
> > > > are multiple issues caused by multiple CL.
> > > > Let's revert this and see if bots really turns green. If you could repro
> the
> > > > crash even w/o the original change, could you
> > > > please file a bug with the stack?
> > > > 
> > > > I believe login or not login doesn't really matter. My impression is
that
> > this
> > > > is due to some kind of
> > > > race, so the condition may vary depending on the other factors. For
> example,
> > I
> > > > couldn't repro this
> > > > crash using daisy_spring with the display I was using (both before/after
> > login
> > > > and I confirmed that it's using SW mirroring).
> > > 
> > > I'm don't know, but I just built back at rev 312978, one before my CL and
> > > mirroring crashed
> > 
> > Can you bisect then? I combined two CLs, so it should be easy to  revert the
> > revert if you found the culprit.
> 
> and let's continue the discussion on the bug

closing this.