Standalone DRM application

[Ilija Hadzic]

On Thu, 18 Apr 2013, David Herrmann wrote:

> Hi
>
> On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek <gandalf at winds.org> wrote:
>> David,
>>
>> I'm developing a small application that uses libdrm (DRM ioctls) to change
>> the
>> resolution of a single graphics display and show a framebuffer. I've run
>> into
>> two problems with this implementation that I'm hoping you can address.
>>
>>
>> 1. Each application is its own process, which is designed to control 1
>> graphics
>> display. This is unlike X, for instance, which could be configured to grab
>> all
>> of the displays in the system at once.
>>
>> Depending on our stackup, there can be as many as 4 displays connected to a
>> single graphics card. One process could open /dev/dri/card0 and call
>> drmModeSetCrtc() to initialize one of its displays to the requested
>> resolution.
>> However, whenever a second process calls drmModeSetCrtc() to control a
>> second
>> display on the same card, it gets -EPERM back from the ioctl.
>>
>> I've traced this down to the following line in
>> linux/drivers/gpu/drm/drm_drv.c:
>>
>> DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
>> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>
>> If I remove the DRM_MASTER flag, then my application behaves correctly, and
>> 4
>> separate processes can then control each individual display on the card
>> without
>> issue.
>>
>> My question is, is there any real benefit to restricting drm_mode_setcrtc()
>> with DRM_MASTER, or can we lose this flag in order to support
>> one-process-per-
>> display programs like the above?
>
> Only one open-file can be DRM-Master. And only DRM-Master is allowed
> to perform mode-setting. This is to prevent render-clients (like
> OpenGL clients) to perform mode-setting, which should be restricted to
> the compositor/...
>
> In your scenario, you should share a single open-file between the
> processes by passing the FDs to each. Or do all of that in a single
> process. There is no way to split CRTCs/connectors between different
> nodes or have multiple DRM-Masters on a single node at once. (There is
> work going on to allow this, but it will take a while...)
>

If running a custom-patched kernel is acceptable (i.e. custom-built, 
embedded system or the like), then a set of patches that I sent about a 
year ago [1] will probably do the job. The problem is that these patches 
are apparently not going upstream because there was little interest and 
there were a couple of arguments against them [2]. Originally, it's the 
work that Dave Airlie started but abandoned. I finished it off and tried 
to have it included upstream but it didn't happen.

I have an application that is similar to what is described here and I am 
using these patches to make it work. Essentially, what you do is call a 
small userspace utility (also included with the patches for libdrm) and 
specify which CRTCs/encoders/connectors/planes do you want included in the 
node and you get a new /dev/dri/render<N> node that your application can 
use and be the master on these resources only. Then for the next node you 
call the utility again and specify a new set of display resources and then 
you run the other application on the top of that node.

The patches that are on the mailing list archive [1] are now a year old, 
but I have a rebased version for newer kernels, which I can send to 
whoever is interested in having them (I am just hesitating to pollute the 
mailing list with patches to which the maintainers have already said 
"no").

[1] http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html
[2] http://lists.freedesktop.org/archives/dri-devel/2012-September/028348.html

-- Ilija