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

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Geert,

Am 08.09.2026 um 19:18 schrieb Geert Uytterhoeven:
>>> 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?

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

Cheers,

	Michael

>
>
> Gr{oetje,eeting}s,
>
>                         Geert
>