Moved issue monorail:2372 to now be issue chromium:698290.

/run/debugfs_gpu/i915_display_info can be used to determine what displays are physically connected to the Chromebook. I attached one with eDP on plus 3 DP MST (daisy-chained) physically connected external monitors but only the first 2 are displaying the desktop, while the 3rd is in power save mode, so not displaying anything (as expected) since the 3 pipes are already assigned.


The CRTC info section shows three pipes being used (A, B, C):

CRTC info
---------
CRTC 27: pipe: A, active=yes, (size=3200x1800), dither=yes, bpp=24
        fb: 69, pos: 0x0, size: 3200x1800
        encoder 36: type: TMDS-36, connectors:
                connector 37: type: eDP-1, status: connected, mode:
CRTC 31: pipe: B, active=yes, (size=3840x2160), dither=yes, bpp=24
        fb: 94, pos: 0x0, size: 3840x2160
        encoder 55: type: DP MST-55, connectors:
                connector 63: type: DP-3, status: connected, mode:
CRTC 35: pipe: C, active=yes, (size=2560x1440), dither=yes, bpp=24
        fb: 133, pos: 0x0, size: 2560x1440
        encoder 56: type: DP MST-56, connectors:
                connector 68: type: DP-5, status: connected, mode:

CRTCs, or pipes, represent the display pipelines while connectors are the actual DP sync or hub devices. Connector 37 is assigned to pipe A, connector 63 to pipe B and connector 68 to pipe C. The video streams are output from one physical port, DP-2 on the Chromebook. 

Deleted: i915_display_info 5.1 KB

i915_display_info 5.1 KB View Download

@2: You shouldn't use driver-specific APIs like /run/debugfs_gpu/i915_display_info to determine anything, since it is inherently non-portable. We have proper ways of doing this through the KMS API.

I suggested Nathan to add comment #2 for pure testing and demonstration purposes. It was not hinting at any kind of implementation.

For the record here's the final drm set call: https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?type=cs&q=setcrtc&l=449

Multi-monitor code seems to be spread in ws/ ozone/ display/

Ping: could be get this bug at least triaged? Enabling  issue 329267  seems nearly done.

DP MST is enabled in v3.18 by default last night(July 17).
I have tested this scenario after DP MST got enabled in v3.18 kernel (3.18.0-15819-gb0dc4581a5b2).

Issue is still reproduced on Chell. 

I wonder what happens if you close the lid, anyone tried that yet?

I tested this on a pixelbook running FSI firmware 9584.86 and a 10/3 R63 9998 OS image. I have 2 SST monitors connected into a Kensington dock which is plugged into the DUT via USB-C. When I plug an MST monitor into the other DUT USB-C port using a ding-dong, the HDMI monitor on the dock goes black. The new monitor lights up and the Display control panel correctly identifies the monitor. When I unplug the new monitor the HDMI monitor lights up. When I close the lid and go into dock mode, whatever monitors are lit up stay that way. The third external monitor does not light up in dock mode.

Thanks Russ for the recent reproduction. The key fact here is: a *random* monitor is turned off. Unlike Windows ChromeOS doesn't offer a choice.

Here's a different issue in the same area, can someone help labelling and triaging it?

issue 775757 with multiple (external) monitors, switching resolution reverts other monitor to default resolution

marcheu@ please help triage

This is a UI problem, to Albert for the UI side.

Thanks for triaging!

Reproducing this issue currently requires MST hardware which can itself be unreliable (and then mask this issue). Avoid current MST pitfalls listed here and there:
https://bugs.chromium.org/p/chromium/issues/detail?id=329267#c58
https://bugs.chromium.org/p/chromium/issues/detail?id=714236#c6

Almost the same topic: is there already a user interface to enter "Dock mode" without closing the lid = without losing the keyboard and trackpad? Some users want to use just (one) large external monitor *and* the built-in keyboard and trackpad at the same time. Gathering multiple people around a laptop screen doesn't really work.

This is *especially* useful for Android apps which seem all clueless and utterly confused as soon as there's more than one screen (and probably even more confused when the number of screens changes while the app is already running)

Copying this question here
https://bugs.chromium.org/p/chromium/issues/detail?id=329267#c66

Curious how bandwidth is allocated to multiple monitors sharing a single MST cable _and_ bottleneck? I mean first come first serve, "balanced", other?

Olga, I can't do much about it, this is a UI problem...

Olga did you ever connect 3 external monitors simultaneously? Then the problem becomes super obvious.

You need at least one MST hub, either standalone or embedded in a monitor that supports daisy chaining. 

Marc, we are exploring introducing UI element which will notify users of Max number of external displays supported. 

Thanks Olga for sharing this, appreciated.

comment #20
> Almost the same topic: is there already a user interface to enter "Dock mode" without closing the lid = without losing the keyboard and trackpad?

Just found by chance that this is implemented: just lower the brightness to zero! Tested with 66.0.3359.10 / 10452.1.0 but it could have been there for much longer. Only the lack of "dock mode" notification is misleading  Issue 816519 

I also tried a couple of Android apps (which prompted this question in the first place) and found that external monitors may be more usable in ARC++ now.


While testing I found an unrelated bug, it doesn't seem filed yet in https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EShell%3EMultipleMonitor so please let me know if I should create a new one:

  Cannot arrange monitors when external monitor is rotated 90 or 270 degrees (180 orientation works fine)

Dragging does nothing.

 Issue 828104  has been merged into this issue.

#26 - the dragging issue is not reproducible in R72