weston rdp black screen

Pekka Paalanen ppaalanen at gmail.com
Fri Sep 18 07:53:21 UTC 2020


On Thu, 17 Sep 2020 19:10:53 +0200
Maciej Pijanowski <maciej.pijanowski at 3mdeb.com> wrote:

> On 10.09.2020 16:32, Maciej Pijanowski wrote:
> >
> > 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.
> >  
> 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.

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.


Thanks,
pq


> 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]
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/compositor/screen-share.c#L888
> [3]
> https://github.com/3mdeb/weston/blob/use_GL_RGBA/libweston/renderer-gl/gl-renderer.c#L1551
> [4] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/36
> [5]
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/362#note_623870
> 
> >
> > 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]
> > https://lists.freedesktop.org/archives/wayland-devel/2019-April/040382.html
> >
> > -- 
> > Maciej Pijanowski
> > Embedded Systems Engineer
> > GPG: 9963C36AAC3B2B46
> > https://3mdeb.com | @3mdeb_com
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel  
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200918/e3788ed2/attachment-0001.sig>


More information about the wayland-devel mailing list