<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> </head> <body> <div class="moz-cite-prefix">On 18.09.2020 09:53, Pekka Paalanen wrote: </div> <blockquote type="cite" cite="mid:20200918105321.63d4642b@eldfell"> <pre class="moz-quote-pre" wrap="">On Thu, 17 Sep 2020 19:10:53 +0200 Maciej Pijanowski <a class="moz-txt-link-rfc2396E" href="mailto:maciej.pijanowski@3mdeb.com"><maciej.pijanowski@3mdeb.com></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On 10.09.2020 16:32, Maciej Pijanowski wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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: [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) RPi: [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) I've changed the format on the RPi ARGB8888 and it still works fine. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Hi, that is some good debugging you did. See this: $ git ngrep -p -A 3 read_pixels\( compositor/screen-share.c=817=shared_output_repainted(struct wl_listener *listener, void *data) -- compositor/screen-share.c:882: so->output->compositor->renderer->read_pixels( compositor/screen-share.c-883- so->output, PIXMAN_a8r8g8b8, so->tmp_data, compositor/screen-share.c-884- x, y_orig, width, height); compositor/screen-share.c-885- libweston/screenshooter.c=110=screenshooter_frame_notify(struct wl_listener *listener, void *data) -- libweston/screenshooter.c:131: compositor->renderer->read_pixels(output, libweston/screenshooter.c-132- compositor->read_format, pixels, libweston/screenshooter.c-133- 0, 0, output->current_mode->width, libweston/screenshooter.c-134- output->current_mode->height); -- libweston/screenshooter.c=262=weston_recorder_frame_notify(struct wl_listener *listener, void *data) -- libweston/screenshooter.c:321: compositor->renderer->read_pixels(output, libweston/screenshooter.c-322- compositor->read_format, recorder->rect, libweston/screenshooter.c-323- r[i].x1, y_orig, width, height); libweston/screenshooter.c-324- -- tests/weston-test.c=431=test_screenshot_frame_notify(struct wl_listener *listener, void *data) -- tests/weston-test.c:454: compositor->renderer->read_pixels(output, tests/weston-test.c-455- compositor->read_format, tests/weston-test.c-456- pixels, tests/weston-test.c-457- 0, 0, Notice how screen-share is using a hard-coded pixel format, but every other caller is using compositor->read_format. compositor->read_format is determined in gl_renderer_setup() based on the availability of GL_EXT_read_format_bgra. Also pixman_renderer_output_set_buffer() sets it if you happen to be using Pixman-renderer instead. So, screen-share needs to start using compositor->read_format instead of hard-coding.</pre> </blockquote> We will try to fix that according to suggestion and submit a patch. Thanks, <blockquote type="cite" cite="mid:20200918105321.63d4642b@eldfell"> <pre class="moz-quote-pre" wrap=""> Thanks, pq </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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">https://lists.freedesktop.org/archives/wayland-devel/2019-April/040382.html</a> -- Maciej Pijanowski Embedded Systems Engineer GPG: 9963C36AAC3B2B46 <a class="moz-txt-link-freetext" href="https://3mdeb.com">https://3mdeb.com</a> | @3mdeb_com _______________________________________________ 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-quote-pre" wrap=""> </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </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>