QT Platform Pluggin - drmModeGetResources Failed

[Carbur8tr]

Made a couple of small changes and tried to troubleshoot as much as I could but it seems like I'm at the point where I might need to recompile QT. Would appreciate any thoughts you have on the subject.

This is using the following: Raspberry Pi 5 4gb Latest "Lite" OS release as of 7/4

Adding Sudo to the startup script "/opt/piplay/startup.sh" lands me here: Jul 06 08:04:27 RTSP systemd[1]: piplay.service: Scheduled restart job, restart counter is at 1. Jul 06 08:04:27 RTSP systemd[1]: Stopped piplay.service - PIPlay. Jul 06 08:04:27 RTSP systemd[1]: Started piplay.service - PIPlay. Jul 06 08:04:27 RTSP sudo[3728]: root : PWD=/opt/piplay ; USER=root ; COMMAND=/usr/bin/python3 /opt/piplay/piplay.py Jul 06 08:04:27 RTSP sudo[3728]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0) Jul 06 08:04:28 RTSP startup.sh[3729]: qt.qpa.xcb: could not connect to display Jul 06 08:04:28 RTSP startup.sh[3729]: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. Jul 06 08:04:28 RTSP startup.sh[3729]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Jul 06 08:04:28 RTSP startup.sh[3729]: Available platform plugins are: linuxfb, minimalegl, offscreen, vnc, xcb, vkkhrdisplay, minimal, eglfs. Jul 06 08:04:28 RTSP sudo[3728]: pam_unix(sudo:session): session closed for user root Jul 06 08:04:28 RTSP startup.sh[3727]: /opt/piplay/startup.sh: line 6: 3728 Aborted sudo python3 /opt/piplay/piplay.py Jul 06 08:04:28 RTSP systemd[1]: piplay.service: Main process exited, code=exited, status=134/n/a Jul 06 08:04:28 RTSP systemd[1]: piplay.service: Failed with result 'exit-code'.

If I remove sudo from the startup script "/opt/piplay/startup.sh we get the following: Jul 06 08:16:46 RTSP systemd[1]: piplay.service: Scheduled restart job, restart counter is at 2. Jul 06 08:16:46 RTSP systemd[1]: Stopped piplay.service - PIPlay. Jul 06 08:16:46 RTSP systemd[1]: piplay.service: Consumed 1.039s CPU time. Jul 06 08:16:46 RTSP systemd[1]: Started piplay.service - PIPlay. Jul 06 08:16:47 RTSP startup.sh[3821]: drmModeGetResources failed (Operation not supported) Jul 06 08:16:47 RTSP startup.sh[3821]: no screens available, assuming 24-bit color Jul 06 08:16:47 RTSP startup.sh[3821]: Cannot create window: no screens available Jul 06 08:16:47 RTSP startup.sh[3820]: /opt/piplay/startup.sh: line 6: 3821 Aborted python3 /opt/piplay/piplay.py Jul 06 08:16:47 RTSP systemd[1]: piplay.service: Main process exited, code=exited, status=134/n/a Jul 06 08:16:47 RTSP systemd[1]: piplay.service: Failed with result 'exit-code'. Jul 06 08:16:47 RTSP systemd[1]: piplay.service: Consumed 1.049s CPU time.

[HussX]

@Carbur8tr Off the bat, I'm not sure which changes you made. The error with sudo added is because eglfs was exported in a separate environment than the Python code. It's sudo all or sudo none, but if you're using systemd sudo isn't needed. If you want to add sudo, do it on the systemctl command. The second bit looks like you don't have a screen connected or turned on. I'll look and make sure I didn't muck something up. Also, was this on the latest push? I ran across this a couple times in testing and it was erring because I had the screen turned off on system start up. If you used the install script and the service is enabled, have you also tried a reboot without the added sudo to see if it kicked off?

[HussX]

@Carbur8tr I'm curious if the pi5 has the card0 vs card1 issue with eglfs I see all over Google. I have a 5 to test with at work but I'm hopping a plane to Dallas, Monday. I want this to work on a 5 as well, so I'll dig in as soon as time permits.

[HussX]

@Carbur8tr also, try plugging the screen into the other HDMI port to see if it detects. I didn't do any testing whatsoever on multiple port setups.

[Carbur8tr]

From top to bottom.

I’ve tried it a few different ways using sudo and not. Just trying to find if either makes a difference and obviously it did but to your point I’m not sure it’s making a large difference due to the nature of the failure.

Latest push, fresh start this morning with the OS and pull.

I have rebooted a few times with the monitor still on so I would hope that would be a good baseline for eglfs to capture the screen dimensions. (Could be wrong)

I’m running all the commands via ssh so I’m hoping that’s not possibly a difference that’s causing an issue. Regardless, I think you might be on to something with switching the ports on the pi.

I read up on the card1/card 0 issue and it’s a possibility but I tried a few things that others have reported to remedy the issue and still same issue.

I will test the other port here soon and report back.

Btw, thank you. I’ve been using displaycam for years on a pi3 and finally decided to upgrade not knowing it was no longer supported due to OMX.

[HussX]

I've been using it forever. Ssh doesn't make a difference that I've noticed. I ran all mine testing via ssh with no additional needs and then let systemd take over.

On Sat, Jul 6, 2024, 19:02 Carbur8tr @.***> wrote:

From top to bottom.

I’ve tried it a few different ways using sudo and not. Just trying to find if either makes a difference and obviously it did but to your point I’m not sure it’s making a large difference due to the nature of the failure.

Latest push, fresh start this morning with the OS and pull.

I have rebooted a few times with the monitor still on so I would hope that would be a good baseline for eglfs to capture the screen dimensions. (Could be wrong)

I’m running all the commands via ssh so I’m hoping that’s not possibly a difference that’s causing an issue. Regardless, I think you might be on to something with switching the ports on the pi.

I read up on the card1/card 0 issue and it’s a possibility but I tried a few things that others have reported to remedy the issue and still same issue.

I will test the other port here soon and report back.

Btw, thank you. I’ve been using displaycam for years on a pi3 and finally decided to upgrade not knowing it was no longer supported due to OMX.

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2212036993, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E2GRMJKVCMM4ZBSMQ3ZLBZPNAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGAZTMOJZGM . You are receiving this because you commented.Message ID: @.***>

[Carbur8tr]

Similar output in a different port:

Jul 06 20:06:18 RTSP systemd[901]: Listening on gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent emulation). Jul 06 20:06:18 RTSP systemd[901]: Listening on gpg-agent.socket - GnuPG cryptographic agent and passphrase cache. Jul 06 20:06:18 RTSP systemd[901]: Listening on dbus.socket - D-Bus User Message Bus Socket. Jul 06 20:06:18 RTSP systemd[901]: Reached target sockets.target - Sockets. Jul 06 20:06:18 RTSP systemd[901]: Reached target basic.target - Basic System. Jul 06 20:06:18 RTSP systemd[901]: Reached target default.target - Main User Target. Jul 06 20:06:18 RTSP systemd[901]: Startup finished in 129ms. Jul 06 20:06:18 RTSP systemd[1]: Started user@1000.service - User Manager for UID 1000. Jul 06 20:06:18 RTSP systemd[1]: Started session-1.scope - Session 1 of User pi. Jul 06 20:06:21 RTSP systemd[1]: systemd-fsckd.service: Deactivated successfully. Jul 06 20:06:22 RTSP systemd-timesyncd[638]: Contacted time server 108.61.73.244:123 (2.debian.pool.ntp.org). Jul 06 20:06:22 RTSP systemd-timesyncd[638]: Initial clock synchronization to Sat 2024-07-06 20:06:22.550469 CDT. Jul 06 20:06:22 RTSP systemd[1]: systemd-hostnamed.service: Deactivated successfully. Jul 06 20:06:28 RTSP systemd[1]: piplay.service: Scheduled restart job, restart counter is at 2. Jul 06 20:06:28 RTSP systemd[1]: Stopped piplay.service - PIPlay. Jul 06 20:06:28 RTSP systemd[1]: piplay.service: Consumed 1.046s CPU time. Jul 06 20:06:28 RTSP systemd[1]: Started piplay.service - PIPlay. Jul 06 20:06:29 RTSP startup.sh[938]: drmModeGetResources failed (Operation not supported) Jul 06 20:06:29 RTSP startup.sh[938]: no screens available, assuming 24-bit color Jul 06 20:06:29 RTSP startup.sh[938]: Cannot create window: no screens available Jul 06 20:06:29 RTSP startup.sh[937]: /opt/piplay/startup.sh: line 7: 938 Aborted python3 /opt/piplay/piplay.py Jul 06 20:06:29 RTSP systemd[1]: piplay.service: Main process exited, code=exited, status=134/n/a Jul 06 20:06:29 RTSP systemd[1]: piplay.service: Failed with result 'exit-code'. Jul 06 20:06:29 RTSP systemd[1]: piplay.service: Consumed 1.029s CPU time. Jul 06 20:06:39 RTSP systemd[1]: piplay.service: Scheduled restart job, restart counter is at 3. Jul 06 20:06:39 RTSP systemd[1]: Stopped piplay.service - PIPlay. Jul 06 20:06:39 RTSP systemd[1]: piplay.service: Consumed 1.029s CPU time. Jul 06 20:06:39 RTSP systemd[1]: Started piplay.service - PIPlay. Jul 06 20:06:40 RTSP startup.sh[950]: drmModeGetResources failed (Operation not supported) Jul 06 20:06:40 RTSP startup.sh[950]: no screens available, assuming 24-bit color Jul 06 20:06:40 RTSP startup.sh[950]: Cannot create window: no screens available Jul 06 20:06:40 RTSP startup.sh[949]: /opt/piplay/startup.sh: line 7: 950 Aborted python3 /opt/piplay/piplay.py Jul 06 20:06:40 RTSP systemd[1]: piplay.service: Main process exited, code=exited, status=134/n/a Jul 06 20:06:40 RTSP systemd[1]: piplay.service: Failed with result 'exit-code'. Jul 06 20:06:40 RTSP systemd[1]: piplay.service: Consumed 1.045s CPU time.

[Carbur8tr]

I've tried a few things attempting to get around this:

Jul 06 20:06:40 RTSP startup.sh[950]: drmModeGetResources failed (Operation not supported)

Really not sure at this point.

[Carbur8tr]

Dumb question, did you do your testing on 64 and 32 bit images?

[HussX]

All on 64 bit. And with direct repo packages. I feel like it's either pi5 or maybe screen manufacturer related. Although I tested with a monitor and a TV. I didn't want to directly specify screen dimensions but it may come to that depending on what I find.

On Sat, Jul 6, 2024, 21:10 Carbur8tr @.***> wrote:

Dumb question, did you do your testing on 64 and 32 bit images?

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2212116407, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E5YASHFVULSIDZL4KDZLCIRVAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGEYTMNBQG4 . You are receiving this because you commented.Message ID: @.***>

[Carbur8tr]

Tried a different screen and same outcome.

Random thought, I wonder if for some reason the 5's handle the screen resolution different from the 3s or 4s. Surely it's not the adapter I'm using to go from micro-hdmi to hdmi.

Will try a fresh OS and pull and report back hopefully here soon.

[HussX]

If it was a VGA adapter I'd believe it. I'm using an adapter on one, the other is straight through. I'm also curious, under raspi-config, what happens if you switch the back end?

On Sun, Jul 7, 2024, 13:57 Carbur8tr @.***> wrote:

Tried a different screen and same outcome.

Random thought, I wonder if for some reason the 5's handle the screen resolution different from the 3s or 4s. Surely it's not the adapter I'm using to go from micro-hdmi to hdmi.

Will try a fresh OS and pull and report back hopefully here soon.

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2212523412, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E4Y6HI5D7MNCWR36ODZLF6RTAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGUZDGNBRGI . You are receiving this because you commented.Message ID: @.***>

[Carbur8tr]

Started fresh and same outcome:

Jul 07 13:59:54 RTSP systemd[1]: piplay.service: Scheduled restart job, restart counter is at 2. Jul 07 13:59:54 RTSP systemd[1]: Stopped piplay.service - PIPlay. Jul 07 13:59:54 RTSP systemd[1]: piplay.service: Consumed 1.050s CPU time. Jul 07 13:59:55 RTSP systemd[1]: Started piplay.service - PIPlay. Jul 07 13:59:56 RTSP startup.sh[6586]: drmModeGetResources failed (Operation not supported) Jul 07 13:59:56 RTSP startup.sh[6586]: no screens available, assuming 24-bit color Jul 07 13:59:56 RTSP startup.sh[6586]: Cannot create window: no screens available Jul 07 13:59:56 RTSP startup.sh[6585]: /opt/piplay/startup.sh: line 6: 6586 Aborted python3 /opt/piplay/piplay.py

I'm assuming you were referring to changing the VNC resolution in Raspi-Config, in which case I set it to the native resolution of the screen and still same result.

At this point I'm thinking that I need to look a little further into recompiling QT. Not really sure how at this point but from most of what I read it's pointing back to a potential issue in that area.

[HussX]

Actually I meant the x display back end, although I doubt it should relate being lite. But they did change it in the July release. Under Advanced and then Wayland. If that does it, it's a simple flag change on the startup script.

On Sun, Jul 7, 2024, 15:06 Carbur8tr @.***> wrote:

Started fresh and same outcome:

Jul 07 13:59:54 RTSP systemd[1]: piplay.service: Scheduled restart job, restart counter is at 2. Jul 07 13:59:54 RTSP systemd[1]: Stopped piplay.service - PIPlay. Jul 07 13:59:54 RTSP systemd[1]: piplay.service: Consumed 1.050s CPU time. Jul 07 13:59:55 RTSP systemd[1]: Started piplay.service - PIPlay. Jul 07 13:59:56 RTSP startup.sh[6586]: drmModeGetResources failed (Operation not supported) Jul 07 13:59:56 RTSP startup.sh[6586]: no screens available, assuming 24-bit color Jul 07 13:59:56 RTSP startup.sh[6586]: Cannot create window: no screens available Jul 07 13:59:56 RTSP startup.sh[6585]: /opt/piplay/startup.sh: line 6: 6586 Aborted python3 /opt/piplay/piplay.py

I'm assuming you were referring to changing the VNC resolution in Raspi-Config, in which case I set it to the native resolution of the screen and still same result.

At this point I'm thinking that I need to look a little further into recompiling QT. Not really sure how at this point but from most of what I read it's pointing back to a potential issue in that area.

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2212540864, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E5WM5ZOYHWYZP2QZ4TZLGGTVAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGU2DAOBWGQ . You are receiving this because you commented.Message ID: @.***>

[Carbur8tr]

Tried both X11 and Wayfire, same result.

[HussX]

I haven't changed this on the 4, but does it match on the 5? In /boot/firmware/config.txt

Enable DRM VC4 V3D driver

dtoverlay=vc4-kms-v3d max_framebuffers=2

On Sun, Jul 7, 2024, 16:07 Carbur8tr @.***> wrote:

Tried both X11 and Wayfire, same result.

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2212556339, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E3YLUJFXJ6VO6OSHRTZLGNZNAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGU2TMMZTHE . You are receiving this because you commented.Message ID: @.***>

[Carbur8tr]

[HussX]

Those match 😑 There has to be something simple. I can't wait to get my hands on a 5. I may grab an extra one on the road.

On Sun, Jul 7, 2024, 20:07 Carbur8tr @.***> wrote:

IMG_0317.jpeg (view on web) https://github.com/HussX/piplay/assets/58281811/e7f0b794-e658-40bf-8cc3-7b5f31d907f2

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2212632612, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E322MAIUL23GSHMXXTZLHJ4JAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGYZTENRRGI . You are receiving this because you commented.Message ID: @.***>

[Carbur8tr]

No worries, I really do appreciate you entertaining this.

In the meantime I might start fresh and play with a couple of the imports. I was reading on an opencv-headless and contrib that seemed interesting but need to read more.

[HussX]

I thought about trying out headless and using a venv, but I felt better about using apt-packages despite being more likely to change. And apologies, I haven't had a chance to attempt to look at this yet. I've been hammered with remote issues.

[Carbur8tr]

I haven't had time to mess with it myself either. I'll be curious to see if you can find anything anything.

My luck it would be something simple and stupid on my end.

[HussX]

Verified this. I pulled my working SD and dropped it in a 5, I see the exact same thing. Digging into it now while I have a short chance.

[HussX]

Tested this on a 5 and then moved the SD back to 4 to verify it didn't break anything. Please test!

[Carbur8tr]

I read through the startup file. Easy enough, will test tonight and report back.

[HussX]

Sorry for all the delays. A ton of work projects took priority.

[Carbur8tr]

To confirm, everything appears to be working now as it should. Many thanks!

Question, have you noticed that the grid likes to resize quite a bit over a period of time? I have a 3x3 grid currently and at first launch all squares look equally sized. After running for some time now I noticed that the top and middle row are growing and the bottom row is shrinking. (If that makes any sense). Just curious if this a configuration issue on my end?

[HussX]

@Carbur8tr Actually I haven't noticed that. I've had this running on my desk for weeks and everything looked normal, mind you that's on a 4. I'll have to do some more extensive testing on a 5. Glad it's working, though!

The only time I've seen any odd sizing is if a resolution was changed mid stream or when a camera was reconnecting. Is there anything odd in the logs?

[Carbur8tr]

Interesting you should ask, I am getting quite a few disconnects and reconnects "using backend 1900."

[HussX]

I had to look that up.. :) 1900 is FFMPEG.

[HussX]

How does htop look while running? I'm not sure that it's using hardware acceleration. I haven't tested for steam limits with various models since it'll depend on resolutions and frame rates as well as screen resolution. All my use cases are 6 cams or less but I wouldn't mind getting this tweaked for as many people to use as possible.

On Thu, Aug 1, 2024, 14:40 Carbur8tr @.***> wrote:

Interesting you should ask, I am getting quite a few disconnects and reconnects "using backend 1900."

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2263725848, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2E2HMDIDXKHTNT74PGTZPJ6KNAVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTG4ZDKOBUHA . You are receiving this because you modified the open/close state.Message ID: @.***>

[Carbur8tr]

Looks great when it first launches and it doesn't look bad when it's been up for a bit and resizes, but rather just odd because it will compress the bottom row.

In total there are 9 cameras I'm displaying but I can try less or more if you would like. I think the disconnects are mainly why this is happening. The odd part is that all of the streams seem to play great at their native frame rates (30fps) until there's a disconnect. Then it will quickly reconnect and sometimes resize.

[HussX]

I'm back out of state at the moment but I'll look into the resizing. I'm 95% sure I know why. As to the reconnects, I wonder if we're throttling somewhere. Are you running full resolution streams or are they lower resolution to keep closer to the on screen downsizing/down sampling?

On Sat, Aug 3, 2024, 21:53 Carbur8tr @.***> wrote:

Looks great when it first launches and it doesn't look bad when it's been up for a bit and resizes, but rather just odd because it will compress the bottom row.

In total there are 9 cameras I'm displaying but I can try less or more if you would like. I think the disconnects are mainly why this is happening. The odd part is that all of the streams seem to play great at their native frame rates (30fps) until there's a disconnect. Then it will quickly reconnect and sometimes resize.

— Reply to this email directly, view it on GitHub https://github.com/HussX/piplay/issues/6#issuecomment-2267266189, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZ2EZOOIKDNKZHMCCKAJTZPWJS3AVCNFSM6AAAAABKONZO32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGI3DMMJYHE . You are receiving this because you modified the open/close state.Message ID: @.***>

[HussX]

@Carbur8tr I pushed another slight change for static panel sizes which should stop the resizing over time. I'm still digging in on what I can do to optimize things a bit.