It's from Oct 2020, and widely available on various distro or backports.
Fix related meson warnings.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
by passing an open file descriptor in order to support the modern
Android USB device permissioning scheme.
During the process, a handle obtained by a call to
libusb_wrap_sys_device() is stored in the SpiceUsbDevice instance.
A call to libusb_open() is skipped if there is already a handle
present in the SpiceUsbDevice instance.
Finally, on Android, the option LIBUSB_OPTION_NO_DEVICE_DISCOVERY
must be set prior to the call to libusb_init() as per libusb
documentation.
Acked-by: Frediano Ziglio <freddy77@gmail.com>
Internally, spice-widget has separate try_keyboard_ungrab() and
try_mouse_ungrab() functions to ungrab the keyboard and mouse
respectively. Both of these functions are called when the grab
sequence is pressed.
spice-widget exposes try_mouse_ungrab() as spice_display_mouse_ungrab()
to allow callers to explicitly ungrab. However, it does not currently
expose try_keyboard_ungrab(), so callers can only ungrab the mouse and
cannot ungrab the keyboard.
Correct this by exposing try_keyboard_ungrab() as
spice_display_keyboard_ungrab().
Fixes#73
GStreamer is a hard requirement since ac0e50f or v0.36 wich is the
same release that PulseAudio backend was deprecated:
9a4b3bc "build-sys: deprecate the pulseaudio backend" in 2019-01-14
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The files are not in src so not included anyway.
Acked-by: Francesco Giudici <fgiudici@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Supported by Meson 0.49 (required by Spice-GTK).
New syntax is shorter and is recommended in
https://mesonbuild.com/Release-notes-for-0-49-0.html
("Joining paths with /").
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
spice_display_channel_change_preferred_video_codec_types: new function
for sending an array of video codecs instead of only one.
Signed-off-by: Kevin Pouget <kpouget@redhat.com>
Since gtk-doc 1.8, no need to maintain a types file!
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Maintaining 1 build system is hard. Maintaining 2 is even harder.
It seems the meson build system is now in good shape to replace
autotools. Like many desktop projects, let's move entirely to meson
and drop autotools support.
Known changes:
- generating changelog files in the dist tarball. This is not strictly
required, and can be added back later.
- generated files are not included in the dist tarball. In some ways,
this can be considered a good thing.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
- Fix the following warnings:
./spice-gtk-sections.txt:467: warning: No declaration found for SPICE_GTK_CHECK_VERSION.
./spice-gtk-sections.txt:468: warning: No declaration found for SPICE_GTK_MAJOR_VERSION.
./spice-gtk-sections.txt:469: warning: No declaration found for SPICE_GTK_MICRO_VERSION.
./spice-gtk-sections.txt:470: warning: No declaration found for SPICE_GTK_MINOR_VERSION.
- fixxref for glib and gtk (thus requires gtk+ to build doc)
- And other minor simplifications.
After autotools is removed, we should try to use --rebuild-types. For
now I prefer not to touch it :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Fix gtk-doc warnings such as:
html/SpiceChannel.html:538: warning: no link for: "api-index-0.20" -> (0.20).
Unfortunately, the generated file is still missing.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
../src/./spice-audio.h:22:2: warning: #warning "Only <spice-client.h> can be included directly" [-Wcpp]
#warning "Only <spice-client.h> can be included directly"
^~~~~~~
...
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Christophe Fergeau <cfergeau@redhat.com>
Add a few helper functions to deal with a QMP port channel, in order
to ease json handling, and wrapping a few commands.
(by convention, the port should have the name
"org.qemu.monitor.qmp.0", but it's not strictly required)
This helper is put into use in the virt-viewer "Add QEMU-like UI: VT
console & basic VM status" series.
Note: this adds a strong dependency on json-glib for
spice-client-glib, a widely available and fairly small
library.
QMP specification is:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/qmp-spec.txt
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
No need to use it when we can actually specify the parameters in the
actual gnome.generate_gir() function calls. We still keep it in the case
of gnome.gtkdoc(), as there is no way to specify the libraries to link
with.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In a comparison with current autotools build system, meson/ninja
provides a huge improvement in build speed, while keeping the same
functionalities currently available and being considered more user
friendly.
The new system coexists within the same repository with the current one,
so we can do more extensive testing of its functionality before deciding
if the old system can be removed, or for some reason, has to stay for
good.
- Meson: https://mesonbuild.com
This is the equivalent of autogen/configure step in autotools. It
generates the files that will be used by ninja to actually build the
source code.
The project has received lots of traction recently, with many GNOME
projects willing to move to this new build system. The following wiki
page has more details of the status of the many projects being ported:
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
Meson has a python-like syntax, easy to read, and the documentation
on the project is very complete, with a dedicated page on how to port
from autotools, explaining how most common use cases can be
implemented using meson.
http://mesonbuild.com/Porting-from-autotools.html
Other important sources of information:
http://mesonbuild.com/howtox.htmlhttp://mesonbuild.com/Syntax.htmlhttp://mesonbuild.com/Reference-manual.html
- Ninja: https://ninja-build.org
Ninja is the equivalent of make in an autotools setup, which actually
builds the source code. It has being used by large and complex
projects such as Google Chrome, Android and LLVM. There is not much to
say about ninja (other than it is much faster than make) because we
won't interact directly with it as much, as meson does the middle man
job here. The reasoning for creating ninja in the first place is
explained on the following post:
http://neugierig.org/software/chromium/notes/2011/02/ninja.html
Also its manual provides more in-depth information about the design
principles:
https://ninja-build.org/manual.html
- Basic workflow:
Meson package is available for most if not all distros, so, taking
Fedora as an example, we only need to run:
# dnf -y install meson ninja-build.
With Meson, building in-tree is not possible at all, so we need to
pass a directory as argument to meson where we want the build to be
done. This has the advantage of creating builds with different options
under the same parent directory, e.g.:
$ meson ./build --prefix=/usr
$ meson ./build-extra -Dextra-checks=true -Dalignment-checks=true
After configuration is done, we call ninja to actually do the build.
$ ninja -C ./build
$ ninja -C ./build install
Ninja defaults to parallel builds, and this can be changed with the -j
flag.
$ ninja -j 10 -C ./build
- Hacking:
* meson.build: Mandatory for the project root and usually found under
each directory you want something to be built.
* meson_options.txt: Options that can interfere with the result of the
build.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-6-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-5-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-4-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-3-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-2-git-send-email-mjay.francis@gmail.com>
That HTTP proxy code has been added to glib 2.43.92.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The spice-controller was a small library to let NPAPI browser plugins
communicate with the spice client. Due to usage of vala, the library
could not promise ABI stability, and was also considerer a pretty
poor implementation.
Furthermore, major browser vendors began to phase out NPAPI support in
2013, and some would like to see it gone by the end of this
year (realistically, it may not happen though).
As an alternative, remote-viewer (the first class Spice client)
learned to connect with a file of mime type application/x-virt-viewer,
as early as February 2013 with v0.5.5. I also proposed a DBus
controller, and a simpler way to pass connection details via stdin.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The generic G_DEPRECATED* macros got introduced in 2.32, and spice-gtk
depends on 2.36. We can drop our own.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It provides information about the remote cursor similar to the signal
"cursor-set". The benefit over the signal is that the property can be
queried at any time.
Users of the "cursor-set" signal should migrate to "notify::cursor".
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1411380
Acked-by: Victor Toso <victortoso@redhat.com>
* SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
This message was introduced in protocol 0.12.13 to establish client
side preference on video codec to be used in streams.
At this moment, we only introduce a new API [0] to select *the*
preferred video codec for client; In a later time, it should be
possible to use this message upon connection in order to to give
higher priority for video codecs with better performance and with
hardware decoding capabilities.
[0] spice_display_change_preferred_video_codec_type()
Note that host preference for encoding is expected to be considered
first then the client's preference.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
As we have UsbDk integration now which is well maintained upstream.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Fix gtk-doc warning by ignoring the new private header.
./spice-gtk-unused.txt:1: warning: 12 unused declarations.They should be
added to spice-gtk-sections.txt in the appropriate place.
While at it, fix grabsequence header incorrect file name.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Fix all the gtk-doc: "unused declarations. They should be added to
spice-gtk-sections.txt in the appropriate place."
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Send a SpiceMsgcMainMouseModeRequest message to request a mouse mode.
This allows to switch between client/absolute and server/relative mouse
modes.
This is necessary for some applications that require pointer
re-positioning, which we can't provide through a remote protocol easily
with client pointer (no such hardware-level message exists afaik).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
Add description, "Since" and change the parameter name in the docstring
to match parameter name in the function definition.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Not so many systems require gtk+ 2.0 these days, let's move on.
This drops the old python bindings (non-gir based), and the
unsteady/experimental gtk2-only XShm support.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Add spice-glib support for gl scanout messages.
A note about SpiceGlScanout: it is struct with scanout details,
registered as a boxed type, with associated gl-scanout property. That
way, it doesn't need a seperate signal for change notification and the
current scanout can be retrieve with gobject getter. Since boxed
property are always duplicated by g_object_get(), an additional
spice_display_get_gl_scanout() method returns the current scanout
without duplication (that's what spice-gtk display widget will use).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There were several shortcomings to the existing file transfer API,
particularly in terms of monitoring ongoing file transfers. The major
issue is that spice_main_file_copy_async() allows you to pass an array
of files, but the progress callback does not provide a way to
identify which file the callback is associated with. This makes it
nearly impossible for an application to monitor file transfers.
In addition, the SpiceDisplay widget automatically handles drag-and-drop
actions on the widget, and initiates file transfers without allowing the
application to specify a progress callback. So there's no way for an app
to monitor file transfers that are initiated via drag and drop.
http://lists.freedesktop.org/archives/spice-devel/2015-September/021931.html
has a more detailed explanation of the issues.
This change doesn't break the existing API, but adds some new API that
will allow an application to monitor file transfer progress, even for
transfers that are initiated within spice-gtk itself.
- A new public SpiceFileTransferTask object is added.
- The SpiceMainChannel object gains a "new-file-transfer" signal that is
emitted whenever a new file transfer is initiated. The
SpiceFileTransferTask object is passed to the signal handler.
- The application can retain this object and monitor its 'progress'
property to be notified when the progress of the file transfer
changes. The SpiceFileTransferTask::finished signal indicates when the
given file transfer has completed. The application can also cancel the
file transfer by calling the _cancel() method.
The 'spicy' test application has been updated to use this new API and
display a simple dialog showing the progress of individual files.
This is a new function that allows the caller to decide whether to send
the new status down to the server or not (analogous to the difference
between spice_main_set_display() vs spice_man_update_display()).
This new function is needed to reduce unnecessary MonitorsConfig
messages from being sent to the server. Because spice-gtk does not
maintain any display state internally, it depends on the application to
maintain that state. Some state changes come from the server itself
(e.g. the guest has changed resolution due to some activity within the
guest), and some come from the application (e.g. the user has resized
the window of the client). Changes that come from server updates do not
need to be sent back down to the server, whereas those that originate
from the application *do* need to be sent to the server.
This prevents a compile error on Debian Jessie, when building from git.
This is fairly subtle, and Debian specific. It only happens when you use
autoreconf to generate a new libtool script. Debian patches that script
to require an explicit setting to link with all dependent libraries.
It should be harmless on other distros, and it does save us Debian guys some
hassle.
