[MST] ChromeOS UI + logic does not allow full control of monitor resolution + refresh rate + DPI scaling = monitor fails to enumerate |
||||||
Issue descriptionChrome Version : 67.0.3396.87 OS Version: 10575.55.0 URLs (if applicable) : b/109869461 Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari: N/A Firefox: N/A IE/Edge: N/A What steps will reproduce the problem? 1. Connect a MST dock (2-lane HBR2 = 10.4gbps) OR (4-lane HBR2 = 21.6gbps) 2. Connect high-res monitors (4kUHD VESA reduced blanking 4:4:4 8bpp = 16gbps@60, 7.88gbps@30) AND { Another 4k60 capable monitor (see above) OR 1920x1200@60 capable monitor (VESA reduced blanking 4:4:4 8bpp = 4.62gbps) } 3. Open ChromeOS Display setting menu What is the expected result? (1) ChromeOS intelligently manages and balances post-link-training DP1.2 HBR2 rate (2) Allows both monitors to operate at resolutions/frequencies that don't overload DP link bandwidth (4k60 [x2] = 16+16 = 32 >> 4-lane 21.6gbps limit) (4k30 + 1920@60 = 7.88+4.16 = 12.04 >> 2-lane 10.4gbps limit) (3) Allows independent manual selection of resolution + refresh to allow all other valid combinations, greying out options as necessary (4) Lowering the resolution manually reduces *enumerated* resolution, freeing up MST bandwidth (4.5) DPI scaling is manually selectable What happens instead of that? (1) ChromeOS enumerates solely based off of EDID of displays (2) Allows user to select invalid res+refresh combinations that result in one monitor or other not working ("black display") based on order of insertion/configuration (3) Settings are restricted from user choice (Release channel) or limited to highest refresh rate (Developer channel) (4) ChromeOS enumerates displays at highest resolution possible (4.5) then when lower resolutions are selected, does DPI scaling in softwar automatically. There is no user option to select DPI scaling manually. (5) Random entire hard-lockups of ChromeOS system because of overloading. Please provide any additional information below. Attach a screenshot if possible. * Logs of hard-lockup not possible due to needing 3-finger salute to restore. * Can provide remnant logs after reset (Alt+Shift+I) if requested UserAgentString: Mozilla/5.0 (X11; CrOS x86_64 10575.55.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
,
Jun 20 2018
,
Jun 22 2018
,
Jun 26 2018
Note: I chatted with afakhry@ and it's likely that we instead want to do something automatic, for example we could use the PATH property of the DP connector to tell us which connectors are sharing a link (see https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#standard-connector-properties). However that doesn't tell us the max bandwidth of the link, so Chrome would still have to do some guesswork. This probably needs more thinking...
,
Jun 28 2018
,
Sep 12
I'd like to follow up on this issue, with a breakdown of smaller sub-issues, and corrections from the above. (1) Modern ChromeOS builds now allow the user to separately select Resolution and/or DPI scaling. (2) The following backports resolve some link training issues with commercial MST hubs: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1151896/1 (3) There is a VC payload starting index issue that is being investigated. (4) Specific monitor blanking intervals and signal timings have been noted to play a major part in whether certain monitors will work or not. e.g. a "non-reduced blanking interval" 4k60 + 1920x1200@60 monitors will overload a 4-lane HBR2 MST dock (>21.6)... ... but a "VESA reduced blanking interval" 4k60 + 1920x1200@60 monitors will work just fine. For end users, this means two seemingly identical 4k60 monitors -- one may "work" and the other "not work" for no well defined reason. You need to use the "modetest" command in developer mode console as root to identify the H-Blank, V-Blank, and TDMSS data rates. https://www.extron.com/product/videotools.aspx
,
Dec 27
+ovanieva@ Pinging back on this to update status. We are getting more products in which require support for either (a) a manual UI dropdown or (b) better automatic UX logic. Stéphane has provided me a briefing on the basics of the kernel API + backend, and I would like to schedule a sync with Olga to discuss this given the pressing importance. "Made for Google" are targeting this feature for a pending release, so I am updating the bug status accordingly.
,
Dec 27
Additional instance of this issue jumping up and biting someone to cause a "P1": https://bugs.chromium.org/p/chromium/issues/detail?id=907643
,
Dec 27
Hopefully useful commands and references in the old entry which tracked the MST implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=329267#c51
,
Dec 28
,
Jan 10
I've broken out what I feel are the two biggest blockers (and narrowest fixes): crbug/920560 crbug/920543 Beyond that, it is a UI + algorithm discussion. I defer to the appropriate experts on that issue. Please let me know if I may assist. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by aaboagye@chromium.org
, Jun 20 2018Components: UI OS>Kernel>Display