<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 10.09.2020 16:32, Maciej Pijanowski wrote: </div> <blockquote type="cite" cite="mid:90de6506-9e7f-3994-253a-2fa72c564699@3mdeb.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> Hello, I'm having exactly the same issue as described in the [1]. I have a custom Yocto build running on the embedded board with Mali GPU. Mali GPU was also used in the mentioned thread. So maybe there is something in common. When RDP backend is used as a main backend (in the core section) I can see the screen content in the RDP client. When the core backend is DRM and the RDP is started via the screen-share plugin, I can only see the black screen in the RDP client (although the input works correctly). I tried running the same combination on Fedora VM or on the RPi4 and in those cases the screen-share works correctly with RDP. I've been looking for some differences in the logs between those setups. I have noticed the EGL config in case of Mali to be different than in case of the other ones. Mali: <pre class="code highlight" lang="markdown"> [07:24:23.919] Bad/unknown DRM format code 0x00000000. [07:24:23.919] Unable to use first choice EGL config with XRGB8888, succeeded with alternate ARGB8888. ... [07:24:23.923] GL version: OpenGL ES 2.0 "fa33ed7" [07:24:23.923] GLSL version: OpenGL ES GLSL ES 1.00 [07:24:23.923] GL vendor: ARM [07:24:23.923] GL renderer: Mali-400 MP ... [07:24:24.006] Chosen EGL config details: id: 9 rgba: 8 8 8 8 buf: 32 dep: 24 stcl: 8 int: 0-10 type: win|pix|pbf|swap_preserved vis_id: ARGB8888 (0x34325241) </pre> RPi: <pre class="code highlight" lang="markdown"> [07:04:41.917] GL version: OpenGL ES 3.1 Mesa 20.0.2 [07:04:41.917] GLSL version: OpenGL ES GLSL ES 3.10 [07:04:41.917] GL vendor: Broadcom [07:04:41.917] GL renderer: V3D 4.2 ... [07:04:42.032] Chosen EGL config details: id: 17 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8888 (0x34325258) </pre> I've changed the format on the RPi ARGB8888 and it still works fine. </blockquote> So I've been investigating this issue further. I've checked for the pixeldata here [2] and in the cases with the black screen there was nothing dumped. I have traced it further back to the glReadPixels call [3]. Once I switched the pixel format to the PIXMAN_a8b8g8r8 (gl_format to GL_RGBA) it started to work correctly. Both VNC [4] and RDP backends now work fine with the screen-share on platform with Mali GPU and libMali blob. As I got this working, I could just patch the code to use the given pixel format. But I would prefer to fix things upstream. Any hints on what would be "the proper" way of fixing this issue are welcome. I also added Stefan Agner to CC as he was changing this part of the code lately in screen-share and we were discussing this matter in [5]. I hope this is fine. Thanks, [2] <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/wayland/weston/-/blob/master/compositor/screen-share.c#L888">https://gitlab.freedesktop.org/wayland/weston/-/blob/master/compositor/screen-share.c#L888</a> [3] <a class="moz-txt-link-freetext" href="https://github.com/3mdeb/weston/blob/use_GL_RGBA/libweston/renderer-gl/gl-renderer.c#L1551">https://github.com/3mdeb/weston/blob/use_GL_RGBA/libweston/renderer-gl/gl-renderer.c#L1551</a> [4] <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/36">https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/36</a> [5] <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/362#note_623870">https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/362#note_623870</a> <blockquote type="cite" cite="mid:90de6506-9e7f-3994-253a-2fa72c564699@3mdeb.com"> One more observation - if I forced the DRM backend to use the pixman renderer (by adding the use-pixman=true in the weston.ini), the cloned content appeared correctly in the RDP client. Of course the performance and usability dropped, as the GPU was no longer used for rendering. It clearly suggests that the problem is somewhere around the Mali library. Any suggestions how to approach further debugging of these kind of issues are highly appreciated. Thank you [1] <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/archives/wayland-devel/2019-April/040382.html" moz-do-not-send="true">https://lists.freedesktop.org/archives/wayland-devel/2019-April/040382.html</a> <pre class="moz-signature" cols="72">-- Maciej Pijanowski Embedded Systems Engineer GPG: 9963C36AAC3B2B46 <a class="moz-txt-link-freetext" href="https://3mdeb.com" moz-do-not-send="true">https://3mdeb.com</a> | @3mdeb_com</pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Maciej Pijanowski Embedded Systems Engineer GPG: 9963C36AAC3B2B46 <a class="moz-txt-link-freetext" href="https://3mdeb.com">https://3mdeb.com</a> | @3mdeb_com</pre> </body> </html>