Comments (6)
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.
from meta-tegra.
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.
from meta-tegra.
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.
from meta-tegra.
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!
from meta-tegra.
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!
from meta-tegra.
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.
from meta-tegra.
Related Issues (20)
- Avoid dummy0 interface being created HOT 6
- "isolcpus=" to enable offline cores Orin NX
- Issue adding a custom `.dtb` for custom carrier (A603) HOT 1
- `p3509-a02-p3767-0000` fails compiling due to tegra-minimal-initramfs' do_image_cpio (kirkstone) HOT 2
- How to modify MB1 & MB2 BCTs and how to sign and store with keys HOT 1
- Orin NX won't boot scarthgap build HOT 3
- nvidia-kernel-oot: Conflicts with intree kernel modules of the same name HOT 7
- Cannot compile kernel on kirkstone HOT 5
- scarthgap: gtk-4.14.1 build failed, dependency "libdrm" not found HOT 6
- Xavier AGX fails to switch partitions after swupdate HOT 2
- tegra-uefi-capsules-36.3.0/bup-payload/signed/flash.idx is not found when building SWUpdate image HOT 3
- Question: Are there any plans for updating kirkstone-l4t-r32.7.x to the latest L4T32.7.5? HOT 2
- Wifi hiccups with tegra-kernel oe4t-patches-l4t-r32.7.4 HOT 1
- nsight-systems license md5 HOT 1
- tegra-uefi-capsules/36.3.0/tegra-uefi-capsules-36.3.0/bup-payload/signed/flash.idx is not found HOT 1
- Crash in nvgpu module with 5.15 kernel 5.15.136-l4t-r36.3 HOT 49
- Device bricked, stopped at EFI console HOT 3
- NVS compilation error, kirkstone HOT 4
- Issues Flashing to Jetson Orin nano devkit with secure boot HOT 8
- Spidev loop back test is not working on L4T 35.4.1 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meta-tegra.