StuartF
Posts: 35
Joined: Sun Feb 02, 2014 5:41 pm

Pi4 gbm needs 'sudo' ?

Thu Feb 20, 2020 1:04 pm

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?

User avatar
topguy
Posts: 6886
Joined: Tue Oct 09, 2012 11:46 am
Location: Trondheim, Norway

Re: Pi4 gbm needs 'sudo' ?

Thu Feb 20, 2020 1:29 pm

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
Posts: 121
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Pi4 gbm needs 'sudo' ?

Thu Feb 20, 2020 1:35 pm

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
Posts: 35
Joined: Sun Feb 02, 2014 5:41 pm

Re: Pi4 gbm needs 'sudo' ?

Thu Feb 20, 2020 3:40 pm

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.

Return to “OpenGLES”