On Thu, Apr 9, 2015 at 11:40 PM, Jonathon Jongsma <jjongsma@xxxxxxxxxx> wrote:
When the server sends a new monitors config message to the client, it
comes through the display channel. However, when the client wants to
change the monitor config on the server, it does so via the main channel
(i.e. the agent). The main channel keeps a set of structs that represent
the current state each display. An application can update a single
display by calling spice_main_update_display(). The main channel will
update that particular struct and then schedule a new MonitorsConfig
message based on the values of all of these structs. This generally
works fine, but it relies on the application to remember to update each
display properly. It would be less error-prone if spice-gtk tracked
incoming display updates from the server rather than having spice-gtk
pass them up to the application and have the application pass them back
down.
That's simply because we shouldn't mix (unless it is somehow safe enough) what is the monitor config requested (main channel config), and what is the actual monitor config (display channels)
Note that when spice-gtk updates its internal state, it does not trigger
a new monitor configuration to be sent down to the server. If the
application wants to send down a new configuration, it still has to call
spice_main_update_display() as before. This change simply means that the
application won't need to call this function in response to
informational updates from the server.
It would change the user requested config if a display channel monitor config would reset it (on main channel) and the user would set/resize another monitor and send the last config for example.
nack
--
Marc-André Lureau
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel