All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres@free.fr>
To: dri-devel@lists.freedesktop.org
Subject: [RFC] Complete experimental render node implementation
Date: Mon, 17 Dec 2012 02:42:00 +0100	[thread overview]
Message-ID: <50CE7868.4040205@free.fr> (raw)

Hi,

Following to my shared talk with krh, danvet and Timothée Ravier @ 
XDC2012, I have
actually taken the time to start fixing some security holes found in the 
graphics stack.

Today, I would like to request your comments on the render node 
patchset. Keep in mind that I am
not asking for inclusion. However, I know this patchset works on my 
nvidia card and I would like
to know if anyone has anything against this architecture.

## DRM
If I'm not mistaken, the idea originated from airlied which got 
simplified later by krh.
Both only provided drm patches.

Here is what I did:
- I took krh's patchset
- rebased it on top on drm 3.7-rc8
- added support for Nouveau
- fixed a few bugs along the way (as stated in the commit logs)

The kernel can be found here: 
https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes
The patches will also be sent in reply, to let you comment on specific 
parts of the patches.

## Libdrm

Here are the two main goals of this patchset:
- Add a new symbol called drmOpenType that allows to open a specific 
type of device (usual node, render node)
- Add a new symbol called drmGetSameDeviceButType to get the path to the 
same drm_device but with a different type

The patches are available here: http://cgit.freedesktop.org/~mperes/drm/

## DRI2Proto

What we want here is to let the ddx send the render node instead of the 
usual one.
However, authentication is not necessary and not shouldn't be done on a 
render node.

This modification to DRI2Proto adds a boolean in the Connection response 
to tell the dri2 client
that no authentication is required.

The patches are available here: 
http://cgit.freedesktop.org/~mperes/dri2proto/

## XServer

The X-Server is responsible for collecting the DRI2 informations from 
the ddx.
In this patch, we provide the way for the ddx to specify whether the 
DRI2 client should authenticate or not.

The patches are available here: http://cgit.freedesktop.org/~mperes/xserver/

## xf86-video-nouveau

In this patch, we simply tell the DRI2 extension to use the render node if
available (using drmGetSameDeviceButType), and if it is the case,
we set the "require_authentication" attribute to 0.

The patches are available here: 
http://cgit.freedesktop.org/~mperes/xf86-video-nouveau/

## Mesa

In this patch, I simply check whether I should authenticate or not using 
the information
from the DRI2 protocol.

The patches are available here: http://cgit.freedesktop.org/~mperes/mesa/

Cheers,

Martin

             reply	other threads:[~2012-12-17  1:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-17  1:42 Martin Peres [this message]
2012-12-17  1:47 ` [PATCH 1/4] drm: Fix DRM_MINOR limits for control and render nodes martin.peres
2012-12-17  1:48   ` [PATCH 2/4] drm: Add support for " martin.peres
2012-12-17  1:48   ` [PATCH 3/4] drm/i915: Support " martin.peres
2012-12-17  1:48   ` [PATCH 4/4] drm/nouveau: " martin.peres
2012-12-17  2:02 ` [PATCH 1/5] drm: allow opening the drm device by type (control, render or render_only) martin.peres
2012-12-17  2:02   ` [PATCH 2/5] drm: generate the path of a different device type for the same drm device martin.peres
2012-12-17  2:02   ` [PATCH 3/5] nouveau: Allow opening a specific type of " martin.peres
2012-12-17  2:02   ` [PATCH 4/5] nouveau: bump version to 2.4.34 for release martin.peres
2012-12-17  2:02   ` [PATCH 5/5] configure.ac: bump version to 2.4.41 " martin.peres
2012-12-17  2:06 ` [PATCH] dri2proto: add device_requires_auth in xDRI2ConnectReply to support render nodes martin.peres
2012-12-17  2:09 ` [PATCH] dri2: add support for " martin.peres
2012-12-17  2:10 ` [PATCH] " martin.peres
2012-12-17  2:13 ` [PATCH] dri2: " martin.peres
2012-12-18 12:03 ` [RFC] Complete experimental render node implementation Daniel Vetter
2012-12-18 12:23   ` Martin Peres
  -- strict thread matches above, loose matches on Subject: below --
2012-12-17  1:39 Martin Peres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50CE7868.4040205@free.fr \
    --to=martin.peres@free.fr \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.