Actually make the existing ioctls for adding and removing drawables do
something useful, and add another ioctl for the X server to update drawable
information. The only kind of drawable information tracked so far is cliprects.

Only reallocate cliprect memory if the number of cliprects changes.
Also improve diagnostic output.

hook up drm ioctl update draw
export drm_get_drawable_info symbol
Signed-off-by: NDave Airlie <airlied@linux.ie>

Signed-off-by: NDave Airlie <airlied@linux.ie>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Signed-off-by: NDave Airlie <airlied@linux.ie>

I've been threatening this for a while, so no point hanging around.
This lindents the DRM code which was always really bad in tabbing department.
I've also fixed some misnamed files in comments and removed some trailing
whitespace.
Signed-off-by: NDave Airlie <airlied@linux.ie>

This converts the drm_handle_t to unsigned int.
This is currently safe to do as we don't pass these across the kernel/user
boundary, but userspace does use these, but no-one builds userspace against
the kernel headers at present so it is okay to switch over the kernel copy
of drm.h at this point. (The CVS tree will switch over soon in sync with
some Mesa changes)

From: Egbert Eich <eich@suse.de>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The patch makes drmAddBufs/drmMapBufs can handle buffers in video memory

The attached patch adds a new buffer type DRM_FB_BUFFER. It works like
AGP memory but uses video memory.

From: Austin Yuan <austinyuan@viatech.com.cn>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Added a new DRM map type _DRM_CONSISTENT for consistent PCI memory. It
uses drm_pci_alloc/free for allocating/freeing the memory.

From: Felix Kuhling <fxkuehl@gmx.de>
Signed-off-by: NDavid Airlie <airlied@linux.ie>

This file can be included from userspace so wrap the config.h include.
Signed-off-by: NDavid Airlie <airlied@linux.ie>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!