Re: [PATCH] fbdev: atafb: Restrict SuperBlitter to supported formats

Hi Michael,

On Mon, 7 Sept 2026 at 22:14, Michael Schmitz [off-list ref] wrote:

On 7/09/26 23:14, Miro Kropáček wrote:

quoted

On Sun, 6 Sept 2026 at 11:49, Michael Schmitz [off-list ref] wrote:

quoted

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.

Without a 24 bpp mode, the 24 bpp fill is pointless, so no point trying
to keep that mode alive.

quoted

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.

You're correct - we'd need a memset24() to account for that. Without

Unless the frame buffer would be using a DIRECT_COLOR visual (which
is not the case), then you could draw pixels in the 16 console colors
by replicating the color index in all 3 bytes ;-)

hardware support this is an academic exercise that I don't have time for :-)

True. And as this code is used only to fill the first line (the blitter
replicates it into the other lines), the performance difference between
a simple byte loop and a true memset24() won't be that large.


Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds