weston rdp black screen

[Jean-Francois Dagenais]

> On Apr 12, 2019, at 09:48, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> Hi,
> 
> I believe Mali is the prorietary GPU driver (and a chip family?), so
> something that implements OpenGL.

Yes, there is an ARM made glue kernel module that manifests /dev/mali. Then the
integrator of the MALI GPU (xilinx for example) distributes a binary libMali.so
which implements egl.h, gbm.h, gles (v1 and v2) functions, etc.

Why would screenshots of MALI GLES2 rendered content work, but screen-share.c
doesn't? (Again, I could probably figure it out by staring at the code long
enough.) Then again, I don't yet know if screen-share.c is producing a black
image, or it's the rdp-backend on the second weston that's not "pixman rendering"
the image correctly.

> 
> Right. It's very good to talk about it before-hand, so you will know
> what to expect from the upstreaming aspect. Right now I cannot say if a
> new remoting backend is welcome or not, if the use cases are
> essentially the same as for RDP-backend.

I think they are, and even cover more than our requirements.

> Although, I suppose why not,
> the RDP-backend has been pretty easy on maintenance too, but it has a
> dedicated person taking care of it when something breaks (usually due
> to freerdp breaking its API).

It doesn't bring a fuzzy feeling that none of the Microsoft RDP clients work
with rdp-backend, nor does my old CoRD client. Makes me think that the freerdp
backend would always give us trouble down the line.

Again, excluding MALI completely, in plain non sharing rdp weston, only the
xfreerdp and wfreerdp.exe has given me an image.


> Maybe Daniel Stone could say something? I must confess I don't really
> keep track on downstreams much.
> 

Thanks for your help guys!