libdrm part of the render-node patch series

[Ilija Hadzic <ihadzic@research.bell-labs.com>]

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
node).

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

Regards,
Ilija

----

[1] http://people.freedesktop.org/~airlied/multiseat/0001-libdrm-add-support-for-an-env-variable-to-override-t.patch
[2] http://people.freedesktop.org/~airlied/multiseat/xorg.conf
[3] http://people.freedesktop.org/~airlied/multiseat/start1
[4] http://people.freedesktop.org/~airlied/multiseat/start2