powerd emits BrightnessChanged D-Bus signals, which are received by chromeos::PowerManagerClient and forwarded to PowerManagerClient::Observer::BrightnessChanged.

I think that ash::TrayBrightness::BrightnessChanged -> HandleBrightnessChanged is the route that we take to display the bubble. At first glance, I'm not sure why that wouldn't be working in mash.

I was briefly thrown for a loop when I added some logging to TrayBrightness and didn't see it show up in /var/log/chrome/chrome, but it turns out that ash logging goes to /var/log/ui/ui.LATEST when running with --mash.

As far as I can tell, we're bailing out here in TrayBrightness::HandleBrightnessChanged:

  // Never show the bubble on systems that lack internal displays: if an
  // external display's brightness is changed, it may already display the new
  // level via an on-screen display. 
  if (!display::Display::HasInternalDisplay())
    return;

And then:

  // static
  bool Display::HasInternalDisplay() {
    return internal_display_id_ != kInvalidDisplayId;
  }

Kyle, do you know what's going on here? The popup is displayed in --mus but not --mash, which feels a bit surprising.

In mustash there are two different IPC interfaces for sending display::Screen/Display information to clients. The WM gets messages on the mojom::WindowManager interface which is a special case (to ensure synchronization with other WindowTree related messages). The mojom::WindowManager interface doesn't include the internal display (and some other things) because I never finished up that work.

We decided on a "simple display management" plan in mus where display::Screen/Display information originates from ash still. That is why it works there. 

I haven't talked with sky@ recently but I think we're going to use the same "simple display management" code with mustash now too.

The plan is to enable simplified display management for mash too. I filed 718860.

Simplified display management is now enabled for mash and the brightness keys now show the popup.