Wayland/weston, Qt and RDP connection...

Mon Jan 16 14:25:25 UTC 2023

Hi,

Ok, this might be the reason…

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.

------------------------------------------------------------------------------------

Testing weston-simple-egl with RDP and HDMI-display

------------------------------------------------------------------------------------

"Force driving" weston-simple-egl to RDP-weston session: (WAYLAND_DISPLAY=wayland-1)

Command:

WAYLAND_DISPLAY=wayland-1 weston-simple-egl

has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage

Segmentation fault

Logging:

root at sm2s-imx8mp:~# journalctl -f

-- Journal begins at Mon 2023-01-16 09:50:23 CET. --

Jan 16 11:47:32 sm2s-imx8mp audit[1569]: ANOM_ABEND auid=0 uid=0 gid=0 ses=5 pid=1569 comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1

Jan 16 11:47:32 sm2s-imx8mp kernel: audit: type=1701 audit(1673866052.888:25): auid=0 uid=0 gid=0 ses=5 pid=1569 comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1

Result:

Doesn't work.

And similar error appears, when I’m trying to drive “Qt” application on RDP-weston:

Jan 16 13:51:55 sm2s-imx8mp audit[2027]: ANOM_ABEND auid=0 uid=0 gid=0 ses=5 pid=2027 comm="QSGRenderThread" exe="/opt/cpx/cpx" sig=11 res=1

Jan 16 13:51:55 sm2s-imx8mp kernel: audit: type=1701 audit(1673873515.594:33): auid=0 uid=0 gid=0 ses=5 pid=2027 comm="QSGRenderThread" exe="/opt/cpx/cpx" sig=11 res=1

------------------------------------------------------------------------------------

------------------------------------------------------------------------------------

"Force driving" weston-simple-egl to a HDMI display (WAYLAND_DISPLAY=wayland-0)

Command:

WAYLAND_DISPLAY=wayland-0 weston-simple-egl

Logging:

root at sm2s-imx8mp:/opt/cpx# WAYLAND_DISPLAY=wayland-0 weston-simple-egl

has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage

304 frames in 5 seconds: 60.799999 fps

302 frames in 5 seconds: 60.400002 fps

302 frames in 5 seconds: 60.400002 fps

302 frames in 5 seconds: 60.400002 fps

302 frames in 5 seconds: 60.400002 fps

Result:

Works fine, animation runs smoothly.

[cid:image001.png at 01D929AF.41CA1A80]

------------------------------------------------------------------------------------

BR,

-Matti

-----Original Message-----
From: Pekka Paalanen <ppaalanen at gmail.com>
Sent: maanantai 16. tammikuuta 2023 11.40
To: Matti Ristimäki <Matti.Ristimaki at planmeca.com>
Cc: Marius Vlad <marius.vlad at collabora.com>; wayland-devel at lists.freedesktop.org
Subject: Re: Wayland/weston, Qt and RDP connection...

On Sat, 14 Jan 2023 11:58:37 +0200

Marius Vlad <marius.vlad at collabora.com<mailto: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

This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230116/f7417de5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 239387 bytes
Desc: image001.png
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230116/f7417de5/attachment-0001.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: weston-simple-egl---cat-weston-log.txt
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230116/f7417de5/attachment-0001.txt>