Hi Piotr, On Fri, 15 Apr 2022 at 12:11, Piotr Oniszczuk <piotr.oniszczuk@xxxxxxxxx> wrote: > 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... I bet if you dumped the gbm_surface format (passed by Qt as a parameter to gbm_surface_create_with_modifiers or gbm_surface_create) and the EGLConfig's EGL_NATIVE_VISUAL_ID (from eglQueryConfig), you would see that the format tokens are different. Which is a Qt coding error. > 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 (*)) I disagree. I looked at a clone of Qt, and I could not see a coherent path that ensured that the gbm_surface format chosen by Qt matched the EGLConfig format used on that EGLSurface. A mismatch is an error. There are some workarounds allowing you to specify a format, however those only work by coincidence sometimes. Even with the explicit format specification, Qt never makes any attempt to match gbm_surface and EGLConfig formats; it just hopes that they will match by coincidence. There is no additional complexity or strangeness that RK356x is introducing here. It only works by pure luck on other platforms. > 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 Unfortunately there is no reasonable workaround outside of Qt. Looking at the Qt/QPA source tree, it looks like the usual way of 'fixing' this is to hack platform specific configuration into the Qt backend. If Qt won't be fixed to use generic APIs correctly, then I guess your best option is to just hack up yet another platform-specific backend. Which is a shame, but there is no reasonable workaround we can do in low-level code for toolkits doing the wrong thing and hoping it works. Cheers, Daniel
