[SOLVED] Why does KMS drmModeSetCrtc() fail with permission denied while running in X11 session?

Why does KMS drmModeSetCrtc() fail with permission denied while running in X11 session?

The title already implies the question, so what is blocking the execution from the sample program in this repo https://github.com/dvdhrm/docs/tree/master/drm-howto

It's a simple program showing KMS in action, so I downloaded it, compiled it and gave it a run. This was the output:

michael@lord:~/Downloads/docs/drm-howto$ sudo ./modeset
[sudo] password for michael: 
using card '/dev/dri/card0'
mode for connector 59 is 1920x1080
ignoring unused connector 68
ignoring unused connector 71
ignoring unused connector 75
cannot set CRTC for connector 59 (13): Permission denied
exiting

Also note that I have a running X11 session on my machine. It seems X is already using the device /dev/dri/card0 and blocks it for all other programs.

Here is my video card:

michael@lord:~/Downloads/docs/drm-howto$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)

I have also added i915.modeset=1 into /etc/initramfs-tools/modules and rebuilt it with sudo update-initramfs -u so it loads the driver from inside my kernel and not from the xorg side.

There is also the possibility that my driver doesn't support KMS but lspci has shown that I only have an internal intel graphics card installed. So I sticked with the xorg core display driver package which is installed by default from xserver-xorg-core.

None of these changes have taken affect. The only way I can execute those examples is by killing the xorg session and let it run in tty.

Any ideas?

Solution

It works as expected. Only DRM-Master is allowed to do modesetting, and there can only be one DRM-Master. X is already master.

You can become master using drmSetMaster() or implicitly by opening the the primary device node when there is no current master. (The example code becomes DRM-Master implicitly.)