Logs (repro after powerwash and before first user login) are at
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/658280/

hterm is for the javascript based terminal used by SecureShell, not for native terminals like frecon/VT2

marcheu@ - could this be related to crbug.com/654551 ?

No, this is a separate issue.

Is there anything running while you switch to VT2 or can you repro it from CrOS login screen?

We had seen something like this before, and it was Chrome flipping on top of frecon screen because at the time frecon would give up DRM master too easily. Now that frecon holds DRM master while it is active, Chrome should not be able to flip like this.

Nothing special running. No user login needed. Best reproduced on first time login screen. Guest mode too.

It looks like in certain situations (for instance switch to VT2, and quickly switch to Chrome and back to VT2) Chrome somehow does not drop master.

[   47.961522] frecon(210): Switching to background.
[   47.961572] DDD called dropmaster pid 210 210 // frecon process 210 dropped master
[   47.962451] DDD called setmaster drm_master_relax is: 1 sysadmin: 0 pid 862 644 // Chrome process set master
[   48.025296] frecon(210): Switching to foreground. // frecon becoming active, it sent dbus signal here to Chrome to drop master
// here Chrome should be dropping master but it is not.
[   48.026199] DDD called setmaster drm_master_relax is: 1 sysadmin: 1 pid 210 210 // frecon sets master (stealing it from Chrome because Chrome did not drop it. stuff goes to hell from here).
[   48.112916] DDD failed func 108 retcode -62
[   48.171850] DDD failed func 12 retcode -22
[   48.173549] DDD failed func 177 retcode -38

Further attempts of Chrome to drop master fail because of messed up kernel state (no minor->master)
[  121.185376] frecon(210): Switching to background.
[  121.185422] DDD called dropmaster pid 210 210
[  121.501595] DDD failed func 108 retcode -62
[  121.712545] frecon(210): Switching to foreground.
[  121.713609] DDD called dropmaster pid 862 644
[  121.713632] DDD failed to drop master because there is no minor->master
[  121.713655] DDD failed func 31 retcode -22
[  121.714485] DDD called setmaster drm_master_relax is: 1 sysadmin: 1 pid 210 210

I think we may be hitting some kind of race, in display_configurator.cc
After Chrome regains display ownership, it runs display reconfiguration and I think at that time it may ignore calls to release display ownership. It should be noticed by frecon though, so maybe Chrome does not send proper "false" result on dbus?

Also, if DropMaster ioctl fails in Chrome it isn't propagated back to dbus result.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/frecon/+/a818a1e57c6ed3d28aa7affd07ad102f170b0d7d

commit a818a1e57c6ed3d28aa7affd07ad102f170b0d7d
Author: Dominik Behr <dbehr@chromium.org>
Date: Thu Oct 27 02:46:22 2016

frecon: read result of Chrome DBUS calls and act on them.

When Chrome takes ownership of display, it runs display reconfiguration.
During that time it will ignore and fail calls to release ownership of display.
Frecon did not read result of DBUS function calls and assumed they succeeded
when they did not. This change fixes that and makes frecon retry the calls if
they fail.

BUG= chromium:658280 
TEST=switch to VT2 then switch back to Chrome and quickly back to VT2.

Change-Id: I3335ed3dcea260a6da69675b713e4546c6e4d4d0
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403615
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

[modify] https://crrev.com/a818a1e57c6ed3d28aa7affd07ad102f170b0d7d/dbus.c
[modify] https://crrev.com/a818a1e57c6ed3d28aa7affd07ad102f170b0d7d/dbus.h
[modify] https://crrev.com/a818a1e57c6ed3d28aa7affd07ad102f170b0d7d/main.c
[modify] https://crrev.com/a818a1e57c6ed3d28aa7affd07ad102f170b0d7d/term.c

Verified on build 8980.0.0

Moving old issues out of Internal>Graphics to delete this obsolete component ( crbug.com/685425  for details)