Hi ----- Mensaje original ----- > > This avoid some configuration races when connecting to a multi-channel > > display server which is slow to set up. > > Would you mind describing the symptoms of that race?
When starting a spice-gtk client with multiple display channel, some display readiness could be delayed due to network etc. In the meantime, the display that are ready could already have there configuration updated via spice_main_set_display_enabled(). If after 1s, the new configuration doesn't have the same set of monitors enabled, the guest will receive new configuration with less monitors, and disable them. The resulting client might end up with black/disabled or disapearring displays (depending on implementation) right after connecting. Mostly for legacy reason, spice-gtk automatically delays sending the latest monitor configuration by 1s (this was originally to filter client implementation that may set configuration multiple times in a row when for ex, resizing windows, but also during initialization time) However, 1s isn't enough to wait for all the display to be ready, so instead this automatic sending is delayed until at least n (== number of display channels) monitors are set. Note this check only applies to auto-sending, clients are able to send the configuration directly via spice_main_send_monitor_config(). > I'm puzzled by a nasty glitch, and it has monitor config issues > as a symptom. So of course, you have a hammer - and I'm wondering > if it matches my nail? > <grin> > > Cheers, > > Jeremy > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
