I don't have any experience with this code, but I think it's chromeos/dbus/services/console_service_provider.* and chrome/browser/chromeos/dbus/chrome_console_service_provider_delegate.*. It looks like it goes through DisplayConfigurator, so there's a good chance that powerd's SetDisplayPower D-Bus method calls can be fixed at the same time.

hshi@ you know this code? Can you fix?

+dbehr@ -- this is a frecon issue.

It's not necessarily a frecon issue; Chrome has to participate in the negotiation and I suspect that the mashified Chrome doesn't do that. Basically what derat@ says in #2.

Yeah, I don't think that anything within org.chromium.LibCrosService* works in mash yet.

* crazy idea: rename it to org.chromium.Chromium while we're at it :-P

 Issue 644323  mentions ConsoleServiceProvider.

Chrome browser seems to hook this up here: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/chrome_browser_main_chromeos.cc?q=consoleserviceprovider&sq=package:chromium&dr=C&l=239

The implementation depends on ash::Shell::GetInstance()->display_configurator()

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/dbus/chrome_console_service_provider_delegate.cc?sq=package:chromium&dr=C&l=20

rjkroege, this sounds like something that needs to get fixed as part of mustash display refactoring. It doesn't seems like an issue with frecon itself, so I doubt it's something for dbehr@. I'm not sure which process DisplayConfigurator is going to live it, but it looks like that process needs to respond to a dbus signal.

I'm not sure who should own this.

Would be me or kyle so owner is right for now.

ChromeConsoleServiceProviderDelegate isn't running in the same process as DisplayConfiguration in mustash. We will need two new IPC messages from chrome -> mus-ws for TakeDisplayOwnership() and ReleaseDisplayOwnership() and a new implementation of ChromeConsoleServiceProviderDelegate that calls those IPCs. The response is already async so that shouldn't be a problem.

It looks like there is another bug where two Chrome instances are getting launched. This is interfering with dbus messages and so I can't try added IPCs for TakeDisplayOwnership() and ReleaseDisplayOwnership(). Once that is fixed I'll check if the IPCs work.

Alternately, mus-ws could learn to speak dbus. This would be more robust (e.g. VT2 switch would work even if chrome browser crashes). OTOH, it might involve splitting up the org.chromium.LibCrosService dbus service -- I have no idea if a dbus service can be provided by two processes (like the console switch by mus-ws and the other stuff by content_browser). Dan?

Another halfway solution might be for pieces of org.chromium.LibCrosService to live in the ash process.

Comment #10 seems OK if it's really simple to do, but long-term I think the dbus signal needs to be handled by mus-ws.

Indeed, the right long term fix is for mus to directly manage the console switch. I'd rather not have mus take a dependency on dbus but my objection is not particularly pragmatic.

In an ideal world, shouldn't LibCrosService be itself accessed via mojo?

#12: No, at least with the conventions that we've settled upon, a service is identified by a single name that can only be owned by one D-Bus connection.

org.chromium.LibCrosService is a poorly-named dumping ground, though, so there's probably no reason why it shouldn't be split into two or more reasonably-named services as part of this, which live in different processes for mus but all inside of the browser otherwise. That can be done incrementally without breaking non-mus Chrome OS.

#13: The consensus that I've seen is that using mojo instead of D-Bus for Chrome OS system services is out-of-scope until the mojo interface is stabilized. cmasone@ was working on it for a while, a while ago, but he left.

Is the plan for DisplayConfigurator to live inside of mash or in mus-ws? The D-Bus service that controls it should probably live in the same process.

DisplayConfigurator (and all the display management code really) will live in mus-ws.

I've sent out https://codereview.chromium.org/2648433006 which adds IPCs from chrome to mus-ws and frecon works. It seems like having a separate dbus connection in mus-ws for display related dbus messages as per #12 and #14 is correct solution in the end? I can file a bug for that.

 Issue 682807  has been merged into this issue.

Re #16 -- please file bug. But note that the high-level goal is that musws should do the right thing without needing a Chrome browser instance but a separate dbus connection may not necessarily be the only way.

Filled https://bugs.chromium.org/p/chromium/issues/detail?id=684725

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

commit a653f8962715401e37ae038f4946e85ab6433d6d
Author: kylechar <kylechar@chromium.org>
Date: Tue Jan 24 23:29:05 2017

Get frecon working with mustash.

This CL adds a mus specific ConsoleServiceProviderDelegate. It sends
IPCs to mus-ws to take and relinquish display control. This is
necessary because dbus and display management are not in the same
process anymore.

BUG= 682804 

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

[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/chrome/browser/chrome_content_browser_manifest_overlay.json
[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/chrome/browser/chromeos/BUILD.gn
[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/chrome/browser/chromeos/chrome_browser_main_chromeos.cc
[add] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/chrome/browser/chromeos/dbus/mus_console_service_provider_delegate.cc
[add] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/chrome/browser/chromeos/dbus/mus_console_service_provider_delegate.h
[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/services/ui/display/screen_manager_ozone.cc
[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/services/ui/display/screen_manager_ozone.h
[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/services/ui/manifest.json
[modify] https://crrev.com/a653f8962715401e37ae038f4946e85ab6433d6d/services/ui/public/interfaces/display/display_controller.mojom

 Issue 672970  has been merged into this issue.