Pi4 gbm needs 'sudo' ?

[StuartF]

I am currently updating a program using openGL2 using dispmanx from the pi3 to openGL3 using DRM.
Everything was going generally ok, until I hit a brick wall.

The problem was gbm_surface_lock_front_buffer always returning NULL after eglSwapBuffers.

So after going through the code and checking all the formats, encoder, connectors and resources stuff ( many hours ) I decided to try running as 'sudo'.

Then it worked.

I know the 'make a cup a tea' thing can apply to this, but I was wondering it this is a problem or if I have to run as sudo as a matter of fact.
The opengl2 version could be run without sudo, as a normal user.

This is for a full screen, non X-win framebuffer setup.

Any suggestions?

[topguy]

I saw this in the usage guide for "flutter-pi" sounds relevant for you question..

Adding "pi" user to the "render" group.

Code: Select all

usermod -a -G render pi

[Daniel Gessel]

It shouldn’t require sudo... have you tried kmscube on your system? I based my GBM/KMS code on the legacy mode setting path and haven’t needed sudo (though I haven’t upgraded to the latest OS update).

[StuartF]

Thanks for the replys

@topguy
ironically i had to

Code: Select all

sudo usermod -a -G render pi

but that did nothing.

@Daniel Gessel
Looking at kmscube, it seems to be GL2, and have 'legacy' fallback.
I'm running the latest buster, so it might be different.

So a new day, from a fresh boot, I ran the program without sudo and then got something different.

eglMakeCurrent and eglSwapBuffers both produce
failed to export dumb buffer: Permission denied
Failed to create scanout resource

Then the gbm fails to give the bo handle.

So It isn't gbm that is at fault, it's egl. The fail message output is latent.
Verified by adding usleep after commands and before a printf for results.

For now running as sudo isn't that much of a problem, but if I ever find out what is going on I'll post it.