Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> The only caller only called that function.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/display-channel.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/display-channel-private.h | 1 +
> server/display-channel.c | 10 --
> server/display-channel.h | 2 ++
> s
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> Do not check it after assigning to reds->config->image_compression,
> check the value as soon as possible.
> This prevent potential invalid settings.
>
> Signed-off-by: Frediano Ziglio
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> DisplayChannelClient get them directly from reds (they are changed
> only during initialisation so they can be read freely from any
> thread).
>
> Signed-off-by: Frediano Ziglio
>
This also looks like a patch that should get squashed (maybe parts
should be squashed into two different previous commits, see below), but
I agree with all of the changes.
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Zig
Personally, I would squash this patch with the previous one
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> Now that stuff are a bit more on their correct place some
> function can be static.
>
> Signed-off-by: Frediano Ziglio
> ---
&
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> No reasons to expose red_qxl_is_running, this was used to not
> send capability is the state was not running.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/display-channel.c | 3 ---
&
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/display-channel.c | 108 +
> server/display-channel.h | 7 +++
> server/red-work
Acked-by: Jonathon Jongsma
On Tue, 2019-03-26 at 19:10 +, Frediano Ziglio wrote:
> Currently channel threading/handling is spread between RedQxl,
> RedWorker and RedChannel.
> Move more to RedChannel simplify RedQxl and RedWorker.
>
> Signed-off-by: Frediano Ziglio
> --
essage_type,
> void *payload);
>
> +/* dispatcher_send_message_custom
> + *
> + * Sends a message to the receiving thread.
> + *
> + * If the sent message is a message type requires an ACK, this
> function will
> + * block until it receives an ACK from the receiving thread.
The comment above is a little bit confusing because in this case the
message type doesn't determine whether an ACK is required. The @ack
argument determines whether an ACK is required. Maybe remove the phrase
"is a message type ". So it becomes:
"If the sent message requires an ACK, this function..."
> + *
> + * @handler: callback to handle message
> + * @payload: payload
> + * @payload_size: size of payload
> + * @ack: acknowledge required. Make message synchronous
> + */
> +void dispatcher_send_message_custom(Dispatcher *dispatcher,
> dispatcher_handle_message handler,
> +void *payload, uint32_t
> payload_size, bool ack);
> +
> /* dispatcher_register_handler
> *
> * This function registers a message type with the dispatcher, and
> registers
with minor comments above:
Acked-by: Jonathon Jongsma
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
From: Frediano Ziglio
This is a preparatory patch that states the running property in QXLState
and provides accessor functions that allows us to check whether the QXL
device is running from different threads.
Signed-off-by: Jonathon Jongsma
---
Alternate proposal for patch 7/10. I also rebased
Somehow this information doesn't really seem to belong to
DisplayChannel, but I can't put my finger on exactly why it feels out
of place...
On Wed, 2019-03-20 at 09:59 +, Frediano Ziglio wrote:
> This is a preparatory patch to allows DisplayChannel to check
> if device is running.
>
> Signe
red_channel_init_stat_node(channel, &worker->stat,
> "display_channel");
> -red_channel_register_client_cbs(channel, client_display_cbs);
> -g_object_set_data(G_OBJECT(channel), "dispatcher", dispatcher);
> +g_object_set_data(G_OBJECT(
There should be some justification in the commit log about why this is
an improvement.
Jonathon
On Wed, 2019-03-20 at 09:59 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/main-dispatcher.c | 38 --
> 1 file changed, 8 insertion
Acked-by: Jonathon Jongsma
On Wed, 2019-03-20 at 09:59 +, Frediano Ziglio wrote:
> No reason to pass through MainDispatcher, the purpose of
> MainDispatcher is to call reds functions from the right thread.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/main
That's a weird function, but seems rather unrelated to the current
series.
Acked-by: Jonathon Jongsma
On Wed, 2019-03-20 at 09:59 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/main-dispatcher.c | 13 ++---
> 1 file changed, 2
>type = message_type;
> msg->ack = ack;
> if (msg->size > dispatcher->priv->payload_size) {
> dispatcher->priv->payload = g_realloc(dispatcher->priv-
> >payload, msg->size);
> diff --git a/server/dispatcher.h b/server/di
Acked-by: Jonathon Jongsma
On Wed, 2019-03-20 at 09:59 +, Frediano Ziglio wrote:
> handler is a pointer, check for NULL, not 0.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/dispatcher.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
This way, the cursor channel can be subclassed. This will be used in
future commits as I refactor the client callbacks.
---
server/cursor-channel.c | 62 +++--
server/cursor-channel.h | 12
2 files changed, 40 insertions(+), 34 deletions(-)
diff --git
Rather than having an API to register client callbacks for each channel
type, make them vfuncs.
Since the client callbacks are registered identically for each channel
of the same type, it doesn't make sense for to require these to be
registered separately for each object. It's cleaner to have the
On Mon, 2019-03-18 at 09:53 -0400, Frediano Ziglio wrote:
> > On Mon, Mar 11, 2019 at 12:42:10PM -0400, Frediano Ziglio wrote:
> > > >
> > > > Series looks good to me,
> > > >
> > > > Reviewed-by: Christophe Fergeau
> > > >
> > >
> > > Why not ack? Not good enough? Not tested? Missing somethin
On Fri, 2019-03-15 at 05:05 -0400, Frediano Ziglio wrote:
> >
> > For the Display Channel and the Cursor channel, move the call to
> > reds_register_channel() to the _constructed() vfunc rather than
> > calling
> > it explicitly from RedWorker. This matches what other channels do.
> > ---
> > Chan
For the Display Channel and the Cursor channel, move the call to
reds_register_channel() to the _constructed() vfunc rather than calling
it explicitly from RedWorker. This matches what other channels do.
---
Changes in v2:
- remove cursor channel registration in stream device
Note that I didn't i
message was received and ignore it.
Signed-off-by: Jonathon Jongsma
---
changes in v2:
- change rationale in commit log
vdagent/vdagent.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/vdagent/vdagent.cpp b/vdagent/vdagent.cpp
index 89019bb..177e663 100644
--- a/vdagent
For coding style consistency, use 'bool' when we want to represent a
boolean value.
Signed-off-by: Jonathon Jongsma
---
Changes in v2:
- new patch
server/reds.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index
sending graphics device info to agents that do not support it.
Signed-off-by: Jonathon Jongsma
---
server/reds.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 2e5c69e60..63bfadb22 100644
--- a/server/reds.c
+++ b/server/reds.c
Only send the graphics device display info to agents that advertise the
VD_AGENT_CAP_GRAPHICS_DEVICE_INFO capability
Signed-off-by: Jonathon Jongsma
---
Changes in v2:
- renamed member variable
- moved variable to RedCharDeviceVDIPortPrivate
- reset variable when agent disconnects
- make
sending graphics device info to agents that do not support it.
Signed-off-by: Jonathon Jongsma
---
server/reds.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 2e5c69e60..63bfadb22 100644
--- a/server/reds.c
+++ b/server/reds.c
Only send the graphics device display info to agents that advertise the
VD_AGENT_CAP_GRAPHICS_DEVICE_INFO capability
Signed-off-by: Jonathon Jongsma
---
server/reds-private.h | 1 +
server/reds.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/server/reds-private.h b
Since we now support the graphics device info message, advertise this
fact when sending capabilities to the server.
Signed-off-by: Jonathon Jongsma
---
src/vdagentd/vdagentd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
index f80f48b
eans that it's not correct,
> this is another indication that it's wrong.
>
> > Signed-off-by: Jonathon Jongsma
> > ---
> > vdagent/vdagent.cpp | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/vdagent/vdagent.c
and ignore it.
Signed-off-by: Jonathon Jongsma
---
vdagent/vdagent.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/vdagent/vdagent.cpp b/vdagent/vdagent.cpp
index 89019bb..177e663 100644
--- a/vdagent/vdagent.cpp
+++ b/vdagent/vdagent.cpp
@@ -1288,8 +1288,7 @@ void VDAgent
Acked-by: Jonathon Jongsma
On Fri, 2019-02-22 at 16:12 +, Frediano Ziglio wrote:
> RedPipeItem is not using the Ring structures anymore.
> Also is not using GLib functionality.
> Just include base headers.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-pipe
So, I applied these patches, and generated the messages with the new
code and compared it to the old hand-coded message.h file. I had to re-
arrange a bunch of the newly-generated code to get a readable diff, but
I end up with the attached output. A few notable changes:
- Quite a few fields have c
DstInfo;
Hmm, slightly tricky, this one. It's technically an ABI change, but
since we only use spice-common as a submodule, I suppose it's OK to
remove.
I'd like to see the commit log mention that this is leftover from v1 of
the protocol, which we removed support for already
uot;
> -#include "image-encoders.h"
> #include "common-graphics-channel.h"
Seems that display-channel.h uses a GlzImageRetention type which is
defined in image-encoders.h. And BitmapGradualType which is defined in
spice-bitmap-utils.h. Presumably these headers are i
,
Acked-by: Jonathon Jongsma
On Thu, 2019-02-21 at 15:59 +, Frediano Ziglio wrote:
> Allows the compiler to catch some errors which are only triggered
> when
> building with optimizations enabled.
>
> Signed-off-by: Frediano Ziglio
> ---
> .gitlab-ci.yml | 10 +-
>
e, but what kind of errors are you talking about?
> > Reviewed-by: Jonathon Jongsma
> >
>
> Like "this variable is not used" or "this variable is not
> initialized"
> for instance.
> Not sure if people prefers "release" or "debugoptimized
On Wed, 2019-02-20 at 07:08 -0500, Frediano Ziglio wrote:
> >
> > For the Display Channel and the Cursor channel, move the call to
> > reds_register_channel() to the _constructed() vfunc rather than
> > calling
> > it explicitly from RedWorker. This matches what other channels do.
>
> I think thi
On Thu, 2019-02-14 at 12:56 +, Frediano Ziglio wrote:
> Allows to catch some errors which the compiler is not able to
> detect in debug mode (the default).
Seems fine, but what kind of errors are you talking about?
Reviewed-by: Jonathon Jongsma
>
> Signed-off-by: Fre
On Wed, 2019-02-20 at 07:08 -0500, Frediano Ziglio wrote:
> >
> > For the Display Channel and the Cursor channel, move the call to
> > reds_register_channel() to the _constructed() vfunc rather than
> > calling
> > it explicitly from RedWorker. This matches what other channels do.
>
> I think thi
For the Display Channel and the Cursor channel, move the call to
reds_register_channel() to the _constructed() vfunc rather than calling
it explicitly from RedWorker. This matches what other channels do.
---
server/cursor-channel.c | 12
server/display-channel.c | 2 ++
server/red-w
On Wed, 2019-02-13 at 09:19 -0500, Frediano Ziglio wrote:
> >
> > Stream devices assume that all QXL devices are registered with the
> > server before we receive any communications from the stream device.
> > This
> > is due to the fact that QXL display channel IDs are assigned
> > directly
> > fr
Acked-by: Jonathon Jongsma
On Tue, 2019-02-12 at 21:24 +, Frediano Ziglio wrote:
> This was added in bd8771adbcf3ff34d14333cf874191e8d105f612.
> There's no reason to not use reds function instead.
> MainDispatcher needs to listen in the main thread that is the
> one provi
Looks fine to me.
Insofar as I can ACK a patch that's partially my own code:
Acked-by: Jonathon Jongsma
:)
On Tue, 2019-02-12 at 21:24 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> Signed-off-by: Jonathon Jongsma
> Reviewed-by: Jonathon Jongsma
> --
why not
Acked-by: Jonathon Jongsma
On Mon, 2019-02-11 at 11:54 +, Frediano Ziglio wrote:
> Most of the time result is set to AGENT_MSG_FILTER_OK, set at
> the beginning and change if necessary.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/agent-msg-filter.c | 14 +
Looks mostly good, but I found an issue and had a couple suggested
improvments. So I sent a couple follow-up patches that you can squash
with this patch if you think they're valid.
Reviewed-by: Jonathon Jongsma
On Mon, 2019-02-11 at 11:54 +, Frediano Ziglio wrote:
> Signed-off-by:
Rather than showing the expected data in raw format (ascii codes, etc),
which is hard to verify, show the characters themselves, and group them
by structure.
Also add a few more comments.
---
server/tests/test-stream-device.c | 35 +++
1 file changed, 26 insertions(+),
Stream devices assume that all QXL devices are registered with the
server before we receive any communications from the stream device. This
is due to the fact that QXL display channel IDs are assigned directly
from the QXL device ID, whereas Stream display channels are assigned
channel IDs based on
On Tue, 2019-02-12 at 12:24 -0500, Frediano Ziglio wrote:
> > On Tue, 2019-02-12 at 04:05 -0500, Frediano Ziglio wrote:
> > >
> > > > Untested, but looks fine.
> > > >
> > > > Acked-by: Jonathon Jongsma
> > > >
> > &g
Untested, but looks fine.
Acked-by: Jonathon Jongsma
On Mon, 2019-02-11 at 11:54 +, Frediano Ziglio wrote:
> Instead of scanning the monitor twice (one to compute the size
> and another to build the message) use a single function to
> marshall the message.
> This also fixe
ing some gstreamer sink plugin which implements the
> GstVideoOverlay interface
> + * 3) Decompressed frames will be rendered to widget directly from
> GStreamer's pipeline
"to *the* widget" sounds more correct. Otherwise I'd say the rest of
this patch looks fine. I on
Use brackets everywhere.
---
src/vdagent/device-info.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/src/vdagent/device-info.c b/src/vdagent/device-info.c
index 7c0f615..4983543 100644
--- a/src/vdagent/device-info.c
+++ b/src/vdagent/device-info
t "$with_session_info" = "auto" || test "$with_session_info"
> > =
> > "systemd"; then
> > PKG_CHECK_MODULES([LIBSYSTEMD_LOGIN],
> > diff --git a/src/vdagent/device-info.c b/src/vdagent/device-info.c
> > new file mode 100644
> &g
Acked-by: Jonathon Jongsma
On Mon, 2019-01-28 at 11:14 +0100, Lukáš Hrázký wrote:
> Instead of one unsupported example, present two real world examples.
>
> Signed-off-by: Lukáš Hrázký
> ---
> server/spice-qxl.h | 32 ++--
> 1 file changed, 22
On Mon, 2019-01-28 at 15:09 +0100, Lukáš Hrázký wrote:
> Adds serialization of the GraphicsDeviceInfo message and sends it to
> the
> server when it starts to stream.
>
> Signed-off-by: Lukáš Hrázký
> Reviewed-by: Jonathon Jongsma
> ---
> configure.ac
Acked-by: Jonathon Jongsma
On Mon, 2019-01-28 at 15:09 +0100, Lukáš Hrázký wrote:
> Receives the GraphicsDeviceInfo message from the streaming agent and
> stores the data in a list on the streaming device.
>
> Signed-off-by: Lukáš Hrázký
> ---
> server/display-limits.h
nd display id
+ *
+ * Copyright 2018 Red Hat, Inc.
+ *
+ * Red Hat Authors:
+ * Jonathon Jongsma
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the L
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.
In the case where we have an mjpeg plugin running in the streaming
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, f
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 | 58
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 | 81 -
1 file changed, 72 insertions(+), 9 deletions(-)
diff --git a/src/vdagent/x11-randr.c b/src/vdagent/x11-randr.
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.
---
src/vdagent/x11-randr
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"
Previous
- removed goto
- improved logging
- etc.
Jonathon Jongsma (7):
Add lookup_xrand_output_for_device_info()
Look up and store xrandr output in display map
Make clearer distinctions between output ids
Use guest output map to determine xrandr output
Factor a function out of get_cur
On Fri, 2019-01-18 at 15:56 +0400, Marc-André Lureau wrote:
> Hi
>
> On Fri, Jan 18, 2019 at 3:47 PM Frediano Ziglio
> wrote:
> >
> > >
> > > From: Marc-André Lureau
> > >
> > > Maintaining 1 build system is hard. Maintaining 2 is even harder.
> > >
> > > It seems the meson build system is n
nd display id
+ *
+ * Copyright 2018 Red Hat, Inc.
+ *
+ * Red Hat Authors:
+ * Jonathon Jongsma
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the L
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.
---
src/vdagent/x11-randr
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"
Previous
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, f
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 a/src
utput index and crtc index
- added a patch to send new display IDs when device info changes
- multiple changes from review
- factored out function find_device_at_pci_address()
- No more initializing X/XRandr
- removed goto
- improved logging
- etc.
Jonathon Jon
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 b/src/vdagent/x11-randr.
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) => X
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-of
evice_address.c_str(),
> + info.device_display_id);
> +}
> +
> +if (display_info.size() > 0) {
> +stream_port.send(display_info[
> 0]);
Shouldn't we have some handling here in case size() is greater than 1?
at least print a warning or something?
> +} else {
> +syslog(LOG_ERR, "Empty device display info from the
> plugin");
> }
>
> while (!quit_requested && streaming_requested) {
Reviewed-by: Jonathon Jongsma
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
o);
> +}
> +
> +XRRFreeScreenResources(screen_resources);
> +return result;
> +}
> +
> +std::vector get_device_display_info_drm(Display
> *display)
> +{
> + auto outputs = get_outputs();
> +
> +// sorting by output name, may not be necessary (the list sho
display_ids() / etc?
I know that the stream device currently (and probably always) only has
a single display per channel, but part of me wishes the interfaces had
some consistency. Not a big issue, just curious.
Acked-by: Jonathon Jongsma
> static StreamDevice *
> stream_device_
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
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
> monit
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 channe
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: L
On Wed, 2019-01-16 at 13:34 +0100, Lukáš Hrázký wrote:
> > > +StreamMsgDeviceDisplayInfo *display_info_msg =
> > > &dev->msg->device_display_info;
> > > +
> > > +size_t device_address_len =
> > > GUINT32_FROM_LE(display_info_msg->device_address_len);
> > > +if (device_address_len > MAX_
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
On Fri, 2019-01-11 at 10:07 +0100, Lukáš Hrázký wrote:
> Hi,
>
> On Thu, 2019-01-10 at 15:27 -0600, Jonathon Jongsma wrote:
> > On Tue, 2019-01-08 at 16:28 +0100, Lukáš Hrázký wrote:
> > > Receives the GraphicsDeviceInfo message from the streaming agent
> > > an
On Fri, 2019-01-11 at 11:15 +0100, Lukáš Hrázký wrote:
> On Wed, 2019-01-09 at 11:36 -0600, Jonathon Jongsma wrote:
> > On Tue, 2019-01-08 at 16:26 +0100, Lukáš Hrázký wrote:
> > > Adds a function to let QEMU provide information to identify
> > > graphics
> > &g
On Tue, 2019-01-08 at 16:28 +0100, Lukáš Hrázký wrote:
> Receives the GraphicsDeviceInfo message from the streaming agent and
> stores the data in a list on the streaming device.
>
> Signed-off-by: Lukáš Hrázký
> ---
> server/red-qxl.c | 1 -
> server/red-stream-device.c | 66
> ++
On Tue, 2019-01-08 at 16:28 +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.
>
> TODO: doesn't resend the message on agent rec
On Wed, 2019-01-09 at 12:43 +0100, Lukáš Hrázký wrote:
> On Wed, 2019-01-09 at 02:38 -0500, Frediano Ziglio wrote:
> > >
> > > The message contains information about the graphics device and
> > > monitor
> > > belonging to a particular video stream (which maps to a channel)
> > > from
> > > the st
On Tue, 2019-01-08 at 16:28 +0100, Lukáš Hrázký wrote:
> The message serves for passing the device address and device display
> ID
> information for all display channels from SPICE server to the
> vd_agent.
>
> Signed-off-by: Lukáš Hrázký
> ---
> spice/vd_agent.h | 15 +++
> 1 file c
This patch looks reasonable to me, but I wonder if you could expand the
commit log to indicate the steps required to trigger the warning? In
what situation is this function (clipboard_get()) being called when the
agent is not connected?
Jonathon
On Thu, 2019-01-10 at 16:39 +0100, Victor Toso
Acked-by: Jonathon Jongsma
On Tue, 2019-01-08 at 16:26 +0100, Lukáš Hrázký wrote:
> Replace it by spice_qxl_set_device_info. Note we can't use
> monitors_count for what's stored in max_monitors, because
> monitors_count
> denotes the length of the device_di
On Tue, 2019-01-08 at 16:26 +0100, Lukáš Hrázký wrote:
> Adds a function to let QEMU provide information to identify graphics
> devices and their monitors in the guest. The function
> (spice_qxl_set_device_info) sets the device address (e.g. a PCI path)
> and monitor ID -> device display ID mapping
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"
Previous
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 a/src
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.
---
src/vdagent/x11-randr
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, f
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 -
1 - 100 of 2454 matches
Mail list logo
