I'm not 100% sure that the nv94 one we were using won't work. The context
layouts are identical (well.. same ctxprog, so of course!), only a couple
of registers differ. But, be safe until we actually get some 9xxx chips
working.
Our PFIFO/PGRAPH context save/load functions don't really work well
(at all?) on nv5x yet. Depending on what random state the card is
in before the drm loads, fbcon probably won't work correctly.
Luckily we've setup the GPU in such a way that it'll actually do a
hw context switch for the first context. Not sure of how successful
this'd be currently on the older chips (actually, pretty sure it won't
work), so NV50 only for now.
This patch tries to use the available fence count to figure out whether a
given batch can succeed or not (just like the aperture check).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
drm_fops.c reads the current process' EUID directly from task_struct.
Apparently starting in 2.6.28-rc4 this fails to build.
In Linus' tree, commit b6dff3ec5e116e3af6f537d4caedcad6b9e5082a
"CRED: Separate task security context from task_struct"
moves the euid field from task_struct to another struct.
Earlier commit 9e2b2dc4133f65272a6d3c5dcb2ce63f8a87cae9
"CRED: Introduce credential access wrappers" implements the wrapper
macros to access e.g. euid. This is in 2.6.27-rc4, and this contains the
definition of current_euid() that will be used in the DRM compatibility header
for kernels before 2.6.27. That commit also creates <linux/cred.h>, which
contains the upstream definition of current_euid().
drm_fops.c is fixed to use current_euid(), and drm_compat.h will offer
the compatibility definition for kernels <2.6.27.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
It is impossible to replace the original semantics of this call purely
in userland, since the fb_id would change.
after discussion with Dr_Jakob
Signed-Off-By: Owain Ainsworth <oga@openbsd.org>
Acked-By: Jakob Bornecrantz <jakob@vmware.com>
Michel caught a case where we might overwrite a success or other return
value with EBUSY, so check the return value before checking for the
timeout condition.
In some cases, vblank interrupts may be disabled or otherwise broken.
The kernel has a 3s timeout builtin to handle these cases, but the X
server's SIGALM for cursor handling may interrupt vblank wait ioctls,
causing libdrm to restart the ioctl, making the kernel's timeout
useless.
This change tracks time across ioctl restarts and returns EBUSY to the
caller if the expected vblank sequence doesn't occur within 1s of the
first call.
Fixes fdo bz #18041, which is caused by a drmWaitVBlank hanging due to
the corresponding pipe getting disabled (thus preventing further events
from coming in).
The values are really going to continue meaning pipe, not plane, and that's
what they're called in the kernel copy of the header. Userland hasn't ever
made the switch to pipe!=plane, since userland checks are based on DRM
version, which is still stuck at 1.6. However, Mesa did start using
plane[AB] names, so provide a compat define.
Remember tiling mode values provided by appplications, and
record tiling mode when creating a buffer from another application. This
eliminates any need to ask the kernel for tiling values and also makes
reused buffers get the right tiling.
Signed-off-by: Keith Packard <keithp@keithp.com>
Applications may actually care if the mapping operation failed, so when
it happens, return an error indication. errno is probably trashed by
fprintf though.
Signed-off-by: Keith Packard <keithp@keithp.com>
The execbuffer ioctl returns ENOMEM when it fails to pin all of the buffers
in the GTT. This is usually caused by the DRM client attempting to use too
much memory in a single request. Dumping out the requested and available
memory values should help point out failures in the DRM code to catch over
commitments of this form.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add mode setting files to libdrm, including xf86drmMode.* and the new
drm_mode.h header. Also add a couple of tests to sanity check the
kernel interfaces and update code to support them.
Ben Skeggs
Stuart Bennett
Kristian Høgsberg
Stephane Marchesin
Stuart Bennett
Eric Anholt
Jesse Barnes
Pekka Paalanen
Dave Airlie
Owain G. Ainsworth
Robert Noland
Dave Airlie
Keith Packard