Hi Am 19.01.24 um 13:25 schrieb Pekka Paalanen:
On Fri, 19 Jan 2024 11:58:38 +0100 Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:Hi Am 17.01.24 um 17:40 schrieb Jocelyn Falempe:...The last thing, is if I plan to add YUV support, with this implementation, I only need to write one function that convert one pixel. Otherwise I would need to add the drm_fb_r1_to_yuvxxx_line() and drm_fb_r1_to_yuvxxxx() boilerplate.8) YUVs are multi-plane formats IIRC. So it's likely a bit more complicated.And I'm not aware of any current use case for YUV. If the framebuffer console doesn't support it, the panic helper probably won't either.Kernel panic during a fullscreen video playback, maybe? That use case is likely to have an YUV FB as the only visible KMS plane FB, either primary or overlay plane depending on which is capable of displaying it. Sub-titles might not exist, or might be in a fairly small RGB overlay. I don't know if such case is important enough to handle.
That's at least a possible use case AFAICT.Each conversion is implemented in a helper drm_fb_<src format>_to_<dst format>(). drm_fb_blit() is just a big switch statement to call the correct helper. Something like drm_r1_to_yuv422() would be no different and would integrate with the existing drm_fb_blit() nicely.
So it appears to me as if it's better to either extend the current code for multi-plane formats, or write custom helpers drm_fb_r1_to_yuv<whatever>().
Best regards Thomas
Thanks, pq
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
