Thank you for your reply, my hardware is not ready yet.
1, my test:
I have done a test, the two terminals were set up different environment variables, terminal 1 no matter how set, will not affect the proc of Terminal 2.
cat /proc/31495/environ
View the environment variables of the proc is DISPLAY=:1.0
2, One of my ideas:
Suppose I have two proc A and B
I envisioned that I could set it up in the startup script
Then it should be possible to achieve two processes using different display interfaces.
There is an important question: whether the two processes can share memory through ‘dma_buf’?
For example, in proc_A, pipeline is ‘dec->vic’, vic’s capture_plane use ‘dma_buf’, can the fd be given to the proc_B’s renderer to show?
I did not configure X server.
I just open a terminal, first input shell command: export DISPLAY=:1.0 ( or export DISPLAY=:0.0), then run the mmapi’s sample
Do you mean that QT can support DRM? I am very interested in this
I have a few questions
1, what version of QT can support DRM? is it must be the embedded version ?
2, through the DRM, QT and video can be superimposed display? Video output from the main window, QT superimposed on the windowB(or C), with translucent effect
Don’t know if this is particularly relevant, but you can’t use DISPLAY=:1.0 unless you have already started a second X server. “:0.0” and “:0.1” would be relevant for two monitors of one X instance, “:0.0” and “:1.0” would be relevant for two X servers with one display on each server.
We solved the problem with DRM on the R28.1.
HDMI use CRTC0, use WIN_A, drmModePageFlip() func to send BUF,
DSI use CRTC1, use WIN_B, drmModeSetPlane() func to send buf,
drmModeSetPlane() does not need poll waiting for the DRM driver to return BUF, so the two display will not conflict because of drm_fd .
You can also set HDMI and DSi using their own WIN_B, use setPlane func to send buf.
Thanks for feedback. I am glad to hear you finished your project.
Moreover, I also want to ask the your development on Qt. Did you use Qt + DRM in the end?
Our team would like to know if there is anything we can help on Qt(e.g. integrate it with our native graphic system)
thanks you ~
We use the QT+DRM architecture, QT5.9 version can support DRM, configure QT’s QPA backends to eglfs_kms_egldevice, and modify QT plugin source code, compatible with our DRM library on L4T.
QT plugin source code has been mainly modified:
1, drmOpen device name is “nv-drm”
2, do not allow QT to modify the CRTC configuration, directly using the existing configuration to display
The way we use QT may not be very common, and most people use X11 as a display backend.
Is it possible to share or any reference how exactly is below change doing?
"QT plugin source code has been mainly modified:
1, drmOpen device name is "nv-drm"
2, do not allow QT to modify the CRTC configuration, directly using the existing configuration to display"
Also, do you use our default rootfs to enable eglfs in QPA?
Because x can’t do the layered overlay of the video and QT, if use QT to open a window to display the video, I don’t know how Qt show the dma_buf in the QT-created window.