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

Hi Michael,

On Fri, 11 Sept 2026 at 06:53, Michael Schmitz [off-list ref] wrote:

Am 08.09.2026 um 19:18 schrieb Geert Uytterhoeven:

quoted

quoted

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 ;-)

Sorry, I don't get that - are the console colors chosen judiciously to
allow for that?

Sorry, I don't remember if we still do that.

quoted

quoted

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.

I wasn't worried about performance as the blitter takes care of most of
the work (though we may schedule away from svblit_fillrect() while the
blitter is active). Getting the 'simple byte loop' right is more
important. My sample code got everything wrong in fact.

There's a reason why we don't work with 24 bit sized objects usually,
and probably a reason why 24 bpp was never implemented for the
SuperVidel :-)

Yeah, 24bpp is tricky.  And in this case we don't even have to deal with a
different endianness ;-)

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