Re: [PATCH] fbdev: atafb: Restrict SuperBlitter to supported formats
From: Miro Kropáček <hidden>
Date: 2026-09-07 11:15:09
Also in:
dri-devel, lkml
Hi Linmao, hi Michael, On Sun, 6 Sept 2026 at 11:49, Michael Schmitz [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Hi Linmao, thanks for your patch! Am 27.08.2026 um 21:39 schrieb Linmao Li:quoted
The SuperBlitter operations derive an integer byte count per pixel. The accelerated fill path handles only one-, two- and four-byte pixels. However, the operations are currently installed for every external framebuffer in SuperVidel RAM, including planar 1/2/4/8-bpp and 24-bpp truecolor modes accepted by the external video parser. For 1/2/4-bpp modes, the byte count becomes zero, so accelerated copies do nothing and fills fall through to 32-bit stores. Planar 8-bpp uses an incompatible memory layout. For 24-bpp modes, fills also use 32-bit stores despite advancing addresses by three bytes per pixel. These cases can corrupt the framebuffer beyond the requested rectangle.I believe 24 bpp mode can be rescued using something like this (entirely untested):--- a/drivers/video/fbdev/atafb.c +++ b/drivers/video/fbdev/atafb.c@@ -2463,6 +2463,11 @@ static void svblit_fillrect(struct fb_info *info, case 2: memset16((u16 *)line, pix, rect->width); break; + case 3: + memset(line, pix, ((rect->width * bytespp) % 4)); + line += ((rect->width * bytespp) % 4); + memset32((u32 *)line, pix, (rect->width * bytespp) / 4); + break; default: memset32((u32 *)line, pix, rect->width); break;Can't test this on hardware, and would need Miro to confirm it works as intended.
Linmao's patch: I ran it on a Falcon with SuperVidel at 1920x1080x32bpp, all good. Michael's 24bpp fill: I cannot test it because the SuperVidel has no 24bpp video mode. It was planned but never implemented. Its mode register offers 1/2/4/8-bit bitplane, 8-bit chunky, 16-bit highcolor and 32-bit truecolor (24-bit RGB plus an alpha byte), with the remaining code reserved - and TOS offers no 24bpp mode to set. Unless I overlooked something, the fill also looks wrong on paper: the first line is filled with a repeated byte and then with repeated 32-bit words of the same value, which cannot reproduce a 3-byte pixel pattern unless all three bytes are equal. On the fbset question: no, the pixel format, depth and geometry of an external framebuffer cannot be changed at runtime here. fbset -depth 16 and fbset -xres 1024 -yres 768 both return success and change nothing, because ext_decode_var() only validates against the values from the boot argument, ext_encode_var() re-derives every field from the external_* globals and ext_set_par() is empty. Only a reboot with a different atafb:external: argument changes the mode. -- http://mikro.atari.org