Wayland/weston, Qt and RDP connection...

[Pekka Paalanen]

On Sat, 14 Jan 2023 11:58:37 +0200
Marius Vlad <marius.vlad at collabora.com> wrote:

> On Fri, Jan 13, 2023 at 08:07:07PM +0000, Matti Ristimäki wrote:
> > Hi,  
> Hi,
> > 
> > 
> > 
> > Thanks for the reply!
> > 
> > 
> > 
> > Jep, this might be the reason...
> >   
> > > --modules=systemd-notify.so --modules=screen.share.so  
> > 
> > This might be a long shot but it is screen-share.so (hyphen).

Hi,

this typo would stop Weston from starting, and Weston would clearly say
in its log why. The Weston log output is always important to look at. If
the compositor doesn't start, also applications will fail to start with
"Failed to create wl_display" or other such error.

If you use Weston's --log option, check the file since Weston won't
print its log to the standard output. I might recommend to not use
--log, and let the systemd service unit forward the stdout and stderr
into the journal instead (which it does by default).

> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: EGL: Warning: No default display support on wayland

That means that the application is not checking whether connecting to
a Wayland compositor worked or not. This is an application bug, but
it is just secondary fallout from the primary failure. Quite likely
the application will also crash (segfault).

The reason is that EGL_DEFAULT_DISPLAY is equal to NULL, so I infer
that the application code does not verify that the wl_display is not
NULL before using it.

EGL_DEFAULT_DISPLAY cannot work with Wayland by design.

> > We did try the RDP-weston -session this way too...
> > 
> > 1.
> > 
> > Running RDP-weston -session manually via terminal and after that forcing weston-smoke to the RDP-weston -session.
> > 
> > 
> > 
> > First weston rdp-backend command via terminal. Notice, that here the "--modules=screen-share.so" is written correctly: (And after that WAYLAND_DISPLAY=wayland-0 is running...)
> > 
> > 
> > 
> > weston --backend=rdp-backend.so --modules=screen-share.so --rdp-tls-cert=/data/etc/ssh/tls.crt --rdp-tls-key=/data/etc/ssh/tls.key  
> Just noticed, you already start weston with the RDP backend *and* with
> the screen-share module. Is that on purpose?

I suspect that is not intended. Having both rdp-backend and
screen-share in the same Weston instance has no use.


> The screen-share module starts a weston instance with the RDP backend
> (assuming you have start-on-startup in the ini file) which you connect
> to.
> 
> So for instance, if you have the following in your ini file:
> 
> [core]
> modules=screen-share.so
> 
> [screen-share]
> command=/path/to/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-key=rdp/tls.key --rdp-tls-cert=rdp/tls.crt --no-config
> start-on-startup=true
> 
> Then you run it like:
> 
> $ /path/to/weston --config /path/to/weston.ini
> 
> It would automatically start *another* weston instance on the machine to 
> connect to. Weston then chooses up, its own a back-end to use locally 
> (for instance the DRM back-end), but also creates another weston instance
> with the RDP back-end (which is being done by the screen-share module).

This is the right idea.

One shall never start the "second" Weston if screen sharing is desired,
only the screen-share plugin in the "first" Weston can do that.

> So, when the second RDP instance is started by screen-share.so it won't
> really do anything as it won't be able to do a socket bind (being an already
> RDP server instance on that port).
> 
> Do you have a display/an output on that local device, or is it without
> any outputs graphic devices?
> 
> Can you provide a full weston log when this happens?

That would be interesting.

Matti, it could be beneficial to build the set-up in steps:

1. No screen-share, no Qt app. Just Weston with its local backend (DRM
   quite likely) and a demo app, e.g. weston-simple-egl (shows a
   spinning triangle in OpenGL ES 2).

2. Add screen-share, but no Qt app. Make sure both local and RDP
   outputs look good with a demo app.

3. Add the Qt app.

If you stop at the first point where you encounter problems, it is
easier to ask and answer.

You have already shown that a stand-alone (non-screen-sharing) RDP
Weston instance works fine with your weston-smoke experiment.

Your Qt app segfaults in the stand-alone RDP Weston instance case. We
have no idea why that would be, when weston-smoke works. If it is
because the app requires hardware accelerated OpenGL (or you use a
proprietary EGL implementation), then it might still work with the
DRM-backend. This is because the RDP-backend does not yet support
hardware accelerated OpenGL or Vulkan apps. Normally apps will just
fall back to Mesa's software renderer, but maybe your app needs
something extra or maybe you are not using Mesa as your EGL etc.
implementation.

A full Weston log would answer many questions.

Proprietary graphics driver stacks tend to be hard to work with,
because obviously we cannot fix them, and they often work only in very
narrow circumstances. Some vendors even patch Weston, so it would be
good to understand if you are using an upstream Weston or something
with downstream patches.


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/20230116/7424e58e/attachment.sig>