Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Wiadomość napisana przez Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> w dniu 12.04.2022, o godz. 09:50:
> 
> 
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR8888 aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB8888 aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
> 
Applied :-)
Results: pls see below

> Could you try the following patch? It removed the formats in question
> from the list of supported formats in the hope that your application
> then picks one of the supported formats.
> 
> Sascha
> 
> -----------------------8<-----------------------------
> 
> From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> Date: Tue, 12 Apr 2022 09:42:32 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> 
> The cluster windows only allow AFBC compressed formats. Not all of the
> offered formats are supported by the GPU though. Applications pick one
> of the formats and assume that this is also supported by the GPU they
> use to render on them, but this is not the case for all formats.
> Particularly DRM_FORMAT_XRGB8888 and DRM_FORMAT_ARGB8888 are not
> supported by the GPU and choosing them results in a black screen.
> Drop these formats for now.
> 
> Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
> 1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 9bf0637bf8e26..38412766e3659 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -16,8 +16,6 @@
> #include "rockchip_drm_vop2.h"
> 
> static const uint32_t formats_win_full_10bit[] = {
> -	DRM_FORMAT_XRGB8888,
> -	DRM_FORMAT_ARGB8888,
> 	DRM_FORMAT_XBGR8888,
> 	DRM_FORMAT_ABGR8888,
> 	DRM_FORMAT_RGB888,
> -- 
> 

With above patch app select expected format (i think):

1970-01-01 01:00:31.074643 I /dev/dri/card0: Authenticated
1970-01-01 01:00:31.189420 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
1970-01-01 01:00:31.189444 I /dev/dri/card0: Selected Plane #37 Overlay for video
1970-01-01 01:00:31.189528 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
1970-01-01 01:00:31.189536 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
1970-01-01 01:00:31.190279 I Wrote /home/minimyth/.mythtv/eglfs_kms_config.json: 
{
"device": "/dev/dri/card0",
"outputs": [ { "name": "HDMI1", "format": "abgr8888", "mode": "current" } ]
}

(file eglfs_kms_config.json is generated by app to configure Qt; it is steep (b) in yesterday's email) 
I see format abgr8888 is now selected by app (this is expected t think)



but later Qt says:

1970-01-01 01:00:34.985215 I Qt: EGL Error : Could not create the egl surface: error = 0x3009
Handling Aborted
Aborted
 
I suspect Qt tries with this format talk to GLES provider - but it wasn't somehow accepted by underlying EGL provider (mesa GLES)?






[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux