>
> Signed-off-by: Jeremy White
Acked-by: Frediano Ziglio
> ---
> v3 Use the obviously better PRIx64
> v2 Use (u) (u) thing instead of (u) ((u) thing)
>Simplify some casting where possible
> ---
> src/scan.c| 6 +++---
> src/session.c | 8
> src/spice.c | 18 +++-
Signed-off-by: Jeremy White
---
v3 Use the obviously better PRIx64
v2 Use (u) (u) thing instead of (u) ((u) thing)
Simplify some casting where possible
---
src/scan.c| 6 +++---
src/session.c | 8
src/spice.c | 18 +++---
3 files changed, 18 insertions(+), 14 dele
>
> >
> > On 6/3/19 2:22 PM, Frediano Ziglio wrote:
> > > The formula is here to make sure glyph is aligned to 4 bytes so
> > > tell to the compiler to avoid a warning.
> >
> > What's the warning ?
>
> Trying to reproduce but the updated environment it's slow like
> hell (it's more than 30 minu
>
> On 6/3/19 2:22 PM, Frediano Ziglio wrote:
> > The formula is here to make sure glyph is aligned to 4 bytes so
> > tell to the compiler to avoid a warning.
>
> What's the warning ?
Trying to reproduce but the updated environment it's slow like
hell (it's more than 30 minutes that it's compili
On 6/3/19 2:22 PM, Frediano Ziglio wrote:
The formula is here to make sure glyph is aligned to 4 bytes so
tell to the compiler to avoid a warning.
What's the warning ?
Is it that the pointer may be unaligned (which is imposible
if you start from an aligned address) ?
Looks complicated to me, e
>
> The IO operation is cancelled on channel dispose
> and it is not an error, so silence the warnings.
>
> Signed-off-by: Jakub Janků
> ---
> src/channel-webdav.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> in
>
> The current implementation finishes it
> only after new data arrives from the channel (or after it is cancelled).
>
Minor: weird split of long line
> Signed-off-by: Jakub Janků
> ---
> src/vmcstream.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git
>
> In pipe_output_stream_is_writable, if the peer is already gone,
> peer_closed is set to TRUE and in this case, peer->read should not be
> accessed
> as peer is NULL.
>
> Otherwise, the following sequence of calls (simplified) would trigger a
> segfault:
>
> spice_make_pipe(p1, p2);
>
> >
> > The point of the mmtime timestamps is that they are the same on the
> > server and client thanks to the client running its own mmtime clock
> > synchronized, modulo a server-controlled offset, to the server's
Not sure about the "modulo a server-controlled offset", I would
say "biased by a
On 6/3/19 2:22 PM, Frediano Ziglio wrote:
This patch came from some experiments using an emulated MIPS machine.
On such architecture due to not supporting alignment access the
compiler is more strict about conversion complaining with some
pointer casts. Use different conversion to avoid these war
On 2019/06/14, Daniel Vetter wrote:
> Split out to make the functional changes stick out more.
>
Since this patch flew-by, as standalone one (intentionally or not) I'd
add, anything vaguely like:
"Core users of DRIVER_PRIME were removed from core with prior patches."
HTH
Emil
___
>
> The point of the mmtime timestamps is that they are the same on the
> server and client thanks to the client running its own mmtime clock
> synchronized, modulo a server-controlled offset, to the server's
> mmtime clock.
> So the frame mmtime timestamps are neither tied to the server nor the
>
"audio_delay" is 32 bit as defined by protocol.
Signed-off-by: Frediano Ziglio
---
src/channel-display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/channel-display.c b/src/channel-display.c
index cda0fcdd..542920bb 100644
--- a/src/channel-display.c
+++ b/src/channel
This follows up commit 887aedff41bdb89845e7cb349454a8dcbb515db4
"The video latency is in fact a margin".
Signed-off-by: Frediano Ziglio
---
src/channel-display-priv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/channel-display-priv.h b/src/channel-display-priv.h
i
>
> 'Latency' is confusing because it evokes either the network latency
> or the audio latency, neither of which match what the latency
> variables contain. Instead they record how much margin there was
> between when the frame was received, and when it is supposed to be
> displayed. Hence the new
>
> By the time schedule_frame() pulls a sample off GStreamer's pipeline the
> frame may have been decoded for hundreds of milliseconds, making the
> decoding time all but meaningless.
> This patch ensures the statistics are always collected by
> sink_event_probe() which is called as soon as the
>
> The number of frames that were sitting in the decoding_queue before the
> current frame was added is crucial to correctly interpret the decoding
> time:
> * Less than MAX_DECODED_FRAMES means nothing blocked the decoding of
> that frame.
> * More than MAX_DECODED_FRAMES means decoding was de
17 matches
Mail list logo
