From: Marc-André Lureau
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
---
doc/reference/spice-gtk-docs.xml | 102 +--
From: Marc-André Lureau
Since gtk-doc 1.8, no need to maintain a types file!
Signed-off-by: Marc-André Lureau
---
doc/reference/meson.build | 2 +-
doc/reference/spice-gtk.types | 49 ---
2 files changed, 1 insertion(+), 50 deletions(-)
delete mode 100644
From: Marc-André Lureau
Our own handling was limited, since it checked only spice-common.
This is handled by meson since v0.40 for subprojects.
Signed-off-by: Marc-André Lureau
---
build-aux/meson/check-spice-common | 5 -
meson.build| 3 ---
2 files changed, 8
From: Marc-André Lureau
Follow meson build system conventions.
This will allow meson to handle it as a subproject.
Signed-off-by: Marc-André Lureau
---
.gitmodules | 4 ++--
meson.build | 6 +-
src/meson.build | 2 --
{src =>
From: Marc-André Lureau
Daniel P. Berrange (24):
Add named constants for QKeyCode values
Add ability to generate enums
Build tests with warnings enabled
Add Sun/Sparc keyboard keycodes
Add some missing mappings for USB HID
Add line for QKeyCode asterisk
From: Marc-André Lureau
Escape special characters with \, fixes:
html/SpiceUsbDeviceManager.html:741: warning: no link for: "1" -> (1).
html/SpiceUsbDeviceManager.html:742: warning: no link for: "2" -> (2).
html/SpiceUsbDeviceManager.html:743: warning: no link for: "3" -> (3).
From: Marc-André Lureau
Use the trick recommended here to generate a vcs_tag.h at build-time:
https://github.com/mesonbuild/meson/issues/3903
Hopefully, meson will learn to generate project version from git:
https://github.com/mesonbuild/meson/issues/688
Signed-off-by: Marc-André Lureau
---
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
src/channel-display.c | 2 +-
src/channel-main.h| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/channel-display.c b/src/channel-display.c
index ae949eb..fd072a9 100644
--- a/src/channel-display.c
+++
From: Marc-André Lureau
- 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
From: Marc-André Lureau
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:
- no git version: a following
From: Marc-André Lureau
meson doesn't handle git-version-gen correctly yet (see
meson#688). Let's set the version manually for now.
And a tag version vX.X will also fail to build, version_info[2]
is out of array bounds.
Signed-off-by: Marc-André Lureau
---
meson.build | 2 +-
From: Marc-André Lureau
Hi,
Meson build system seems complete enough to drop autotools upstream!
Various other improvements to meson, gtk-doc, etc...
(the first 2 patches were already sent for review on the ML, but are
included here for completeness and have received minor fixes)
Thanks
From: Marc-André Lureau
Use glib preset (from meson v0.37) to catch all our translatable
strings and use good default settings.
While at it, remove the needless directory argument.
Signed-off-by: Marc-André Lureau
---
po/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Add a function to look up an xrandr output for a given device display
id. This uses sysfs and the drm subsystem to lookup information about a
graphics device output. It then compares the drm output name to xrandr
output names to try to match that device output to an xrandr output.
This is necesary
Rather than getting the current guest resolution in a
VDAgentMonitorsConfig struct and then translating it to a new struct
type for sending down to the daemon, simply use the new function that
was factored out in a previous commit and populate the message struct
directly.
---
There are basically three ways to refer to an output within vdagent:
- The index of the array of MonitorConfig message. This is essentially
a "spice display id"
- the index of the array of xrandr outputs. This is the "output index"
- the xrandr output id. This is the "output ID"
When sending the guest xorg resolution to the vdagentd daemon, we get
the current resolution with this function, which returns a
VDAgentMonitorsConfig structure that must then be converted to the
structure that we send to the daemon. Rather than re-using this function
that returns the wrong type,
Add a display_id field to the structure that we use to send down the
list of guest display resolutions to the vdagentd daemon. This allows us
to map the spice display id to the proper X display for determining
mouse locations, etc.
---
src/vdagent/x11-randr.c | 35
When the agent gets a new device info message (from the daemon), we need
to re-calculate the guest output map and send that information back down
to the daemon so that it can handle mouse input events correctly.
---
src/vdagent/x11-randr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
This is a patch set that handles the PCI address and device dispay ID
sent down to the agent by the server, and uses that to maintain a map
for looking up a particular xrandr output for a given spice display id.
This patch series builds on the patch from Lukas titled "Receive the
Instead of storing each device address and device display ID in the hash
table, simply use the lookup_xrandr_output_for_device_info() function to
look up the ID of the xrandr output and store that in the hash table.
---
src/vdagent/x11-priv.h | 2 +-
src/vdagent/x11-randr.c | 53
instead of using the spice display id directly as the xrandr output,
look it up using our new guest output map
---
src/vdagent/x11-randr.c | 78 -
1 file changed, 69 insertions(+), 9 deletions(-)
diff --git a/src/vdagent/x11-randr.c
In the case where we have an mjpeg plugin running in the streaming
agent, we have two spice displays representing the same guest display.
In that scenario, the session agent may maintain the following guest
output mapping:
spice channel 0 (QXL) => X output 0
spice channel 1 (streaming-agent) =>
Acked-by: Jonathon Jongsma
On Wed, 2019-01-16 at 13:52 +0100, Lukáš Hrázký wrote:
> The graphics_device_info message contains the device display ID
> information (device address and device display ID). Stores the data
> in a
> hash table in vdagent.
>
> Signed-off-by: Lukáš Hrázký
> ---
>
A couple minor comments below.
On Wed, 2019-01-16 at 13:52 +0100, Lukáš Hrázký wrote:
> Adds an interface method to the FrameCapture class to get the device
> display info (device address and device display id) for each display
> of
> the graphics device that is captured.
>
> Also adds functions
On Wed, 2019-01-16 at 13:52 +0100, Lukáš Hrázký wrote:
> Adds the graphics device info from the streaming device(s) to the
> VDAgentGraphicsDeviceInfo message sent to the vd_agent.
>
> Signed-off-by: Lukáš Hrázký
> ---
> server/red-stream-device.c | 18 +++
> server/red-stream-device.h
re-sending on the correct patch series.
Acked-by: Jonathon Jongsma
On Wed, 2019-01-16 at 13:52 +0100, Lukáš Hrázký wrote:
> Sends the device address and device display IDs to the vdagent. The
> message is sent either in reaction to the SPICE_MSGC_MAIN_AGENT_START
> message or when the graphics
Accidentally sent this on the v2 series, but I'll repeat it here:
Commit subject mentions the wrong type name?
StreamMsgGraphicsDeviceInfo != StreamMsgDeviceDisplayInfo
On Wed, 2019-01-16 at 13:52 +0100, Lukáš Hrázký wrote:
> The message contains information about the graphics device and
>
Commit subject mentions the wrong type name?
StreamMsgGraphicsDeviceInfo != StreamMsgDeviceDisplayInfo
On Mon, 2019-01-14 at 17:38 +0100, Lukáš Hrázký wrote:
> The message contains information about the graphics device and
> monitor
> belonging to a particular video stream (which maps to a
On Thu, Jan 17, 2019 at 6:20 PM Frediano Ziglio wrote:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1661147
> > If display miniport driver does not pass valid display info to
> > the basic display driver on disable/uninstall, the basic
> > display driver raises run-time error and stays
Acked-by: Jonathon Jongmsa
On Mon, 2019-01-14 at 17:38 +0100, Lukáš Hrázký wrote:
> Sends the device address and device display IDs to the vdagent. The
> message is sent either in reaction to the SPICE_MSGC_MAIN_AGENT_START
> message or when the graphics device info changes.
>
> Signed-off-by:
On Wed, 2019-01-16 at 13:34 +0100, Lukáš Hrázký wrote:
> > > +StreamMsgDeviceDisplayInfo *display_info_msg =
> > > >msg->device_display_info;
> > > +
> > > +size_t device_address_len =
> > > GUINT32_FROM_LE(display_info_msg->device_address_len);
> > > +if (device_address_len >
On Mon, Jan 14, 2019 at 04:17:49PM +, Frediano Ziglio wrote:
> The SpiceStat structure can be 20 or 24 bytes depending on alignment.
> Being a memory mapped structure potentially used with lockless access,
> it is not good to have it unaligned.
> The only tool that we know of that reads this
Acked-by: Christophe Fergeau
On Wed, Jan 02, 2019 at 11:21:00AM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/inputs-channel.c | 8
> server/reds.c | 36 +++-
> server/reds.h | 2 +-
> 3 files
Acked-by: Jonathon Jongsma
On Wed, 2019-01-02 at 11:21 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/inputs-channel.c | 8
> server/reds.c | 36 +++-
> server/reds.h | 2 +-
> 3 files changed, 24
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1661147
> If display miniport driver does not pass valid display info to
> the basic display driver on disable/uninstall, the basic
> display driver raises run-time error and stays with yellow
> bang. This behavior is specific to UEFI machines.
>
Hey, not overly familiar with the windows code, but looks reasonable
Reviewed-by: Christophe Fergeau
On Thu, Jan 17, 2019 at 11:08:48AM +0200, Yuri Benditovich wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1661147
> If display miniport driver does not pass valid display info to
> the
Hi,
On 1/17/19 2:27 PM, Frediano Ziglio wrote:
Currently we set timestamps as buffer's PTS, this value may be changed by
the pipeline in some cases and cause an unexpected buffer warnings (when
GstVideoOverlay is not used). Use GstReferenceTimestampMeta when
synchronization is made by spice.
Frediano Ziglio on Thu, 2019/01/17 07:41:
>
> > Commit 098268a33c7c8008ccec9050aea8f0763f1c06d5 (systemd: Update path
> > in unit file) was a really incomplete change. Let's change every
> > occurrence of /var/run to /run.
> >
> > Signed-off-by: Christian Hesse
>
> Acked-by: Frediano Ziglio
Hey,
On Thu, Jan 17, 2019 at 12:06:29PM +0100, Ibrahim Hernández jorge wrote:
> Hi,
>
> I would be very interested in using your protocol for my final master
> project.
> I would like to use the protocol, mainly due to the need to use audio, for
> the remote use of a physical machine. But all
> Commit 098268a33c7c8008ccec9050aea8f0763f1c06d5 (systemd: Update path
> in unit file) was a really incomplete change. Let's change every
> occurrence of /var/run to /run.
>
> Signed-off-by: Christian Hesse
Acked-by: Frediano Ziglio
> ---
> README | 2 +-
>
Hi,
I would be very interested in using your protocol for my final master
project.
I would like to use the protocol, mainly due to the need to use audio, for
the remote use of a physical machine. But all the documentation I find is
about virtual machines.
Is it currently possible to use SPICE for
>
> Currently we set timestamps as buffer's PTS, this value may be changed by
> the pipeline in some cases and cause an unexpected buffer warnings (when
> GstVideoOverlay is not used). Use GstReferenceTimestampMeta when
> synchronization is made by spice.
>
> Before applying this patch you can
> Hi,
>
>
> I'm picking up the Virgl remote support patchset with the goal of
> adapting it for use with Xspice.
>
> If I'm not mistaken the latest version of this patchset is in the
> virgl-spice branches of the following repositories:
>
>
Hi!
The Spice team is pleased to release a new spice-gtk version 0.36,
with the following highlights:
- Add meson build: autotools will be removed in a future release
- Deprecate PulseAudio backend: it will be removed in a future
release, please use GStreamer instead and report issues
- Add
>
> From: Marc-André Lureau
>
> Get the fix for meson build and big endian machines, like s390x.
>
> Frediano Ziglio (4):
> marshaller: Provide spice_marshaller_fill_iovec for Windows
> test: Add a test for subject_to_x509_name function
> lz: Avoid buffer reading overflow
From: Marc-André Lureau
Get the fix for meson build and big endian machines, like s390x.
Frediano Ziglio (4):
marshaller: Provide spice_marshaller_fill_iovec for Windows
test: Add a test for subject_to_x509_name function
lz: Avoid buffer reading overflow checking for image
Hi
On Thu, Jan 17, 2019 at 1:11 PM Frediano Ziglio wrote:
>
> >
> > Hi
> >
> > On Thu, Jan 17, 2019 at 1:03 PM Frediano Ziglio wrote:
> > >
> > > >
> > > > From: Marc-André Lureau
> > > >
> > >
> > > Maybe a comment saying that we want the merge to get the fix
> > > for Meson and big endian
>
> Hi
>
> On Thu, Jan 17, 2019 at 1:03 PM Frediano Ziglio wrote:
> >
> > >
> > > From: Marc-André Lureau
> > >
> >
> > Maybe a comment saying that we want the merge to get the fix
> > for Meson and big endian machines like s390x ?
> >
> > > $ git diff --submodule=log
> > > Submodule
https://bugzilla.redhat.com/show_bug.cgi?id=1661147
If display miniport driver does not pass valid display info to
the basic display driver on disable/uninstall, the basic
display driver raises run-time error and stays with yellow
bang. This behavior is specific to UEFI machines.
Reference:
Hi
On Thu, Jan 17, 2019 at 1:03 PM Frediano Ziglio wrote:
>
> >
> > From: Marc-André Lureau
> >
>
> Maybe a comment saying that we want the merge to get the fix
> for Meson and big endian machines like s390x ?
Sure I can point this out for the main reason.
>
> > $ git diff --submodule=log
> >
Hi
On Thu, Jan 17, 2019 at 1:03 PM Frediano Ziglio wrote:
>
> >
> > From: Marc-André Lureau
> >
>
> Maybe a comment saying that we want the merge to get the fix
> for Meson and big endian machines like s390x ?
>
> > $ git diff --submodule=log
> > Submodule subprojects/spice-common
>
> From: Marc-André Lureau
>
Maybe a comment saying that we want the merge to get the fix
for Meson and big endian machines like s390x ?
> $ git diff --submodule=log
> Submodule subprojects/spice-common 924f47a..0a753b9:
> > meson: fix building for big-endian host
> > quic: fix
From: Marc-André Lureau
$ git diff --submodule=log
Submodule subprojects/spice-common 924f47a..0a753b9:
> meson: fix building for big-endian host
> quic: fix sign-compare warning
> build-sys: improve asciidoc rules to allow multiple targets
> Add a .gitpublish
> lz: More checks on
>
> Hi
>
> On Thu, Jan 17, 2019 at 12:35 PM Frediano Ziglio wrote:
> >
> > >
> > > Hi
> > >
> > > On Thu, Jan 17, 2019 at 12:15 PM Frediano Ziglio
> > > wrote:
> > > >
> > > > >
> > > > > From: Marc-André Lureau
> > > > >
> > > > > autofoo build-sys defines WORDS_BIGENDIAN, and spice-common
Hi,
On Thu, Jan 17, 2019 at 12:33:09PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Thu, Jan 17, 2019 at 11:43 AM Victor Toso wrote:
> >
> > Hi,
> >
> > On Thu, Jan 17, 2019 at 03:04:32AM +0400, marcandre.lur...@redhat.com wrote:
> > > From: Marc-André Lureau
> > >
> > > autofoo build-sys
Hi
On Thu, Jan 17, 2019 at 12:19 PM Frediano Ziglio wrote:
>
> >
> > From: Marc-André Lureau
> >
> > ../subprojects/spice-common/common/quic.c: In function
> > 'fill_model_structures':
> > ../subprojects/spice-common/common/quic.c:695:55: error: comparison of
> > integer expressions of
Hi
On Thu, Jan 17, 2019 at 12:35 PM Frediano Ziglio wrote:
>
> >
> > Hi
> >
> > On Thu, Jan 17, 2019 at 12:15 PM Frediano Ziglio wrote:
> > >
> > > >
> > > > From: Marc-André Lureau
> > > >
> > > > autofoo build-sys defines WORDS_BIGENDIAN, and spice-common code uses
> > > > it.
> > > >
> > >
>
> Hi
>
> On Thu, Jan 17, 2019 at 12:15 PM Frediano Ziglio wrote:
> >
> > >
> > > From: Marc-André Lureau
> > >
> > > autofoo build-sys defines WORDS_BIGENDIAN, and spice-common code uses it.
> > >
> > > Later, I think it would make sense to switch to G_BIG_ENDIAN instead.
> > >
> >
> > This
Hi
On Thu, Jan 17, 2019 at 11:43 AM Victor Toso wrote:
>
> Hi,
>
> On Thu, Jan 17, 2019 at 03:04:32AM +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > autofoo build-sys defines WORDS_BIGENDIAN, and spice-common code uses it.
> >
> > Later, I think it would make
Hi
On Thu, Jan 17, 2019 at 12:15 PM Frediano Ziglio wrote:
>
> >
> > From: Marc-André Lureau
> >
> > autofoo build-sys defines WORDS_BIGENDIAN, and spice-common code uses it.
> >
> > Later, I think it would make sense to switch to G_BIG_ENDIAN instead.
> >
>
> This comment should not be in the
>
> From: Marc-André Lureau
>
> WORDS_BIGENDIAN is defined by autofoo macro.
autoconf
> meson doesn't define it. Let's use the GLib defines instead.
>
> Signed-off-by: Marc-André Lureau
> ---
> tools/spicy-screenshot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
>
> From: Marc-André Lureau
>
> ../subprojects/spice-common/common/quic.c: In function
> 'fill_model_structures':
> ../subprojects/spice-common/common/quic.c:695:55: error: comparison of
> integer expressions of different signedness: 'int' and 'unsigned int'
> [-Werror=sign-compare]
>
>
> From: Marc-André Lureau
>
> autofoo build-sys defines WORDS_BIGENDIAN, and spice-common code uses it.
>
> Later, I think it would make sense to switch to G_BIG_ENDIAN instead.
>
This comment should not be in the commit message.
IMHO WORDS_BIGENDIAN is fine, is pretty standard and Meson
64 matches
Mail list logo
