On 03/10/2024, 14:05, "Daniel P. Berrangé" wrote:
> The QEMU VNC code has logic which rounds up display sizes to a multiple
> of 16:
>
> static int vnc_width(VncDisplay *vd)
> {
> return MIN(VNC_MAX_WIDTH, ROUND_UP(surface_width(vd->ds),
> VNC_DIRTY_
On Thu, Oct 03, 2024 at 01:01:04PM +, Simon Rowe wrote:
> Looking at the trace output it seems that the displaysurface has been rounded
> from the start
> vnc_client_connect VNC client connect state=0x556dce1c1b20 ioc=0x556dce9e1e70
> displaysurface_create_from surface=0x556dce104b30, 1360x768
Looking at the trace output it seems that the displaysurface has been rounded
from the start
vnc_client_connect VNC client connect state=0x556dce1c1b20 ioc=0x556dce9e1e70
displaysurface_create_from surface=0x556dce104b30, 1360x768, format 0x20020888
vnc_server_dpy_recreate VNC server dpy recreate
On 02/10/2024, 13:01, "Daniel P. Berrangé" wrote:
> There's a newer bug report here, but not real progress:
>
> https://gitlab.com/qemu-project/qemu/-/issues/90
>
> 1366 is particularly problematic as it apparently can't be represented
> exactly in EDID which needs a x8 multiple.
Thanks for the
On Wed, Oct 02, 2024 at 11:09:13AM +, Simon Rowe wrote:
> I've been trying to track down the cause of a glitch that affects guest VNC
> consoles when the resolution is set to 1366x768. This results in a "stair
> case" effect where each successive row is offset to the right by a handful of
>
I've been trying to track down the cause of a glitch that affects guest VNC
consoles when the resolution is set to 1366x768. This results in a "stair case"
effect where each successive row is offset to the right by a handful of pixels.
I believe this is related to the fact that the horizontal re
