Hi,
> > VNC is protocol limited to uint16 for width/height size, and so is X11
> > so I imagine some exploding behavour would follow :-)
>
> Indeed, and even 2^16 x 2^16 * 32bpp is already 34 bits. So perhaps we
> should limit VNC to 16384 pixels on each axis (maximum fra
On 18/01/2018 17:06, Thomas Huth wrote:
> On 18.01.2018 16:33, Paolo Bonzini wrote:
>> On 18/01/2018 15:50, Peter Maydell wrote:
>>> On 18 January 2018 at 14:46, Paolo Bonzini wrote:
On 18/01/2018 15:12, Daniel P. Berrange wrote:
>> In addition to that, do we support a >= 2 GiB framebuffe
On 18.01.2018 16:33, Paolo Bonzini wrote:
> On 18/01/2018 15:50, Peter Maydell wrote:
>> On 18 January 2018 at 14:46, Paolo Bonzini wrote:
>>> On 18/01/2018 15:12, Daniel P. Berrange wrote:
> In addition to that, do we support a >= 2 GiB framebuffer at all? (Even
> with unsigned ints, Cove
On 18/01/2018 15:50, Peter Maydell wrote:
> On 18 January 2018 at 14:46, Paolo Bonzini wrote:
>> On 18/01/2018 15:12, Daniel P. Berrange wrote:
In addition to that, do we support a >= 2 GiB framebuffer at all? (Even
with unsigned ints, Coverity would rightly complain about a truncated
>>
On 18 January 2018 at 14:46, Paolo Bonzini wrote:
> On 18/01/2018 15:12, Daniel P. Berrange wrote:
>>> In addition to that, do we support a >= 2 GiB framebuffer at all? (Even
>>> with unsigned ints, Coverity would rightly complain about a truncated
>>> 32-bit multiplication being assigned to a 64-
On 18/01/2018 15:12, Daniel P. Berrange wrote:
>> In addition to that, do we support a >= 2 GiB framebuffer at all? (Even
>> with unsigned ints, Coverity would rightly complain about a truncated
>> 32-bit multiplication being assigned to a 64-bit value).
> client_width/client_height are values that
On Thu, Jan 18, 2018 at 02:54:48PM +0100, Paolo Bonzini wrote:
> On 18/01/2018 14:36, Daniel P. Berrange wrote:
> >>> +/*
> >>> + * Figure out how much pending data we should allow in the output
> >>> + * buffer before we throttle incremental display updates, and/or
> >>> + * drop audio samples.
>
On 18/01/2018 14:36, Daniel P. Berrange wrote:
>>> +/*
>>> + * Figure out how much pending data we should allow in the output
>>> + * buffer before we throttle incremental display updates, and/or
>>> + * drop audio samples.
>>> + *
>>> + * We allow for equiv of 1 full display's worth of FB updates,
On Thu, Jan 18, 2018 at 01:29:35PM +, Peter Maydell wrote:
> On 12 January 2018 at 12:58, Gerd Hoffmann wrote:
> > From: "Daniel P. Berrange"
> >
> > The VNC server must throttle data sent to the client to prevent the 'output'
> > buffer size growing without bound, if the client stops reading
On 12 January 2018 at 12:58, Gerd Hoffmann wrote:
> From: "Daniel P. Berrange"
>
> The VNC server must throttle data sent to the client to prevent the 'output'
> buffer size growing without bound, if the client stops reading data off the
> socket (either maliciously or due to stalled/slow network
From: "Daniel P. Berrange"
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because
11 matches
Mail list logo
