linux-kernel - Re: Standalone DRM application

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Apr 2013 09:42:46 -0500 (CDT)
From:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
To:	David Herrmann <dh.herrmann@...il.com>
cc:	Byron Stanoszek <gandalf@...ds.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: Standalone DRM application

On Thu, 18 Apr 2013, David Herrmann wrote:

> Hi
>
> On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek <gandalf@...ds.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/