linux-kernel - Re: [PATCH 0/2] Better support for complex pixel formats

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7959499-c0cf-4454-b9f9-8436d8818095@igalia.com>
Date: Thu, 1 Feb 2024 19:07:43 -0300
From: Maira Canal <mcanal@...lia.com>
To: Louis Chauvet <louis.chauvet@...tlin.com>,
 Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>,
 Melissa Wen <melissa.srw@...il.com>, Maíra Canal
 <mairacanal@...eup.net>, Haneen Mohammed <hamohammed.sa@...il.com>,
 Daniel Vetter <daniel@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, marcheu@...gle.com, seanpaul@...gle.com,
 nicolejadeyee@...gle.com
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 thomas.petazzoni@...tlin.com, miquel.raynal@...tlin.com
Subject: Re: [PATCH 0/2] Better support for complex pixel formats

Hi Louis,

Thanks for your patches! Could you please rebase them on top of
drm-misc-next? It would make it easier for me to review and test the
patches.

Best Regards,
- Maíra

On 2/1/24 14:31, Louis Chauvet wrote:
> This patchset aims to solve issues I found in [1], and at the same time
> simplify the composition algorithm.
> 
> I sent more igt-gpu-tools test [2] to cover more things and detect the
> issues in [1].
> 
> This patchset is based on [1].
> 
> Patch 1/2: This patch is a no-op, but make the code more readable
> regarding the pixel_read functions.
> 
> Patch 2/2: This patch is more complex. My main target was to solve issues
> I found in [1], but as it was very complex to do it "in place", I choose
> to rework the composition function.
> The main two advantages are:
> - It's now possible to create conversion function for packed & grouped
> pixels. Some pixel formats need absolute x/y position and not only an
> offset in the buffer to extract the correct value. This part also solve
> the issues I found in [1].
> - The rotation management is now way easier to understand, there is no
> more switch case in different places and instead of copy/pasting rotation
> formula I used drm_rect_* helpers.
> 
> [1]: https://lore.kernel.org/dri-devel/20240110-vkms-yuv-v2-0-952fcaa5a193@riseup.net/
> [2]: https://lore.kernel.org/igt-dev/20240201-kms_tests-v1-0-bc34c5d28b3f@bootlin.com/T/#t
> 
> Signed-off-by: Louis Chauvet <louis.chauvet@...tlin.com>
> ---
> Louis Chauvet (2):
>        drm/vkms: Create a type to check a function pointer validity
>        drm/vkms: Use a simpler composition function
> 
>   drivers/gpu/drm/vkms/vkms_composer.c |  97 ++++++++-----
>   drivers/gpu/drm/vkms/vkms_drv.h      |  32 ++++-
>   drivers/gpu/drm/vkms/vkms_formats.c  | 254 ++++++++++++++++++-----------------
>   drivers/gpu/drm/vkms/vkms_formats.h  |   2 +-
>   drivers/gpu/drm/vkms/vkms_plane.c    |  13 +-
>   5 files changed, 236 insertions(+), 162 deletions(-)
> ---
> base-commit: 5d189d57bb335a87ec38ea26fe43a5f3ed31ced7
> change-id: 20240201-yuv-1337d90d9576
> 
> Best regards,