This was filed under Services>Chromoting, but it's not clear if you're expecting someone on Chromoting team to pick it up, and if so what we'd do to test this. Can you elaborate?

It's filed on chromoting as that seemed the best match. We would love someone on chromoting to pick it up. To test run chrome (on chromeos) with --mus (there is a flag to enable it). I suspect for this to work casting needs to work (miu@ is working on it, 754872).

We don't regularly build custom ChromeOS builds. Is it something we can test on a  Linux build machine (is ChromeOS-in-a-window still a thing?) If so then we can test it, but if it's more complex than that then it's probably going to be quicker for someone already familiar with mus to do it. The Chromoting knowledge needed is very small: just click Share in the app on ChromeOS, type the code in on another machine and make sure that you can see and control one computer from the other.

You can build a ChromeOS version of Chrome and run it on the desktop by adding target_os = "chromeos" to your args.gn (this is generally how developers run Chrome for ChromeOS).

I've tried setting this up and running with --login-manager (we need to be signed in to Chrome to test Chromoting) but I can't get it to log me in. Entering an email address and clicking NEXT does nothing (in fact, in this state only the Back button has any effect). I'm also getting a lot of crashes.

I think it's going to be a lot quicker for someone who regularly develops and builds for ChromeOS to test this. The Chromoting test steps are outlined in comment#3.

Jamie, thanks for trying. Where were the set of switches you passed to chrome and what was the crash you got?

My command-line was 
./out/Default/chrome --mus --user-data-dir=/tmp/lkghiosdiguh --login-manager

The main problem I was having was being unable to log in. As for the crashes, they were only with a debug build, I think, and I wasn't specifying --user-data-dir at the time, so it could easily be something profile related. I don't have the crash or a suitable build any more. I can recreate it if you think it's useful, but I don't think it has anything to do with this bug (it was an immediate crash on start-up).

The error message that seemed to be the root cause of the crash was something about a CHECK failed reading or parsing a policy value.

I just tested this. `chrome --mus --login-manager` was able to connect to a chromebook, send keyboard and mouse events, and receive a video stream.

At this point, remoting works well enough that anything broken is a specific bug.

Never mind, I didn't realize that this bug was about remoting in the other direction. Currently I'm getting spam of NOTIMPLEMENTEDs in aura::SystemInputInjectorMus.

This is actually to ensure removing works in both directions. Sounds like it works in one direction now.

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

commit ba5b7706fbac33a26c3ae1721777e5098b6be8ce
Author: Elliot Glaysher <erg@chromium.org>
Date: Fri Dec 15 23:27:57 2017

Make mus-chromeos work as a remoting destination.

mus-chromeos can work as a remoting accessor, but before this patch,
didn't process input events correctly. You can now chromote into a
mus-ash environment.

Bug:  769308 
Change-Id: I92ccd3d5e6cda9e873be59d711acdc83a2864772
Reviewed-on: https://chromium-review.googlesource.com/827940
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524516}
[modify] https://crrev.com/ba5b7706fbac33a26c3ae1721777e5098b6be8ce/services/ui/ws/remote_event_dispatcher.cc
[modify] https://crrev.com/ba5b7706fbac33a26c3ae1721777e5098b6be8ce/ui/aura/BUILD.gn
[modify] https://crrev.com/ba5b7706fbac33a26c3ae1721777e5098b6be8ce/ui/aura/mus/system_input_injector_mus.cc
[modify] https://crrev.com/ba5b7706fbac33a26c3ae1721777e5098b6be8ce/ui/aura/mus/system_input_injector_mus.h
[add] https://crrev.com/ba5b7706fbac33a26c3ae1721777e5098b6be8ce/ui/aura/mus/system_input_injector_mus_unittest.cc

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

commit 40e2862600f65877e9346795352d8655089c1b00
Author: Elliot Glaysher <erg@chromium.org>
Date: Fri Dec 15 23:53:39 2017

Address comments in the previous SystemInputInjectorMus patch.

I only saw these comments after the patch landed.

Bug:  769308 
Change-Id: Ia401bb2ec83a714e89a0cc16d8262a341f354e99
TBR: sky@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/831059
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524527}
[modify] https://crrev.com/40e2862600f65877e9346795352d8655089c1b00/ui/aura/mus/system_input_injector_mus_unittest.cc

Chromoting into a mus-ash instance now works enough that any problems should have specific bugs.