>
> 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
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
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 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
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 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/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
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 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
> 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
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 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
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
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
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
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
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
19 matches
Mail list logo
