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

[Piotr Oniszczuk <piotr.oniszczuk@gmail.com>]

> Wiadomość napisana przez Daniel Stone <daniel@fooishbar.org> w dniu 12.04.2022, o godz. 13:30:
> 
>> Testing Sacha patch (see today's email from Sascha) i'm getting
>> 
>> Qt: EGL Error : Could not create the egl surface: error = 0x3009
>> 
>> i'm reading this as: Qt tries allocate EGL surface and EGL returns error.
>> or i'm wrong?
> 
> Correct, that's EGL_BAD_MATCH. There are very few ways that can
> happen; by far the most likely is that Qt has chosen an EGLConfig
> which does not correctly correspond to the format. (If it was an
> impossible format/modifier combination, then this would be already
> caught when allocating the gbm_surface.)
> 
> Either way, it seems quite clear that the VOP2 driver is totally fine
> here, and that you have a Qt (likely) or Mesa (tbh less likely) issue
> to debug to get the app working.
> 
> Cheers,
> Daniel

Thx Daniel!

Indeed - this is probably another case where I see: writing DRM planes rendering mediaplayer with help of Qt is (too)corner case for Qt....


@all

Looking on Qt sources it looks to me this format should be supported:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/kmsconvenience/qkmsdevice.cpp?h=5.15.2#n380

Interesting that with custom Qt config1: "format": "argb8888",
DRI state shows: format=AR24 little-endian (0x34325241)

UI is OK, playback is OK. OSD not visible (*)

custom config2: "format": "abgr8888" 
Qt crashes with EGL_BAD_MATCH

So it looks forcing some Qt formats works while other - not. 

Looking why this:

Qt logging says nothing.
export MESA_DEBUG=1 gives no any message. I'm a lost here a bit...



But from a bit more distant perspective:

1. Sascha concludes in (*) that issue is most probably in format negotiation by app.

2. imho app probably correctly negotiates accordingly to inputs it gets from providers (DRM) and clients (mesa). 
Test with patch excluding
DRM_FORMAT_XRGB8888,
DRM_FORMAT_ARGB8888,
shows imho proper app reaction on this (new format elected; but Qt fails with this format). Indirectly i conclude app logic is ok....

3. Sum of p1 & p2 tells me:
i need to add extra logic in format election to specifically deal with constrains of rk356x (see explanation in (*))
    
4. Even if i implement p3 - then user world - (this using Qt) - will be not happy as:
- majority users are using pre-build Qt
- I don't believe Trolltech will fix this soon

So i see following path:
  
we will verify is issue of Qt with abgr8888 an Qt root cause issue,

If Yes - then:
	- Investigate is there reasonable way to workaround with this outside of Qt?
If not - then:
	- conclude: vop2 - due Qt bug - will not work ok with Qt until Qt will be fixed.

 
If you think this make sense - i need some help with: verify is issue of Qt with abgr8888 an Qt root cause issue

let me know what you think



(*)
Sascha mentioned:
> 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.