search

RPi-Distro / repo

Issue tracking for the archive.raspberrypi.com repo
37 stars 1 forks source link

[Buster] Qt app crash when no monitor is plugged #152

Closed mcallegari closed 5 years ago

mcallegari commented 5 years ago

Hi, it seems Buster improved the Qt + VC4 experience but I discovered a new issue. This can be reproduced with vanilla Qt libraries 5.11.3. When launching a graphics Qt application using EGLFS QPA with no HDMI monitor plugged, the application simply crashes. From a text runlevel launch like this: qt_app -platform eglfs I spent some time on this and it doesn't seem to be in my code. It seems to be in the Qt EGLFS QPA. This might even be related to VC4 (maybe when no monitor is attached, no OGL surface is provided)

This is not good, cause many of my users use the Raspberry Pi headless, with no monitor attached. My application can be controlled remotely via web interface.

Has anyone seen this behaviour so far? Anybody any clue?

Thanks

XECDesign commented 5 years ago

This repo is for reporting issues with packages in the archive.raspberrypi.org repo. The build of Qt we use comes from raspbian.org and is mostly the stock Debian package.

mcallegari commented 5 years ago

I get that, but if this issue turns out to be in the VC4 driver, wouldn't this be the right place to post it?

XECDesign commented 5 years ago

Is it using the open source Mesa V3D driver with FKMS or the legacy libbrcm GLES libs?

What's meant to happen if there no framebuffer device available?

mcallegari commented 5 years ago

Is it using the open source Mesa V3D driver with FKMS or the legacy libbrcm GLES libs?

It's all vanilla so it's using Mesa. Don't know if it's using KMS. Where do I check how Qt is built on Raspbian?

What's meant to happen if there no framebuffer device available?

Obviously not crashing... Up to Stretch (which was using legacy VC4 blobs) this issue never occurred, so I'd say Qt was OK. Unless I've stumbled on a regression. ATM I have no chance to test 5.10.x or 5.12.x on Raspbian. (how would I btw?)

XECDesign commented 5 years ago

It's all vanilla so it's using Mesa. Don't know if it's using KMS. Where do I check how Qt is built on Raspbian?

'vanilla' depends on the model of the pi you're running. The stock image will use mesa's libs on pi4, but legacy libs on all other models.

If you uncomment the deb-src line in /etc/apt/sources.list and run `sudo apt update && apt source $package_name' you can download the debian source package and see how it's built.

Obviously not crashing...

Why not? If you don't have a device to output anything to it seems like it's up to the application to check that what it's trying to do is sensible.

Up to Stretch (which was using legacy VC4 blobs) this issue never occurred, so I'd say Qt was OK.

The old driver would still give you a framebuffer device (/dev/fb0) even if nothing was plugged in, so maybe this is the issue. If you force HDMI in config.txt and reboot, you should be able to get the old behaviour back.

ATM I have no chance to test 5.10.x or 5.12.x on Raspbian. (how would I btw?)

I think you'd need to refer to upstream documentation for build instructions.

mcallegari commented 5 years ago

Alright, thanks a lot for your reply. Will check the above and come back when I have some news.

'vanilla' depends on the model of the pi you're running. The stock image will use mesa's libs on pi4, but legacy libs on all other models.

Didn't know this and it's quite interesting. It suggests the issue might not be there on RPi < 4.

Obviously not crashing...

Why not? If you don't have a device to output anything to it seems like it's up to the application to check that what it's trying to do is sensible.

The 'application' in this case is Qt, so out of my control. By the time I build Qt, debug the code, submit a patch, the patch gets approved, Debian picks it up...I would turn 100 years old :wink:

mcallegari commented 5 years ago

@XECDesign thanks for your suggestions. The hotplug workaround works fine for me so I'll close this.