Virtual keyboard should kick in in this case.

Why is this marked Restrict-View-Google?

I succeeded to repro this bug and confirmed that I can enroll the device when only one touchable display is connected (no non-touchable display). I think  crbug.com/589989  is related.

cederberg@: Could you check that the enrollment works when only one mimo is connected?

Yes, I can confirm this case works.

As I wrote when filing the bug, I did not expect the other scenario to work, and in fact I am not even sure what it would mean to enroll using the Mimo as a keyboard. This seems more like a product decision than an eng decision to me.

Maybe bkemler@ and/or mnilsson@ can weigh in here?

Does it make sense to just detect a situation where we have one regular display and one touch screen during OOBE and automatically popup the the VK on the touchscreen?

I think that would work.

In this case, the touch screen isn't associated with any display, so IIUC any touching doesn't emit a touch event on displays. Hence, even if the VK shows up on the touch display, we cannot use it.

Note: I used a LG touch display (http://www.lg.com/us/monitors/lg-23ET83V-W-led-monitor) for testing. The display has 1080p resolution for the display, but it has 4096x4096 resolution for touch.

MIMO is a bit different than the LG display you tested with.  Since both the display and touch interface go over the same USB connection we have a heuristic to automatically associate the screen and touch surface.

Ah, I see.

 https://crbug.com/303429  is a similar issue and the fix (https://crrev.com/2445293002) is already landed. If touch surface is associated with the screen, VK automatically should show up on the touchscreen.

I'm worried about the case of:
1: User connects a normal display.
2: User connects a MIMO
3: User goes through OOBE

If the OOBE UI shows on the normal display it would make sense to bring up the VK on the MIMO

Can't we, at least for the duration of the Chromeos OOBE, select the MIMO as the primary screen? And use it for the remainder of the OOBE. Maybe only when some other criteria is met, such as no mouse is connected. At the end of OOBE, restore the primary screen back to what it was.

Rationale: There are other things that the user needs to do besides typing on a virtual keyboard: Tap on buttons, select items in dropdown lists, etc. None of that will work if just the keyboard moves but the UI remains on the non-touch screen.

That actually sounds easier.

jdufault@ any thoughts on comment #12?

#12 sounds reasonable to me as well - though I think all of the UI should be accessible via the keyboard arrow keys + enter.

I wonder if we can figure out a way to make the VK work better in this case as well (ie, only popup VK on touch display if there is no keyboard + mouse attached).

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

commit bcbc0c40b5987b07425a9bad2f9dadfeb4612182
Author: felixe <felixe@chromium.org>
Date: Thu May 11 10:53:50 2017

Put OOBE UI on touch display if no keyboard detected

This will enable devices without a keyboard but with a touch display to go
through the OOBE setup.

BUG= 668449 

Review-Url: https://codereview.chromium.org/2865003003
Cr-Commit-Position: refs/heads/master@{#470912}

[modify] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/chromeos/BUILD.gn
[modify] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/chromeos/login/ui/login_display_host_impl.cc
[modify] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/ui/BUILD.gn
[add] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser.cc
[add] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser.h
[add] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser_unittest.cc
[modify] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/ui/webui/chromeos/login/oobe_ui.cc
[modify] https://crrev.com/bcbc0c40b5987b07425a9bad2f9dadfeb4612182/chrome/browser/ui/webui/chromeos/login/oobe_ui.h

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

commit 491c6b2fc5e9d5fd2b7eada34026ff977797b493
Author: felixe <felixe@chromium.org>
Date: Wed May 24 07:27:22 2017

Avoid changing primary display in DisplayObserver call

BUG= 668449 ,722564

Review-Url: https://codereview.chromium.org/2885153004
Cr-Commit-Position: refs/heads/master@{#474196}

[modify] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/browser/chromeos/login/ui/login_display_host_impl.cc
[modify] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/browser/chromeos/login/ui/login_display_host_impl.h
[modify] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser.cc
[modify] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser.h
[add] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser_browsertest.cc
[modify] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/browser/ui/webui/chromeos/login/oobe_display_chooser_unittest.cc
[modify] https://crrev.com/491c6b2fc5e9d5fd2b7eada34026ff977797b493/chrome/test/BUILD.gn