| Age | Commit message (Collapse) | Author |
|---|
|
This also means, that DRM_FULL_MM_COMPAT is always defined,
so it is dropped, too.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
This also means dropping the DRM_ODD_MM_COMPAT case.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
The commit 957b10695b619d6ed2f1098b00502395d9a3c149, "Move vblank_init
to driver load time." forgot to add the function declaration in
linux-core/drmP.h.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
|
|
Loading nouveau.ko would fail with unknown symbols, if the backlight
class device support is not provided in the kernel. Let's make the
backlight support dependant on the kernel configuration.
This is a bit ugly, the proper way would be to check for the config in
Makefile.kernel whether to build nouveau_backlight.o at all, and if not,
nouveau_drv.h should provide the stubs.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Several nvidia-based systems don't support backlight control via the
standard ACPI control mechanisms. Instead, it's necessary for the driver
to modify the backlight control registers directly. This patch adds
support for determining whether the registers appear to be in use, and
if so registers a kernel backlight device to control them. The backlight
can then be controlled via existing userspace tools.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
This function is unused, and yet creates build problems: the symbol
init_mm is not exported by the latest -rc kernels and I don't believe it
ever will be. Even CONFIG_UNUSED_SYMBOLS does not provide it anymore.
If this function is needed in the future, it needs to be reinvented in
any case. So remove it.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Intel developers have stated, that their DRM development continues
elsewhere in some Linux kernel trees. This makes the code in drm.git
just dead weight. This removal allows further cleanup of compatibility
code.
shared-core and bsd-core are left untouched this time.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Acked-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>
|
|
pointed out by pq
|
|
The code's in the linux kernel.
|
|
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.
|
|
This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208.
We really just want the libdrm and ioctl bits, not all the driver
stuff.
|
|
into modesetting-gem
|
|
This reverts commit f46aba43329786c9b2776e82af31d90e1c67eae0.
|
|
There seems to be an issue if we don't protect idr_pre with
the spinlock we use for idr operations.
|
|
|
|
Conflicts:
libdrm/Makefile.am
libdrm/intel/intel_bufmgr.h
libdrm/intel/intel_bufmgr_fake.c
libdrm/intel/intel_bufmgr_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_irq.c
shared-core/radeon_cp.c
shared-core/radeon_drv.h
|
|
|
|
|
|
Relocation now consist of the following informations (in this order) :
handle buffer object handle identifier
start_offset start offset of first data of the buffer object used by the cs
end_offset end offset of last data of the buffer object used by the cs
read_domain read domain (either VRAM, or GTT as GPU is invalid for CS)
write_domain write domain (either VRAM, or GTT as GPU is invalid for CS)
flags flags used for further optimization (like discard previous
buffer content or forget buffer content after cs which can
help in avoiding moving content in or out)
|
|
|
|
|
|
For some reason reading the SCRATCH reg from RAM causes some race to occur.
Hopefully fix this.
|
|
|
|
fixes cursor on second head
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows the rs690 to work on DVI
|
|
|
|
emit in 16-dword blocks, emit irqs at same time as everything else
|
