Can't debug/run a GUI (QML) project on a remote target (Raspberry Pi)

MuratUrsavas

Hi,

As I'm fairly new to remote debugging, I've hit a wall and can not pass it. I had successfully compiled Qt 5.15 for Raspberry Pi cross compilation and set up the right development environment. I've verified it with example projects.

Now I'm trying to debug my QML application on the remote target but I'm failing every time with this output:

Debugging starts
Warning: Identity file  not accessible: No such file or directory.
QML debugging is enabled. Only use this in a safe environment.
Failed to move cursor on screen HDMI1: -13
Failed to move cursor on screen HDMI1: -13
QML Debugger: Waiting for connection on port 10002...
Could not set DRM mode for screen HDMI1 (Permission denied)
Could not queue DRM page flip on screen HDMI1 (Permission denied)
Could not queue DRM page flip on screen HDMI1 (Permission denied)

Note that this output was different when I was doing my tests as headless (just with a VNC connection).

In fact this is the same output if I ssh to the target and run the executable. So, clearly I'm missing a basic approach at here. Read and tried many advice like X11 forwarding etc but these lead to Segmentation Faults, so no luck here.

Executable is running just fine on the target, no issues there.

Could you help me with remote debugging a GUI/QML project via Qt Creator? I don't mind where the GUI pops up, it can be on development machine or remote target.

Thanks in advance.

Regards,

Dev Machine: Ubuntu 20.04
Target: Raspbian with Kernel 5.4.51-v7+

SGaist

Hi,

Do you have X11 up and running ?
Are you starting your application as root or standard user ? If the former, AFAIR, there are security settings that disallow root to access the X server.

MuratUrsavas

Yes, X11 is up and running. I've tested X11 forwarding via standard xclock application and seen that forwarding works as expected. So the issue should be related somehow to Qt toolkit. But I couldn't find a working solution yet.

App is triggered as standard user, not as root.

MuratUrsavas

I've also tested the same scenario with glxgears (from mesa-utils). Even though the performance is terrible (just 3.3% of the original performance) it worked. So Open GL backend should not be the problem. Things narrowed down to Qt again.

X11 is not listening to port 6000 right now, could that be a problem?

SGaist

What happens if you start the application directly on the device in the X11 session ?

MuratUrsavas

It starts as planned. No warnings, no hassle. Everything works just fine.

MuratUrsavas

Here's the log if I execute it directly (with QT_QPA_EGLFS_DEBUG env variable set to 1)

QML debugging is enabled. Only use this in a safe environment.
Created context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) with config:
	EGL_BUFFER_SIZE: 24
	EGL_ALPHA_SIZE: 0
	EGL_BLUE_SIZE: 8
	EGL_GREEN_SIZE: 8
	EGL_RED_SIZE: 8
	EGL_DEPTH_SIZE: 24
	EGL_STENCIL_SIZE: 8
	EGL_CONFIG_CAVEAT: 12344
	EGL_CONFIG_ID: 9
	EGL_LEVEL: 0
	EGL_MAX_PBUFFER_HEIGHT: 4096
	EGL_MAX_PBUFFER_PIXELS: 0
	EGL_MAX_PBUFFER_WIDTH: 4096
	EGL_NATIVE_RENDERABLE: 1
	EGL_NATIVE_VISUAL_ID: 33
	EGL_NATIVE_VISUAL_TYPE: 4
	EGL_SAMPLES: 0
	EGL_SAMPLE_BUFFERS: 0
	EGL_SURFACE_TYPE: 7
	EGL_TRANSPARENT_TYPE: 12344
	EGL_TRANSPARENT_BLUE_VALUE: 0
	EGL_TRANSPARENT_GREEN_VALUE: 0
	EGL_TRANSPARENT_RED_VALUE: 0
	EGL_BIND_TO_TEXTURE_RGB: 1
	EGL_BIND_TO_TEXTURE_RGBA: 0
	EGL_MIN_SWAP_INTERVAL: 0
	EGL_MAX_SWAP_INTERVAL: 1000

and it runs perfectly.

Here's the output if I run it via ssh (no X forwarding):

QML debugging is enabled. Only use this in a safe environment.
Failed to move cursor on screen HDMI1: -13
Failed to move cursor on screen HDMI1: -13
Created context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) with config:
	EGL_BUFFER_SIZE: 24
	EGL_ALPHA_SIZE: 0
	EGL_BLUE_SIZE: 8
	EGL_GREEN_SIZE: 8
	EGL_RED_SIZE: 8
	EGL_DEPTH_SIZE: 24
	EGL_STENCIL_SIZE: 8
	EGL_CONFIG_CAVEAT: 12344
	EGL_CONFIG_ID: 9
	EGL_LEVEL: 0
	EGL_MAX_PBUFFER_HEIGHT: 4096
	EGL_MAX_PBUFFER_PIXELS: 0
	EGL_MAX_PBUFFER_WIDTH: 4096
	EGL_NATIVE_RENDERABLE: 1
	EGL_NATIVE_VISUAL_ID: 875713112
	EGL_NATIVE_VISUAL_TYPE: 12344
	EGL_SAMPLES: 0
	EGL_SAMPLE_BUFFERS: 0
	EGL_SURFACE_TYPE: 4
	EGL_TRANSPARENT_TYPE: 12344
	EGL_TRANSPARENT_BLUE_VALUE: 0
	EGL_TRANSPARENT_GREEN_VALUE: 0
	EGL_TRANSPARENT_RED_VALUE: 0
	EGL_BIND_TO_TEXTURE_RGB: 0
	EGL_BIND_TO_TEXTURE_RGBA: 0
	EGL_MIN_SWAP_INTERVAL: 1
	EGL_MAX_SWAP_INTERVAL: 1
Could not set DRM mode for screen HDMI1 (Permission denied)
Could not queue DRM page flip on screen HDMI1 (Permission denied)
Could not queue DRM page flip on screen HDMI1 (Permission denied)

And as expected, no displayed window at all, even though the application loop continues its execution.

With X forwarding the result is the same with all DISPLAY parameters known by me.

MuratUrsavas

One last thing: I've verified that I can run glxgears via ssh using the remote display, which is what I want, using environment parameter DISPLAY=:0

So, clearly Qt is nitpicking something about DRM security, but I don't know what it is.

MuratUrsavas

OK, I guess I'm getting somewhere (but quite slowly). I think Qt is trying to become a DRM Master which is exclusive privilege for X11 right now, since DRM only allows single master.

To see the effect of this, I've booted the remote machine to CLI without X and run my app over ssh.

Even though I haven't had a complete success, things approved the idea above. No more permission error means my app is really trying to become DRM master (why, is Qt thinking that my app must be a single window embedded app?).

Anyway, I've seen a mouse icon on the display but here's the new output:

QML debugging is enabled. Only use this in a safe environment.
Could not queue DRM page flip on screen HDMI1 (Invalid argument)
Could not queue DRM page flip on screen HDMI1 (Invalid argument)

Nothing more than a mouse icon at 0,0.

SGaist

Good spelunking !

Are you sure the application is started using the xcb backend ? I wonder if it's not using EGLFS or something like that.

MuratUrsavas

And success. I've been able to see my app finally via using this environment variable:

QT_QPA_EGLFS_ALWAYS_SET_MODE="1"

But still, I need to stop my app attempting to be the DRM master, to use Desktop Environment.

MuratUrsavas

Oh, we should've been send the messages at the same time, haven't seen it.

I guess my previous post could be used as a proof that EGLFS is actively used. Otherwise I need some more information to prove it.

MuratUrsavas

Snap! Even though I can run app via ssh, debugging is not possible. I've already entered same environment variables and even entered them in to the bash profile file. I'm getting the same error like I'd not given the variables.

Any suggestions?

The environment variables are defined in: Kit Definition, Project Run Settings and remote bash profile file of the user.

Do you know how to execute remote commands within QtCreator debugging?

SGaist

Sorry, it's been a long time since I did that.

Maybe this page of Qt Creator's documentation will help you.

MuratUrsavas

Thanks, I have couple of ideas to try, then I'll merge myself to that documentation :)

MuratUrsavas

Hopefully I've found my way to a proper debug session. Turned out, I needed one more environment variable which is QT_QPA_EGLFS_KMS_ATOMIC. Setting it as 1 solved my problem.

To sum up, these three environment variables are required for a proper EGLFS remote debugging on a remote display:

DISPLAY=:0
QT_QPA_EGLFS_ALWAYS_SET_MODE=1
QT_QPA_EGLFS_KMS_ATOMIC=1

These can be entered in the kit information or remote device/user bash profile. But they haven't worked on my setup. Maybe I missed something, I don't know.

But if you enter these variables into "Project Settings / Run / Environment Variables" it would work. You also may need to fetch existing variables from the remote system (at least it's suppressing an annoying warning which is XDG_RUNTIME_DIR).

MuratUrsavas

Unfortunately this works only if X11 is not active, hence booted to CLI. Looks like I need to dig more...