spice-widget: Ignore duplicate configure events

gtk seems to be sending us identical / repeated configure events quite
regularly (atleast under X11), we don't care about re-configures with the
same size + coordinates, so filter these out.

Note this patch uses the SpiceDisplayPrivate mx and my members which
were already defined to store the window position, but not yet used.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
spice-widget: Fix auto-grab on window size change

Commit 8a7e72e3 "widget: regrab when widget is reconfigured" adds an
ungrab + grab call to the configure event handling code. But it does this
without checking if the mouse is grabbed at all, causing an unsolicited
grab in certain scenarios, ie:

1) User boots a vm
2) Connects with remote-viewer
3) Goes and do some web-browsing while the vm boots
4) Mouse happens to hover over the remote-viewer window
5) Guests changes resolution (ie X starts)
6) The mouse is grabbed, and when the user tries to move it to
   click something in his web-browser this does not work.

This patch fixes this by checking that the mouse is grabbed before doing
the ungrab + re-grab which is needed to reconfigure the grab to the new window
size / location.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
spice-widget: Reconfiguring the grab is only needed on win32

Commit 8a7e72e3 "widget: regrab when widget is reconfigured" adds an
ungrab + grab call to the configure event handling code. Because:
"On Windows, we need to update the cursor clip. Call ungrab&grab to update it."

But on X11 this is not needed, see man XGrabPointer, which explains that
the grab automatically adjusts to window resizing.

Not only is it not needed it is also racy, causing spice-gtk based
apps to log messages like:
(remote-viewer:9935): GSpice-WARNING **: pointer grab failed 3

This patch fixes this by disabling the ungrab + re-grab on non-win32.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Update current resolution when agent is started

This ensures we have the requested resolution whenever possible.
Notify of monitors when not using MonitorConfig

Windows guest don't use MonitorConfig, but we may want to notify the
client of the number of monitors.

Related to: https://bugzilla.redhat.com/show_bug.cgi?id=919530
controller: don't try to set integrity on XP x64 edition

XP x64 uses version 5.2, but doesn't accept setting the pipe to low
integrity.

5.2 seems to be shared with many versions (server 2003 for example),
but only Vista+ matters, which is only major >=6.

https://bugzilla.redhat.com/show_bug.cgi?id=918342
main: only notify on agent status change
main: warn if receiving message from disconnected agent
gtk-session: remove clipboard timeout

A large clipboard may take longer than 7s on slow networks. Since the
Gtk+ API forces us to use an inner main-loop, exit it asap, if agent
is disconnected for instance.

https://bugzilla.redhat.com/show_bug.cgi?id=752483
session: copy proxy setting

Solve migration falling back to switch-host method when using proxy
set through controller:

https://bugzilla.redhat.com/show_bug.cgi?id=923894
Be less verbose about monitor config
Keep GSocketConnection around after initial connect

There has been reports of recent spice-gtk versions not working on
RHEL6 or Ubuntu 10.04. This happens because these systems have
an older glib version without:

commit a0e1b226a21ca498b301981b0c89e89ad9a31eb1
Author: Dan Winship <danw@gnome.org>
Date:   Fri Apr 23 08:47:18 2010 -0400

    GSocketConnection: don't close the socket if it's still reffed

    When disposing a GSocketConnection, don't explicitly close the
    underlying GSocket. The GSocket will close itself if it gets
    destroyed, and if it doesn't get destroyed, that presumably means the
    app still wants to use it. Eg, this lets you use GSocketClient to
    create a GSocketConnection, and then take the GSocket and destroy the
    GSocketConnection.

    https://bugzilla.gnome.org/show_bug.cgi?id=616855

and spice-gtk commit 0f9a432c "session: allow to connect via HTTP CONNECT
proxy" changed spice_session_channel_open_host to get its socket by doing:

open_host->socket = g_socket_connection_get_socket(connection);
g_object_ref(open_host->socket);
g_object_unref(connection);
(see socket_client_connect_ready)

If glib does not have the commit mentioned above, then this won't
work as expected as open_host->socket will get closed when 'connection'
gets destroyed.

This commit changes spice_session_channel_open_host to return a
GSocketConnection rather than a GSocket so that we can keep the
socket open even on older glib versions.

Huge thanks go to Brad Campbell <brad@fnarfbargle.com> for doing all the
spice-gtk/glib bisecting work.
main: copy the right nth monitor config

i is our counter for c->display[]
channel-main: Don't send empty monitor config on main_init with agent

Currently we send a monitor-config on any agent_start, including sending it if
the agent is already started when the main channel connects, but when the main
channel gets initialized, the display channels aren't intialized yet, so our
monitor config will be empty. Resulting in the Linux agent logging:

spice-vdagent[1285]: err: client sent config with all monitors disabled

This patch fixing this by only sending our monitor-config to the agent when
it (re)starts later on.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Release pointer grab on grab-broken

On windows, the client receives a WM_KILLFOCUS event which generates
solely a keyboard grab-broken event.

This event is received when pressing ctrl-alt-del (to show up the task
manager), and we need to release the pointer grab and clip region in
this case for the client to be usable.

This also clear the clipping region when the client pops-up a dialog.

Since keyboard focus is a pre-requisite for pointer grab, it sounds
logical to release the pointer grab if losing keyboard focus, but for
now, we just release it in grab-broken, as a result of discussion on
the ML.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=857114
https://bugzilla.redhat.com/show_bug.cgi?id=922818
win32: do not handle win keys when the keyboard is not grabbed

Special-case on win32, filter out the win keys when not having the
keyboard grab. This is to avoid the win keys to be received both by
the guest and the client, which can be undesirable in general.

https://bugzilla.redhat.com/show_bug.cgi?id=873341
channel-playback/record: Refuse audio-vol-msgs with 0 channels

Older servers send these, explicitly warn about this, rather then triggering
the following error later:

(remote-viewer:8726): GSpice-WARNING **: set_sink_input_volume() failed: Invalid argument

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
win-usb-dev: make VID and PID available via get_property (Windows)
win-usb-dev: compare vid:pid instead of bus.addr (Windows)

It seems that sometimes, on Win7 clients, bus.addr is changing
when WinUSB driver is being installed (e.g. 4.1 -> 4.2).

So compare vid:pid instead.
usb-device-manager: constify spice_usb_device_get_ functions