OpenEmbedded for Tegra
-
EGLFS issues with kernel 6.12Test deviceSoC: Orin NX Issue contextI'm trying to bring our project to current master, and switch to the mainline yocto kernel. I've got most of the stuff "working" with current master and 6.12 linux-yocto. But I would also want to get rid off Xorg and use Qt with EGLFS. Does anyone has some idea whether this should be feasible? I have tried next two setups. 1: Setup with tegra-libraries-gbm-backendIf I 2: Setup with tegra-udrm-gbmIf I enable I'm running simple PyQt example which should draw a moving white box like this: 
But on the screen I get this deformed artifact instead of box. 
Debug output of the Qt example runing on the target device. I'm not that familiar with the Tegra GPU stack and all the libraries involved. So any hint where to look or what to try is appriciated. |
Beta Was this translation helpful? Give feedback.
Answered by
kekiefer
Nov 19, 2025
Replies: 1 comment 3 replies
-
|
Yeah the tegra libraries gbm struggles with the most basic stuff, so dealing with tegra-udrm-gbm here is the right move. We're using the tegra-udrm-gbm in production with Qt (and the eglfs_kms backend) and linux-yocto on scarthgap for Xavier AGX, Orin NX, and Orin AGX platforms, and I've also tested this on master with Orin NX/AGX, but a couple months back so there may be some regression here. This is with displays using both the built-in tegra display drivers as well as a KMS render only device. From the look of it, the underlying issue with the scrambled looking image is that a buffer is being misinterpreted as being pitch/raster formatted vs block linear, which is probably a case of incorrect modifiers being set on the buffer. See sections in the code here https://github.com/OE4T/tegra-udrm-gbm/blob/master/tegra_udrm_gbm.c#L313 and here https://github.com/OE4T/tegra-udrm-gbm/blob/master/tegra_udrm_gbm.c#L160 As to why this is happening I can't say, but hopefully this insight can help move the discussion forward so we can get this working again. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
You are right, it was my fault. I cannot fully disable X11 in build, since we use some components which requires it. So I ended up with build which still included tegra libraries. With this setup I traced down the issue to the EGLFS code where these flags you mentioned are used. I found out that pipeline is at least get setup, when I replace the flags with 0. After fixing the distro build (including tegra-udrm-gbm properly) I forgot to clean my changes in qtbase (EGLFS) build dir, which was still passing zero, which then probably broke the buffer attributes. So if got it right, the difference between eglfs_kms_egldevice and eglfs_kms is, that one is using NVIDIA's EGL streams, and the second is using GBM? But both ways end up in NVIDIA proprietary "Mesa" libs? And this udrm wrapper is just fixing up the bugs in their GBM implementation? |
Beta Was this translation helpful? Give feedback.
-
|
That about sums it up. More of the stack is open with the GBM implementation (mesa, glvnd, and other components are open source), Many third part applications and libraries do not have eglstreams backends, but GBM support is standard across multiple vendors, so the GBM approach is attractive for these reasons. You are right that all of rendering is still done in nvidia's closed source graphics drivers in the end. |
Beta Was this translation helpful? Give feedback.
-
|
Ok. I finally got the app running with eglfs_kms backend. And X11 entirely disabled in the build. Thanks a lot |
Beta Was this translation helpful? Give feedback.
Answer selected by
loblik
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yeah the tegra libraries gbm struggles with the most basic stuff, so dealing with tegra-udrm-gbm here is the right move.
We're using the tegra-udrm-gbm in production with Qt (and the eglfs_kms backend) and linux-yocto on scarthgap for Xavier AGX, Orin NX, and Orin AGX platforms, and I've also tested this on master with Orin NX/AGX, but a couple months back so there may be some regression here. This is with displays using both the built-in tegra display drivers as well as a KMS render only device.
From the look of it, the underlying issue with the scrambled looking image is that a buffer is being misinterpreted as being pitch/raster formatted vs block linear, which is probably a case of in…