R28.1: Wayland/weston

[madisongh]

With L4T R28.1, NVIDIA provides experimental support for Wayland. Need to investigate that and see if it can be integrated.

[jonte]

Hi,

Thanks for your excellent efforts with this layer. We're also very interested in getting Wayland support on the TX2. We've compiled Weston 3.0.0 with some patches from NVIDIA for enabling EGLStream, EGLOutput and EGLDevice (as far as I can tell, this should enable EGLStream usage rather than the traditional Weston GBM).

Weston and libwayland seems to run OK (as in, I get console output when I execute weston) when applied on top of this layer, but I think we're missing driver support for DRM. Do you have any input on what might be needed to enable DRM on the TX2 for the drm-backend.so to work in Weston?

I noticed that the kernel sources from NVIDIA2 seem to include GPU drivers (kernel/nvgpu/drivers/gpu/nvgpu/) - perhaps the correct driver, paired with NVIDIA libdrm should be enough?

I will be able to devote some time to working on this, and will of course upstream any successful results.

[madisongh]

That would be great, thanks... and thanks for the point to those patches. I don't know whether NV will support using the DRM backend. If you want to use it, you'll probably need to use the libdrm.so they provide in the drivers kit. For R24.1 and R27.1, I omit those from the build altogether; for R28.1 I'm renaming that library to libdrm-tegra.so so it can be installed without interfering with the open-source version of the library. Unforutnately, the Tegra version appears to implement an older (or modified) version of the libdrm API that doesn't have all the functions expected by current client code.

That's about as far as I got in my investigation. Any help would be much appreciated.

[jonte]

Hi,

I have made some progress on this.

Basically, I have managed to run QtWayland, which has built-in support for EGLStreams. There really wasn't much to tweak with QtWayland, it mostly worked out of the box as long as I set the correct "platform integration" for the eglfs plugin. I used the following command to start my compositor:

QT_QPA_EGLFS_INTEGRATION=eglfs_kms_egldevice XDG_RUNTIME_DIR=/tmp qmlscene /tmp/main.qml -platform eglfs

And the following to start a client (file selector box from qmlscene):

XDG_RUNTIME_DIR=/tmp qmlscene -platform wayland

For reference, I am using this as my compositor application:
https://github.com/qt/qtwayland/blob/7ee4be6af2c92c345539bb4950dd48d7a740847d/examples/wayland/minimal-qml/main.qml

I am, as you suggested, using libdrm-tegra.so (I simply moved it to /usr/lib/libdrm.so.2). It looks to me like we need a way to let the user of meta-tegra select which libdrm to use, since the mesa libdrm will not work with Wayland. Do you have any suggestion on how to do this?

Perhaps we should create a new recipe for the nvidia libdrm, and make this provide libdrm, so that the user can set the PREFERRED_PROVIDER to the correct drm implementation?

I have a colleague who already started looking at separating libdrm to its own recipe here: BassemMohsen@1a6473e#diff-b9ebf6ac291728b67ad7ae2257e56572 <- What do you think about this approach?

Also, if we start by separating libdrm to its own recipe, maybe we should split the other libraries in tegra-libraries to their own recipes as well?

Again, I am willing to do this work.

Also, final note. We spent quite some time on Weston 3.0.0 with the NVIDIA patches mentioned above, and we couldn't really get it working, so we gave up on this track.

[madisongh]

That's great progress!

On separating out the various libraries and drivers: I did try that initially, but it is difficult, if not impossible, to know exactly what dependencies there are between the libraries that NVIDIA packages together. So I left them bundled together by default, then carved out separate packages to handle specific cases where that separation was required.

Rather than extracting their libdrm and related files from the L4T package and checking those files into the layer, we should be able to use the update-alternatives mechanism to supply their libdrm as a replacement.

Thanks!

[jonte]

Hi,

On separating out the various libraries and drivers: I did try that initially, but it is difficult, if not impossible, to know exactly what dependencies there are between the libraries that NVIDIA packages together. So I left them bundled together by default, then carved out separate packages to handle specific cases where that separation was required.

Alright, this makes sense. We will put our contribution in the same format.

Rather than extracting their libdrm and related files from the L4T package and checking those files into the layer, we should be able to use the update-alternatives mechanism to supply their libdrm as a replacement.

I am not familiar with update-alternatives (other than in Debian) - I will have a look at this. Thanks for the pointer!

[madisongh]

With the L4T R28.2 release, I looked into this again. Weston is still a no-go due to the GBM vs EGLStream conflict, unless we just use the pre-built copy that NVIDIA provides, which I'm not crazy about. A future xserver-xorg release may support EGLStreams for XWayland. Trying to apply those patches (which are only still proposed and not yet in the xserver code base) on the existing 1.19 xserver code turned into a rat's nest, so we'll just have to wait.