All of
 help / color / mirror / Atom feed
From: Ilija Hadzic <>
Subject: libdrm part of the render-node patch series
Date: Thu, 29 Mar 2012 12:46:44 -0400	[thread overview]
Message-ID: <> (raw)

The following two patches add libdrm support for render node
manipulation. The first patch adds the functions for render
node creation and removal that an application can call.
The second patch add two small test utilities that allow
render node creation and removal from shell.

For example, this will create a render node with one CRTC, one
encoder and one connector and use object IDs 10, 16, and 17 for
CRTC, encoder and connector respectively 

<libdrm>/tests/render_nodes/render_node_add -c 1 -e 1 -p 1 -l 10,16,17

To find out object IDs for your GPU you can use <libdrm>/tests/modeprint
test utility.

Kernel will check that the IDs are valid (i.e. that CRTC is really a CRTC)
and not in use by some other render node, but it will not (yet) check
the interdependency (e.g., if a given encoder can go with a given connector).
The latter is still on TODO list.

To remove the render node use

<libdrm>/tests/render_nodes/render_node_rm -m <minor>

To specify the render node with no display resources (typically for
GPGPU ise), just type render_node_add without arguments.

By default, the test utility will use /dev/dri/controlD64 device, which
is a control node for the first GPU in the system. That can be changed
with -n <node> parameter but the node must be a control node (can't
issue the ioctl through other render node or through the physical card

At this point, the biggest missing thing is the ability to specify the
render node in xorg.conf. So to test this for multiseat-X use case
you still need a hack from Dave Airlie [1] and you need to setup
an environment variable to point X to the right render node [2,3,4 
-- customize for your system]

The following is a list of various problems that still need to
be worked out before this becomes stable (help appreciated).
I have not looked into the details so I have no idea what the causes
are nor how they are related to the fact that it's running
on a render node, but I list them here:

* If I start a seat from fbcon, Gnome 3 would sometimes hang up
  (workaround: ssh to the target machine from another machine and
  start a seat from there)
* Native XFCE terminal acts up (typing in it crashes the window
* Typing in Gnome terminal, makes input characters leak into
  the running fbcon.
* Sending DPMS event from a seat that uses the render node makes
  the screen go dark and never recover
* Killing the glxgears window sometimes causes the whole
  session to be killed.

Barring the above issues, that clearly need to be fixed before
render-nodes can become generally useful, things seem to be
cranking. I was able to run the session in various desktop managers,
run with desktop effects turned on, play games and run various
OpenGL demos.




             reply	other threads:[~2012-03-29 16:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 16:46 Ilija Hadzic [this message]
2012-03-29 16:46 ` [PATCH 1/2] libdrm: add functions for render node manipulation Ilija Hadzic
2012-03-29 16:46 ` [PATCH 2/2] tests: add render_node tests Ilija Hadzic

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:

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

  git send-email \ \ \ \

* 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.