gtk: Implement grab-on-click behavior in relative mode

This patch changes the behavior in the relative mode to be compatible
with other UIs, namely, grabbing the input at the first left click.
It improves the usability a lot; otherwise you have to press ctl-alt-G
or select from menu at each time you want to move the pointer.  Also,
the input grab is cleared when the current mode is switched to the
absolute mode.

The automatic reset of the implicit grabbing is needed since the
switching to the absolute mode happens always after the click even on
Gtk.  That is, we cannot check whether the absolute mode is already
available at the first click time even though it should have been
switched in X11 input driver side.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Merge remote-tracking branch 'remotes/kraxel/tags/pull-gtk-5' into staging

gtk: Implement grab-on-click behavior in relative mode

# gpg: Signature made Tue 08 Apr 2014 12:58:49 BST using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"

* remotes/kraxel/tags/pull-gtk-5:
  gtk: Implement grab-on-click behavior in relative mode

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
dsdt: tweak ACPI ID for hotplug resource device

ACPI0004 seems too new:
Windows XP complains about an unrecognized device.
This is a regression since 1.7.
Use PNP0A06 instead - Generic Container Device.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-By: Igor Mammedov <imammedo@redhat.com>
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

acpi bug fix

Here is a single last minute fix for 2.0

This changes the HID of the container used to claim
resources for CPU hotplug.
As a result, windows XP SP3 no longer brings up
an annoying "found new hardware" wizard on boot.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Tue 08 Apr 2014 13:23:30 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"

* remotes/mst/tags/for_upstream:
  dsdt: tweak ACPI ID for hotplug resource device

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/pci-host/prep: Don't reverse IO accesses on bigendian hosts

The raven_io_read() and raven_io_write() functions pass and
return values in little-endian format (since the IO op struct
is marked DEVICE_LITTLE_ENDIAN); however they were storing the
values in the buffer to pass to address_space_read/write()
in host-endian order, which meant that on big-endian hosts
the values were inadvertently reversed. Use the *_le_p()
accessors instead so that we are consistent regardless of
host endianness.

Strictly speaking the byte order of the buffer for
address_space_rw() is target byte order (which for PPC
will be BE) but it doesn't actually matter as long as we
are consistent about the marking on the IO op struct and
which stl_*_p().

This bug was probably introduced due to confusion caused by
the two different versions of ldl_p() and friends:
 bswap.h defines versions meaning "host endianness access"
 cpu-all.h defines versions meaning "target endianness access"
As a target-independent source file prep.c gets the bswap.h
versions; the very similar looking code in ioport.c is
compiled per-target and gets the cpu-all.h versions.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1396972271-22660-1-git-send-email-peter.maydell@linaro.org
Reviewed-by: Richard Henderson <rth@twiddle.net>
Update version for v2.0.0-rc2 release

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>