[{"id":3678916,"web_url":"http://patchwork.ozlabs.org/comment/3678916/","msgid":"<58180aa1-4e39-4aa8-6d3b-586d4461deba@eik.bme.hu>","list_archive_url":null,"date":"2026-04-18T00:03:14","subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","submitter":{"id":16148,"url":"http://patchwork.ozlabs.org/api/people/16148/","name":"BALATON Zoltan","email":"balaton@eik.bme.hu"},"content":"On Fri, 17 Apr 2026, Chad Jablonski wrote:\n> When using a virtual desktop any amount of scrolling would cause\n> ati_set_dirty to set the wrong region of memory as dirty and screen\n> updates are missed. This is because the previous implementation\n\nI guess this is to fix chars not appearing in xterm when a virtual desktop \nis panned that you noticed here?\nhttps://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg00785.html\n\n> used vga->vbe_start_addr in the dirty address calculation. It\n> works when it's zero but as soon as the virtual desktop is involved\n> it's often non-zero.\n>\n> The first issue is that vga->vbe_start_addr is a word offset and was\n> being added to byte offsets. But regardless, the vbe_start_address affects\n> the scan out and not the framebuffer. We shouldn't need to apply an\n> offset for it at all when thinking about dirty tracking.\n\nObviously I don't quite understood how dirty tracking should work.\n\n> The second is that a bounds check was also being performed to ensure\n> that the dirty memory was within the visible screen. With the virtual\n> desktop this isn't actually what we want. Updates can and will happen\n> outside of the visible screen area. Those should be marked dirty.\n\nBut I still think only the visible area should need marking dirty because it \nis used to update display so marking non visible parts should have no \neffect. I'm not sure if it has any performance impact but just seems \nunnecessary so that's why this tried to limit it to visible area. I've \nadded to cc some people who could maybe enlighten us on this.\n\n> Signed-off-by: Chad Jablonski \n> ---\n> hw/display/ati_2d.c | 16 +++++-----------\n> 1 file changed, 5 insertions(+), 11 deletions(-)\n>\n> diff --git a/hw/display/ati_2d.c b/hw/display/ati_2d.c\n> index 504d1c5708..dc33b014eb 100644\n> --- a/hw/display/ati_2d.c\n> +++ b/hw/display/ati_2d.c\n> @@ -71,17 +71,11 @@ static void ati_set_dirty(VGACommonState *vga, const ATI2DCtx *ctx)\n> DisplaySurface *ds = qemu_console_surface(vga->con);\n>\n> (void)ds;\n> - DPRINTF(\"%p %u ds: %p %d %d rop: %x\\n\", vga->vram_ptr, vga->vbe_start_addr,\n> - surface_data(ds), surface_stride(ds), surface_bits_per_pixel(ds),\n> - ctx->rop3 >> 16);\n> - if (ctx->dst_bits >= vga->vram_ptr + vga->vbe_start_addr &&\n> - ctx->dst_bits < vga->vram_ptr + vga->vbe_start_addr +\n> - vga->vbe_regs[VBE_DISPI_INDEX_YRES] * vga->vbe_line_offset) {\n> - memory_region_set_dirty(&vga->vram,\n> - vga->vbe_start_addr + ctx->dst_offset +\n> - ctx->dst.y * ctx->dst_stride,\n> - ctx->dst.height * ctx->dst_stride);\n> - }\n> + DPRINTF(\"%p ds: %p %d %d rop: %x\\n\", vga->vram_ptr, surface_data(ds),\n> + surface_stride(ds), surface_bits_per_pixel(ds), ctx->rop3 >> 16);\n> + memory_region_set_dirty(&vga->vram,\n> + ctx->dst_offset + ctx->dst.y * ctx->dst_stride,\n> + ctx->dst.height * ctx->dst_stride);\n> }\n\nIf this is how it should be done and limiting dirty tracking to visible \npart does not save any work I wonder if we still need this funcion and \ncouldn't just use memory_region_set_dirty directly? I'd like to avoid \nslowing updates down with unnecessarily marking off screen areas but I'm \nnot sure that concern is valid.\n\nRegards,\nBALATON Zoltan","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fyBmW36fRz1yGt\n\tfor ; Sat, 18 Apr 2026 10:03:39 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wDt9i-0007uc-K2; Fri, 17 Apr 2026 20:03:26 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wDt9f-0007u9-8B\n for qemu-devel@nongnu.org; Fri, 17 Apr 2026 20:03:23 -0400","from zero.eik.bme.hu ([2001:738:2001:2001::2001])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wDt9c-0005LG-H7\n for qemu-devel@nongnu.org; Fri, 17 Apr 2026 20:03:22 -0400","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id 2F2F159695A;\n Sat, 18 Apr 2026 02:03:17 +0200 (CEST)","from zero.eik.bme.hu ([127.0.0.1])\n by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP\n id lRqY68p_bdac; Sat, 18 Apr 2026 02:03:14 +0200 (CEST)","by zero.eik.bme.hu (Postfix, from userid 432)\n id A163D596958; Sat, 18 Apr 2026 02:03:14 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id 9F699596954;\n Sat, 18 Apr 2026 02:03:14 +0200 (CEST)"],"X-Virus-Scanned":"amavis at eik.bme.hu","Date":"Sat, 18 Apr 2026 02:03:14 +0200 (CEST)","From":"BALATON Zoltan ","To":"Chad Jablonski ","cc":"qemu-devel@nongnu.org, Gerd Hoffmann ,\n\t=?iso-8859-15?q?Marc-Andr=E9_Lureau?= ","Subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","In-Reply-To":"<20260417205752.3932801-1-chad@jablonski.xyz>","Message-ID":"<58180aa1-4e39-4aa8-6d3b-586d4461deba@eik.bme.hu>","References":"<20260417205752.3932801-1-chad@jablonski.xyz>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII; format=flowed","Received-SPF":"pass client-ip=2001:738:2001:2001::2001;\n envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu","X-Spam_score_int":"-18","X-Spam_score":"-1.9","X-Spam_bar":"-","X-Spam_report":"(-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3678972,"web_url":"http://patchwork.ozlabs.org/comment/3678972/","msgid":"","list_archive_url":null,"date":"2026-04-18T13:12:43","subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","submitter":{"id":91805,"url":"http://patchwork.ozlabs.org/api/people/91805/","name":"Chad Jablonski","email":"chad@jablonski.xyz"},"content":">\n> I guess this is to fix chars not appearing in xterm when a virtual desktop \n> is panned that you noticed here?\n> https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg00785.html\n>\n\nYep! I should have mentioned this.\n\n>> The second is that a bounds check was also being performed to ensure\n>> that the dirty memory was within the visible screen. With the virtual\n>> desktop this isn't actually what we want. Updates can and will happen\n>> outside of the visible screen area. Those should be marked dirty.\n>\n> But I still think only the visible area should need marking dirty because it \n> is used to update display so marking non visible parts should have no \n> effect. I'm not sure if it has any performance impact but just seems \n> unnecessary so that's why this tried to limit it to visible area. I've \n> added to cc some people who could maybe enlighten us on this.\n>\n\nAfter digging into this deeper I think you're right that the\nnon-visible dirty marking isn't necessary. Looking at vga_draw_graphic\nin hw/display/vga.c it looks like anytime the screen pans, a full screen\nupdate is triggered. But from what I can tell the full screen update doesn't\nclear the dirty map. Only partial updates do that. So setting non-visible\nregions dirty could cause the non-visible regions to be updated later\nwhen it isn't necessary. Meaning the user could pan over the region, do\nan unrelated blit and the stale dirty regions would also be updated. I'm\nnot sure what sort of perfomance implications this has though.\n\nI think if we want to avoid this the way to do it may be to just take\nthe intersection of the currently visible screen area and the\ndestination area and mark just that as dirty. Even fixing the unit issue\nthe old bounds check would miss blits that began outside of the visible\nscreen and continued onto the visible screen.\n\nAnother thought, we could clear dirty bits on full screen updates. But\nthat's a change with a much larger blast radius and I would be nervous to\nmake it.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=jablonski.xyz header.i=@jablonski.xyz\n header.a=rsa-sha256 header.s=fm1 header.b=AWKgBhzv;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm2 header.b=mCDWqpnm;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fyXHS732Hz1yGt\n\tfor ; Sat, 18 Apr 2026 23:13:07 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wE5Te-00024o-H3; Sat, 18 Apr 2026 09:12:50 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wE5Tc-00024P-Pk\n for qemu-devel@nongnu.org; Sat, 18 Apr 2026 09:12:49 -0400","from fhigh-a6-smtp.messagingengine.com ([103.168.172.157])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wE5Ta-0002aC-OY\n for qemu-devel@nongnu.org; Sat, 18 Apr 2026 09:12:48 -0400","from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])\n by mailfhigh.phl.internal (Postfix) with ESMTP id DF65C140007E;\n Sat, 18 Apr 2026 09:12:45 -0400 (EDT)","from phl-frontend-03 ([10.202.2.162])\n by phl-compute-06.internal (MEProxy); Sat, 18 Apr 2026 09:12:45 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Sat,\n 18 Apr 2026 09:12:44 -0400 (EDT)","from localhost (chomposaur [local])\n by chomposaur (OpenSMTPD) with ESMTPA id e838d967;\n Sat, 18 Apr 2026 13:12:43 +0000 (UTC)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=jablonski.xyz;\n h=cc:cc:content-transfer-encoding:content-type:content-type\n :date:date:from:from:in-reply-to:in-reply-to:message-id\n :mime-version:references:reply-to:subject:subject:to:to; s=fm1;\n t=1776517965; x=1776604365; bh=+9GK8TIa0RGJkfNThVKDhbJKrFGv1bXO\n aXXF8PWoFRw=; b=AWKgBhzvC3Wr/PG9d36gpNu2HiNSJZYlk7PxalCwxhYmp7Rg\n NkHRy2h3mNi/Z64kgGkwV/rn0hnWAZ+cYxnxRYaaNdv4eee2d1G59cO/oJcXbXfu\n PVfX1wx9AF1qcr0BPT8CE0jXLosgpPMpvrdbcSisnyWbyDirpkL0tNnQJBhELdJm\n DIAOyWffAIiVmSrxoGUrh2zaa05OOrxKtGLkaAFDmhlJPusENGU477TfLOD2hJd6\n G+cSCYz9s910tjXbm0DToQlg0lpeyIadgj5ZrAWlerzcin9NXtg5u+rq6MPccsiw\n IqdfbJCGxhBNNTwIwVWZ7w2WqR7rrWfwAAKBFA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n messagingengine.com; h=cc:cc:content-transfer-encoding\n :content-type:content-type:date:date:feedback-id:feedback-id\n :from:from:in-reply-to:in-reply-to:message-id:mime-version\n :references:reply-to:subject:subject:to:to:x-me-proxy\n :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1776517965; x=\n 1776604365; bh=+9GK8TIa0RGJkfNThVKDhbJKrFGv1bXOaXXF8PWoFRw=; b=m\n CDWqpnmyh5gDojPzRMCCn95S4sMZ1y8VRQCl9+fdALjEldXsW9R7wQY2PhviVxNM\n 0k2vrdc8BofjR5a/ZzGKL457TlRXDd14e5qSAtkpmypGVXbF/c2Jl+cyZEGujrF3\n 5/dkg5KZhWJhmEGrsQidL8ueK8cSD2UrDzZn/kdRoYp9kd+JqukfhJpTRLaf/N3C\n jKTlYjt2XD5YnqBzlM0LPQSlJz8bsf3zKbVMwqmiZ1v4VLtvh2nsSET14ZBVFoGe\n 39R+kW+mIq3XfExR78YXkvvK6oWIhuZpLPoO+DrTthH+i3++J7GwZjkc3zUDRmwt\n ibfk9jjmETu8RaHNbYrNA=="],"X-ME-Sender":"\n ","X-ME-Received":"\n ","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdehvdekhecutefuodetggdotefrod\n ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr\n ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlh\n cuvffnffculdefhedmnecujfgurhepggfgtgffkfevuffhvffofhgjsehtqhertdertdej\n necuhfhrohhmpedfvehhrgguucflrggslhhonhhskhhifdcuoegthhgrugesjhgrsghloh\n hnshhkihdrgiihiieqnecuggftrfgrthhtvghrnhepudduhfeivdevudfftddvgfeitdfh\n heduteethefgkefggeefhfehfefghfetteehnecuffhomhgrihhnpehnohhnghhnuhdroh\n hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegt\n hhgrugesjhgrsghlohhnshhkihdrgiihiidpnhgspghrtghpthhtohephedpmhhouggvpe\n hsmhhtphhouhhtpdhrtghpthhtohepmhgrrhgtrghnughrvgdrlhhurhgvrghusehrvggu\n hhgrthdrtghomhdprhgtphhtthhopehqvghmuhdquggvvhgvlhesnhhonhhgnhhurdhorh\n hgpdhrtghpthhtoheptghhrggusehjrggslhhonhhskhhirdighiiipdhrtghpthhtohep\n sggrlhgrthhonhesvghikhdrsghmvgdrhhhupdhrtghpthhtohepkhhrrgigvghlsehrvg\n guhhgrthdrtghomh","X-ME-Proxy":"\n \n \n \n ","Feedback-ID":"ib26944c1:Fastmail","Mime-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","Content-Type":"text/plain; charset=UTF-8","Date":"Sat, 18 Apr 2026 09:12:43 -0400","Message-Id":"","Cc":", \"Gerd Hoffmann\" ,\n\t=?utf-8?q?Marc-Andr=C3=A9_Lureau?= ","Subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","From":"\"Chad Jablonski\" ","To":"\"BALATON Zoltan\" , \"Chad Jablonski\"\n ","X-Mailer":"aerc 0.21.0","References":"<20260417205752.3932801-1-chad@jablonski.xyz>\n <58180aa1-4e39-4aa8-6d3b-586d4461deba@eik.bme.hu>","In-Reply-To":"<58180aa1-4e39-4aa8-6d3b-586d4461deba@eik.bme.hu>","Received-SPF":"pass client-ip=103.168.172.157;\n envelope-from=chad@jablonski.xyz;\n helo=fhigh-a6-smtp.messagingengine.com","X-Spam_score_int":"-2","X-Spam_score":"-0.3","X-Spam_bar":"/","X-Spam_report":"(-0.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n FROM_SUSPICIOUS_NTLD=0.498, PDS_OTHER_BAD_TLD=1.997, RCVD_IN_DNSWL_LOW=-0.7,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,\n UNPARSEABLE_RELAY=0.001 autolearn=no autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3678975,"web_url":"http://patchwork.ozlabs.org/comment/3678975/","msgid":"","list_archive_url":null,"date":"2026-04-18T14:56:12","subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","submitter":{"id":16148,"url":"http://patchwork.ozlabs.org/api/people/16148/","name":"BALATON Zoltan","email":"balaton@eik.bme.hu"},"content":"On Sat, 18 Apr 2026, Chad Jablonski wrote:\n>> I guess this is to fix chars not appearing in xterm when a virtual desktop\n>> is panned that you noticed here?\n>> https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg00785.html\n>>\n>\n> Yep! I should have mentioned this.\n>\n>>> The second is that a bounds check was also being performed to ensure\n>>> that the dirty memory was within the visible screen. With the virtual\n>>> desktop this isn't actually what we want. Updates can and will happen\n>>> outside of the visible screen area. Those should be marked dirty.\n>>\n>> But I still think only the visible area should need marking dirty because it\n>> is used to update display so marking non visible parts should have no\n>> effect. I'm not sure if it has any performance impact but just seems\n>> unnecessary so that's why this tried to limit it to visible area. I've\n>> added to cc some people who could maybe enlighten us on this.\n>>\n>\n> After digging into this deeper I think you're right that the\n> non-visible dirty marking isn't necessary. Looking at vga_draw_graphic\n> in hw/display/vga.c it looks like anytime the screen pans, a full screen\n> update is triggered. But from what I can tell the full screen update doesn't\n> clear the dirty map. Only partial updates do that. So setting non-visible\n> regions dirty could cause the non-visible regions to be updated later\n> when it isn't necessary. Meaning the user could pan over the region, do\n> an unrelated blit and the stale dirty regions would also be updated. I'm\n> not sure what sort of perfomance implications this has though.\n>\n> I think if we want to avoid this the way to do it may be to just take\n> the intersection of the currently visible screen area and the\n> destination area and mark just that as dirty.\n\nThat could work but maybe we also have problems with calculating \nintersects. The ATI docs say SC values can be negative (Range -8192 to \n8191) but we don't seem to handle that correctly. I don't know if any \ndrivers use negative values in scissor clipping, I've only noticed it when \nchecking with different values so maybe that's not be a problem in common \ncases.\n\n> Even fixing the unit issue\n> the old bounds check would miss blits that began outside of the visible\n> screen and continued onto the visible screen.\n\nMaybe this is the real reason but I still don't see how a relatively small \nblit of one character in a fully visible xterm not even near the left of \nscreen could be missed this way if the screen is panned so I'm still \nsuspecting clipping might have something to do with this. Not marking out \nof screen updates also does not explain that so it's probably just wrong \ncalculation of visible area. Or you meant that's just another way the \ncurrent calculation could miss updates. Yes that's possible.\n\n> Another thought, we could clear dirty bits on full screen updates. But\n> that's a change with a much larger blast radius and I would be nervous to\n> make it.\n\nCan we invalidate dirty rect in ati_vga_set_offset to avoid changing vga?\n\nRegards,\nBALATON Zoltan","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fyZbW3lgGz1yGt\n\tfor ; Sun, 19 Apr 2026 00:57:09 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wE75s-0002qK-A7; Sat, 18 Apr 2026 10:56:24 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wE75p-0002q6-SO\n for qemu-devel@nongnu.org; Sat, 18 Apr 2026 10:56:21 -0400","from zero.eik.bme.hu ([152.66.115.2])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wE75n-00081z-4V\n for qemu-devel@nongnu.org; Sat, 18 Apr 2026 10:56:21 -0400","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id DA74C59695A;\n Sat, 18 Apr 2026 16:56:14 +0200 (CEST)","from zero.eik.bme.hu ([127.0.0.1])\n by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP\n id hnCA4D5JcORX; Sat, 18 Apr 2026 16:56:12 +0200 (CEST)","by zero.eik.bme.hu (Postfix, from userid 432)\n id 4CF92596958; Sat, 18 Apr 2026 16:56:12 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id 4AFAA596957;\n Sat, 18 Apr 2026 16:56:12 +0200 (CEST)"],"X-Virus-Scanned":"amavis at eik.bme.hu","Date":"Sat, 18 Apr 2026 16:56:12 +0200 (CEST)","From":"BALATON Zoltan ","To":"Chad Jablonski ","cc":"qemu-devel@nongnu.org, Gerd Hoffmann ,\n\t=?iso-8859-15?q?Marc-Andr=E9_Lureau?= ","Subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","In-Reply-To":"","Message-ID":"","References":"<20260417205752.3932801-1-chad@jablonski.xyz>\n <58180aa1-4e39-4aa8-6d3b-586d4461deba@eik.bme.hu>\n ","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII; format=flowed","Received-SPF":"pass client-ip=152.66.115.2; envelope-from=balaton@eik.bme.hu;\n helo=zero.eik.bme.hu","X-Spam_score_int":"-18","X-Spam_score":"-1.9","X-Spam_bar":"-","X-Spam_report":"(-1.9 / 5.0 requ) BAYES_00=-1.9,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3679433,"web_url":"http://patchwork.ozlabs.org/comment/3679433/","msgid":"<6d7f3031-225b-31d9-dcca-45e34ba61783@eik.bme.hu>","list_archive_url":null,"date":"2026-04-20T14:56:54","subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","submitter":{"id":16148,"url":"http://patchwork.ozlabs.org/api/people/16148/","name":"BALATON Zoltan","email":"balaton@eik.bme.hu"},"content":"On Sat, 18 Apr 2026, Chad Jablonski wrote:\n>> I guess this is to fix chars not appearing in xterm when a virtual desktop\n>> is panned that you noticed here?\n>> https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg00785.html\n>>\n>\n> Yep! I should have mentioned this.\n>\n>>> The second is that a bounds check was also being performed to ensure\n>>> that the dirty memory was within the visible screen. With the virtual\n>>> desktop this isn't actually what we want. Updates can and will happen\n>>> outside of the visible screen area. Those should be marked dirty.\n>>\n>> But I still think only the visible area should need marking dirty because it\n>> is used to update display so marking non visible parts should have no\n>> effect. I'm not sure if it has any performance impact but just seems\n>> unnecessary so that's why this tried to limit it to visible area. I've\n>> added to cc some people who could maybe enlighten us on this.\n>>\n>\n> After digging into this deeper I think you're right that the\n> non-visible dirty marking isn't necessary. Looking at vga_draw_graphic\n\nI've found a case which this patch seems to fix and does not involve \npanning (unfortunately I can't give a reproducer as it is with AmigaOS \nthat isn't free) but I don't understand why and what exactly happens. \nMaybe updates are missed when guest updates display by directly writing to \nVRAM? But such writes should cause region to become dirty due to \nvga_dirty_log_start() called at the end of vga_common_init() which we call \nfrom ati_vga_realize(). Without this patch after a mode change display is \nonly updated around the mouse where it's explicitely marked dirty (with \nguest_hwcursor=on as guest_hwcursor=off is bugged) but with this patch \nupdates correctly but I don't know if it's just a side effect or actual \nfix for something. Maybe it's just the calculation fix and not the off \nscreen dirty marking part, I haven't try to test it with restricting to \nvisible screen (maybe I wait for v2 of the patch).\n\nRegards,\nBALATON Zoltan","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fzpVs4xkbz1yD4\n\tfor ; Tue, 21 Apr 2026 00:57:25 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wEq3c-0002QC-As; Mon, 20 Apr 2026 10:57:04 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wEq3b-0002Q2-1Q\n for qemu-devel@nongnu.org; Mon, 20 Apr 2026 10:57:03 -0400","from zero.eik.bme.hu ([2001:738:2001:2001::2001])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wEq3Y-0007BP-Cd\n for qemu-devel@nongnu.org; Mon, 20 Apr 2026 10:57:02 -0400","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id B2C2559695E;\n Mon, 20 Apr 2026 16:56:56 +0200 (CEST)","from zero.eik.bme.hu ([127.0.0.1])\n by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP\n id fCh5aPBl7rE6; Mon, 20 Apr 2026 16:56:54 +0200 (CEST)","by zero.eik.bme.hu (Postfix, from userid 432)\n id 5CEF959695D; Mon, 20 Apr 2026 16:56:54 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n by zero.eik.bme.hu (Postfix) with ESMTP id 5B3B159695B;\n Mon, 20 Apr 2026 16:56:54 +0200 (CEST)"],"X-Virus-Scanned":"amavis at eik.bme.hu","Date":"Mon, 20 Apr 2026 16:56:54 +0200 (CEST)","From":"BALATON Zoltan ","To":"Chad Jablonski ","cc":"qemu-devel@nongnu.org, Gerd Hoffmann ,\n\t=?iso-8859-15?q?Marc-Andr=E9_Lureau?= ","Subject":"Re: [PATCH] ati-vga: fix ati_set_dirty address calculation","In-Reply-To":"","Message-ID":"<6d7f3031-225b-31d9-dcca-45e34ba61783@eik.bme.hu>","References":"<20260417205752.3932801-1-chad@jablonski.xyz>\n <58180aa1-4e39-4aa8-6d3b-586d4461deba@eik.bme.hu>\n ","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII; format=flowed","Received-SPF":"pass client-ip=2001:738:2001:2001::2001;\n envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu","X-Spam_score_int":"-18","X-Spam_score":"-1.9","X-Spam_bar":"-","X-Spam_report":"(-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]