weidongg@ please triage this

Could be due to the index fix by afakhry@

Yes, this is most likely due to the bug I fixed causing port indices to be miscalculated. See  issue 717371 .

Based on the system_logs.txt, I also think it is due to the fix of  issue 717371 .
In the stored display layouts, I found:

      "13761487533244416,8565007717795073": {
        "default_unified": true,
        "display_placement": [
          {
            "display_id": "13761487533244416",
            "offset": 1080,
            "parent_display_id": "8565007717795073",
            "position": "bottom"
          }
        ],
        "mirrored": false,
        "primary-id": "8565007717795073"
      },

This indicates that 8565007717795073 (external display) was the primary display and 13761487533244416 (internal display) was the secondary display. After update to M64, the external display id has been changed to 8565007717795074 (The connector index is calculated based on |connectors| instead of |available_connectors|, see #13 in  bug 717371 ). WindowTreeHostManager [1] cannot find the display id and hence by default use the internal display as primary display.

Currently connected displays are 13761487533244416 and 8565007717795074 based on the following log:
01-08 17:04:55.306    25    25 D wayland-service: Wayland Display ID 13761487533244416 maps to 0
01-08 17:04:55.306    25    25 D wayland-service: Wayland Display ID 8565007717795074 maps to 1

And current primary display is 13761487533244416 based on following log:
      "13761487533244416,8565007717795074": {
        "default_unified": true,
        "display_placement": [
          {
            "display_id": "8565007717795074",
            "offset": -1059,
            "parent_display_id": "13761487533244416",
            "position": "top"
          }
        ],
        "mirrored": false,
        "primary-id": "13761487533244416"
      },

In summary, I think this bug happens only for updating to M64 and will not happen for newer version.

[1] https://cs.chromium.org/chromium/src/ash/display/window_tree_host_manager.cc?gsn=GetCurrentDisplayIdList&l=593

Is this going to cause everyone with an external display set as primary to have that setting lost when 64 hits stable?  If so, that's a major problem.

+afakhry@ for comfirmation

I think the fix for  bug 717371  will not modify all external display ids. The id change seems to only happen when an available connector gets destructed (afakhry@, do you know when this happens?).

I'm mostly worried about potential impact on kiosks. I know there was a lot of pain for users when display IDs changed in the past and want to make sure we don't repeat that.

This was a memory corruption bug in the drm_util that had to be fixed. After the fix the IDs should be stable as long as the display remains connected to the same port. Before the fix, The connected display ID can change when another display gets connected or disconnected.

This issue is not likely to cause problems for kiosk devices for the following reasons:

- The IDs *might* change only if the device has number_of_connected_displays < total_number_of_ports.

Example:
  Device has 2 connected displays to USB-C ports and there are total 3 USB-C ports on the device. Depending on which ports the displays are connected to, the IDs might change.

- If the IDs change while the number of displays are the same before and after (which is going to be almost always the case), they would shift only. That means they will keep the same sort order. This is good because the default layout wouldn't change.

- Last time when the kiosk problem happened, it was because we changed the sort order, causing the unified desktop layout to change, and we used to have no way to change it at all in that mode. Right now, the sort order should remain the same, and we also support changing the layout of unified and non-unified modes using display APIs.


Re#5: 
Not everyone. It really depends on which port was connected, and the number of disconnected ports. Let's see this example:


                 actual port index:        0             1
                                    +--------------+-----------+
                                    | Disconnected | connected |
                                    +--------------+-----------+
reported port index before the fix:                      0

In the above case, after the update, the port index will be reported correctly, and hence the ID will shift. But if the case was the following before the update:

                 actual port index:       0             1
                                    +-----------+--------------+
                                    | connected | Disconnected |
                                    +-----------+--------------+
reported port index before the fix:       0

After the update nothing will change.

Bottom line is, if the connected ports were not consecutive, their port indices were wrong, and after the update, they will shift, but they will retain their relative sort order.

Ok. I'm still nervous about this, but this sounds like a wontfix.

+kbleicher & +trumbull for heads up.  Let's keep an eye out for complaints about display layout being lost as 64 rolls out.

#CBC-RS/TC-watchlist

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.