weston rdp black screen

[Pekka Paalanen]

On Fri, 12 Apr 2019 12:12:06 -0400
Jean-Francois Dagenais <jeff.dagenais at gmail.com> wrote:

> > 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.

Hi,

yeah, I have no idea off-hand.

> > 
> > 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.

Right, but is that an inherent problem in RDP (e.g. being difficult to
implement), is FreeRDP library not good enough, or is it just the
Weston backend being not good enough?

I suspect the RDP-backend and/or FreeRDP have some assumptions or
deliberate omissions, which might cause problems. David?

If you introduce a new backend, can you at least believe yourself that
you would not knowingly leave omissions in the implementation that
would lead to similar problems in other circumstances? :-)


Thanks,
pq
-------------- 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/20190416/a8c441b6/attachment.sig>