Message ID | 20250121-yuv-v16-3-a61f95a99432@bootlin.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | drm/vkms: Add support for YUV and DRM_FORMAT_R* | expand |
Hi Louis, Thanks a lot for the patches. I'm not well versed in YUV color formats, so I did my best reading the kernel documentation before reviewing this series... But I'll most likely ask some basic/dump questions. > From: Arthur Grillo <arthurgrillo@riseup.net> > > VKMS has support for YUV formats now. Remove the task from the TODO > list. > > Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> > --- > Documentation/gpu/vkms.rst | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > index ba04ac7c2167a9d484c54c69a09a2fb8f2d9c0aa..13b866c3617cd44043406252d3caa912c931772f 100644 > --- a/Documentation/gpu/vkms.rst > +++ b/Documentation/gpu/vkms.rst > @@ -122,8 +122,7 @@ There's lots of plane features we could add support for: > > - Scaling. > > -- Additional buffer formats, especially YUV formats for video like NV12. > - Low/high bpp RGB formats would also be interesting. > +- Additional buffer formats. Low/high bpp RGB formats would be interesting. I see that you implemented support for 6 DRM_FORMAT_NV* formats, but DRM_FORMAT_NV15, DRM_FORMAT_NV20 and DRM_FORMAT_NV30 are not implemented. The same applies to DRM_FORMAT_Y210 or DRM_FORMAT_YUV410 among others. Could it be useful to implement all of them in the future? If so, should we add it to the ToDo list? It might be a great task to get started in kernel development, as there are already similar examples and tests. > > - Async updates (currently only possible on cursor plane using the legacy > cursor api). >
On 31/01/25 - 09:40, José Expósito wrote: > Hi Louis, > > Thanks a lot for the patches. > > I'm not well versed in YUV color formats, so I did my best reading the kernel > documentation before reviewing this series... But I'll most likely ask some > basic/dump questions. > > > From: Arthur Grillo <arthurgrillo@riseup.net> > > > > VKMS has support for YUV formats now. Remove the task from the TODO > > list. > > > > Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> > > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> > > --- > > Documentation/gpu/vkms.rst | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > > index ba04ac7c2167a9d484c54c69a09a2fb8f2d9c0aa..13b866c3617cd44043406252d3caa912c931772f 100644 > > --- a/Documentation/gpu/vkms.rst > > +++ b/Documentation/gpu/vkms.rst > > @@ -122,8 +122,7 @@ There's lots of plane features we could add support for: > > > > - Scaling. > > > > -- Additional buffer formats, especially YUV formats for video like NV12. > > - Low/high bpp RGB formats would also be interesting. > > +- Additional buffer formats. Low/high bpp RGB formats would be interesting. > > I see that you implemented support for 6 DRM_FORMAT_NV* formats, but > DRM_FORMAT_NV15, DRM_FORMAT_NV20 and DRM_FORMAT_NV30 are not implemented. > > The same applies to DRM_FORMAT_Y210 or DRM_FORMAT_YUV410 among others. > > Could it be useful to implement all of them in the future? If so, should we add > it to the ToDo list? I don't think we need "all of them" (there are ≈100 + all the modifiers), but definitly all the commonly used ones (I have some of the "common" one ready here [1], I just wait for the YUV series to be accepted to avoid conflicts). > It might be a great task to get started in kernel development, as there are > already similar examples and tests. I don't think we need to specify which format are missing, the point "Additionnal buffer formats. [...]" seems sufficient. If you think this is relevant, I can add "Easy task" so beginners will find it easier? [1]:https://lore.kernel.org/all/20241122-b4-new-color-formats-v3-0-23f7776197c9@bootlin.com/ > > > > - Async updates (currently only possible on cursor plane using the legacy > > cursor api). > >
On Fri, Jan 31, 2025 at 02:02:14PM +0100, Louis Chauvet wrote: > On 31/01/25 - 09:40, José Expósito wrote: > > Hi Louis, > > > > Thanks a lot for the patches. > > > > I'm not well versed in YUV color formats, so I did my best reading the kernel > > documentation before reviewing this series... But I'll most likely ask some > > basic/dump questions. > > > > > From: Arthur Grillo <arthurgrillo@riseup.net> > > > > > > VKMS has support for YUV formats now. Remove the task from the TODO > > > list. > > > > > > Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> > > > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> > > > --- > > > Documentation/gpu/vkms.rst | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > > > index ba04ac7c2167a9d484c54c69a09a2fb8f2d9c0aa..13b866c3617cd44043406252d3caa912c931772f 100644 > > > --- a/Documentation/gpu/vkms.rst > > > +++ b/Documentation/gpu/vkms.rst > > > @@ -122,8 +122,7 @@ There's lots of plane features we could add support for: > > > > > > - Scaling. > > > > > > -- Additional buffer formats, especially YUV formats for video like NV12. > > > - Low/high bpp RGB formats would also be interesting. > > > +- Additional buffer formats. Low/high bpp RGB formats would be interesting. > > > > I see that you implemented support for 6 DRM_FORMAT_NV* formats, but > > DRM_FORMAT_NV15, DRM_FORMAT_NV20 and DRM_FORMAT_NV30 are not implemented. > > > > The same applies to DRM_FORMAT_Y210 or DRM_FORMAT_YUV410 among others. > > > > Could it be useful to implement all of them in the future? If so, should we add > > it to the ToDo list? > > I don't think we need "all of them" (there are ≈100 + all the modifiers), > but definitly all the commonly used ones (I have some of the "common" one > ready here [1], I just wait for the YUV series to be accepted to avoid > conflicts). Good to know, thanks for the clarification. I think we are good with this to-do item as it is. There's plenty of work that can be done :) Jose > > It might be a great task to get started in kernel development, as there are > > already similar examples and tests. > > I don't think we need to specify which format are missing, the point > "Additionnal buffer formats. [...]" seems sufficient. If you think this is > relevant, I can add "Easy task" so beginners will find it easier? > > [1]:https://lore.kernel.org/all/20241122-b4-new-color-formats-v3-0-23f7776197c9@bootlin.com/ > > > > > > > - Async updates (currently only possible on cursor plane using the legacy > > > cursor api). > > >
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index ba04ac7c2167a9d484c54c69a09a2fb8f2d9c0aa..13b866c3617cd44043406252d3caa912c931772f 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -122,8 +122,7 @@ There's lots of plane features we could add support for: - Scaling. -- Additional buffer formats, especially YUV formats for video like NV12. - Low/high bpp RGB formats would also be interesting. +- Additional buffer formats. Low/high bpp RGB formats would be interesting. - Async updates (currently only possible on cursor plane using the legacy cursor api).