With a QEMU setting of
 -vga none \ 
 -device qxl,id=video0,ram_size=67108864,bus=pci.0,addr=0x02\
 -device qxl,id=video1,ram_size=67108864,bus=pci.0,addr=0x0a 

spice-view is a non-ui spice viewer I am customizing from virtual-viewer.

The expected order and assignment is:
** (spice-view:2084): WARNING **: New display: channel [ 0 ] monitorid [0]
** (spice-view:2084): WARNING **: New display: channel [ 0 ] monitorid [1]
** (spice-view:2084): WARNING **: New display: channel [ 0 ] monitorid [2]
** (spice-view:2084): WARNING **: New display: channel [ 0 ] monitorid [3]
** (spice-view:2084): WARNING **: New display: channel [ 1 ] monitorid [0]
** (spice-view:2084): WARNING **: New display: channel [ 1 ] monitorid [1]
** (spice-view:2084): WARNING **: New display: channel [ 1 ] monitorid [2]
** (spice-view:2084): WARNING **: New display: channel [ 1 ] monitorid [3]

All the high order of displays [1,2,3] fail in in the gtk lib, viewer or both.

The order of displays, restarting the viewer, 
  ** (spice-view:1830): WARNING **: New display: channel [ 0 ] monitorid [1]
  ** (spice-view:1830): WARNING **: New display: channel [ 1 ] monitorid [0]
restart
  ** (spice-view:1830): WARNING **: New display: channel [ 0 ] monitorid [1]
  ** (spice-view:1830): WARNING **: New display: channel [ 1 ] monitorid [0]
restart
  ** (spice-view:1830): WARNING **: New display: channel [ 0 ] monitorid [1]
  ** (spice-view:1830): WARNING **: New display: channel [ 1 ] monitorid [0]
....

The order of display assignments are inverted like this:
  ** (spice-view:1830): WARNING **: New display: channel [ 1 ] monitorid [0]
  ** (spice-view:1830): WARNING **: New display: channel [ 0 ] monitorid [0]
or back again.

It results in wrong assignment in order of assignment of displays. On two displays in full scree or kiosk, this results in a swap of expected results if [0,0] / qxl card0 is always expected to be primary display, and [1,0] secondary display (hidden if unavailable) at qxl card1.

This also causes inversion in a windowed mode where it is not predictable which display will be on top, an annoyance, but not a "failure" like fullscreen or Kiosk.


Looking through the code I see the check in both the spice-wigdet.c "static gint get_display_id(SpiceDisplay *display)" and  virt-viewer "virt_viewer_display_spice_new". That both use a check like this (respectivly):

    /* supported monitor_id only with display channel #0 */
    if (d->channel_id == 0 && d->monitor_id >= 0)
        return d->monitor_id;
and

    // We don't allow monitorid != 0 && channelid != 0
    g_return_val_if_fail(channelid != 0 ||  monitorid != 0, NULL);

This made me wonder how the second display [1,0] is recognized by the widget, the viewer does not seem to care.

I cannot tell how to force location or priority of an expected channel's display to the proper window and prevent the inversion.  

 Where should I look to solve the inversion?