Make this a RedsState member function rather than a standalone function.
This means that we simply pass RedsState* as an argument rather than the
internal member variables of RedsState. This enables the following
commit which handles the VD_AGENT_CAP_GRAPHICS_DEVICE_INFO capability to
avoid sending
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/serve
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..72a
Hi,
this is another try to solve the grab race.
Intention of these patches is to make spice-gtk
behave reasonably well with older agents.
The next step would be to fix the protocol itself.
But that will require updating spice-gtk as well as vdagents.
Cheers,
Jakub
Jakub Janků (3):
clipboard:
If two grab messages in opposite directions "meet" on their way
to their destinations, we end up in a state when both spice-gtk
and spice-vdagent think that the other component can provide
clipboard data. As a consequence of this, neither of them can.
This is a bug in the spice-protocol. To mitiga
Targets request is no longer relevant when
clipboard owner changes since the retrieved targets
will be outdated.
When the request is no longer relevant,
invalidate it by pointing its weak ref to NULL.
As a consequence, free_weak_ref() call returns NULL
and clipboard_get_targets() exits.
Signed-of
If spice-vdagent requests clipboard data while
it has previously advertised that it itself can provide it,
acknowledge that it's likely a race condition and not a
programming error.
In this case, release clipboard in spice-gtk as well as vdagent
to prevent other apps from requesting data from us w
On Thu, 2019-02-28 at 03:31 -0500, Frediano Ziglio wrote:
> >
> > In 8251fa25, a check on the minimum size of a message was
> > introduced.
> > For unsupported messages, the vdagent simply exited. This makes it
> > difficult to extend the vdagent protocol without breaking old
>
> The protocol is
Hi,
On Wed, Feb 27, 2019 at 11:39:33PM +0100, Jakub Janku wrote:
> Hi,
>
> On Mon, Feb 25, 2019 at 6:04 PM Victor Toso wrote:
> >
> > From: Victor Toso
> >
> > It is not relevant nowadays that *spicec* client was removed and even
> > monitors_config does not reach spice-vdagent in modern Guests
> On 2/25/19 4:12 PM, Frediano Ziglio wrote:
> >>
> >> When building with older mingw, sprintf_s does not
> >> always work as expected, but snprintf does.
> >>
> >> Also it's more consistent in the file.
> >>
> >> Note that when building with VS, snprintf becomes sprintf_s
> >>
> >
> > I think thi
On 2/28/19 11:38 AM, Victor Toso wrote:
Hi,
On Thu, Feb 28, 2019 at 11:04:51AM +0200, Uri Lublin wrote:
On 2/25/19 2:08 PM, Victor Toso wrote:
On Mon, Feb 25, 2019 at 12:20:06PM +0200, Uri Lublin wrote:
When building with older mingw, sprintf_s does not
always work as expected, but snprintf d
Hi,
On Thu, Feb 28, 2019 at 11:04:51AM +0200, Uri Lublin wrote:
> On 2/25/19 2:08 PM, Victor Toso wrote:
> > On Mon, Feb 25, 2019 at 12:20:06PM +0200, Uri Lublin wrote:
> > > When building with older mingw, sprintf_s does not
> > > always work as expected, but snprintf does.
> > >
> > > Also it's
On 2/28/19 10:48 AM, Snir Sheriber wrote:
Passing CI (on top of the " Add copr Makefile" patch but it should not
affect the CI)
https://gitlab.com/sheriber/spice-streaming-agent/commit/2f34198f1ba74ceb47f82dfb13023c857034f16b/pipelines?ref=ci
On 2/27/19 6:00 PM, Snir Sheriber wrote:
Do not
On 2/25/19 1:15 PM, Frediano Ziglio wrote:
When building with older mingw, sprintf_s does not
always work as expected, but snprintf does.
Also it's more consistent in the file.
Note that when building with VS, snprintf becomes sprintf_s
Related: rhbz#1410181
Signed-off-by: Uri Lublin
Yes,
On 2/25/19 4:12 PM, Frediano Ziglio wrote:
When building with older mingw, sprintf_s does not
always work as expected, but snprintf does.
Also it's more consistent in the file.
Note that when building with VS, snprintf becomes sprintf_s
I think this could be a bug, from documentation:
"If
On 2/25/19 2:08 PM, Victor Toso wrote:
On Mon, Feb 25, 2019 at 12:20:06PM +0200, Uri Lublin wrote:
When building with older mingw, sprintf_s does not
always work as expected, but snprintf does.
Also it's more consistent in the file.
Note that when building with VS, snprintf becomes sprintf_s
Passing CI (on top of the " Add copr Makefile" patch but it should not
affect the CI)
https://gitlab.com/sheriber/spice-streaming-agent/commit/2f34198f1ba74ceb47f82dfb13023c857034f16b/pipelines?ref=ci
On 2/27/19 6:00 PM, Snir Sheriber wrote:
Do not count on copr nightly for getting the depende
On return from S3 the driver may receive failure when
calls DxgkCbAcquirePostDisplayOwnership. In general the
driver is not expected to use this method when returns
from S3 but it is not simple to distinguish between S3
and S4 power transition (possible, due to hybrid sleep).
Current commit avoids
>
> In 8251fa25, a check on the minimum size of a message was introduced.
> For unsupported messages, the vdagent simply exited. This makes it
> difficult to extend the vdagent protocol without breaking old
The protocol is using capabilities, there should not be
unsupported messages.
> installat
19 matches
Mail list logo
