16 Nov, 2011
2 commits
-
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file. Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)Signed-off-by: Ville Syrjälä
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Signed-off-by: Jesse Barnes
Signed-off-by: Dave Airlie -
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.v2: fix ABI of get_plane - move format_type_ptr to the end
v3: add 'flags' field for interlaced support (from Ville)Acked-by: Alan Cox
Reviewed-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Jesse Barnes
Signed-off-by: Dave Airlie
24 Mar, 2011
1 commit
-
This makes the interface a bit cleaner by leaving a single gap in the
vblank bit space instead of creating two gaps.Suggestions from Michel on mailing list/irc.
Reviewed-by: Michel Dänzer
Signed-off-by: Dave Airlie
21 Mar, 2011
1 commit
-
Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two threads:http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.htmlThis patch extends the interface to drm_wait_vblank ioctl so that crtc>1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back to the legacy interface if not)Signed-off-by: Ilija Hadzic
Reviewed-by: Mario Kleiner
Acked-by: Mario Kleiner
Reviewed-by: Alex Deucher
Tested-by: Alex Deucher
Signed-off-by: Dave Airlie
04 Mar, 2011
2 commits
-
This allows libkms to make an easier decision.
Signed-off-by: Dave Airlie
-
We're coming to see a need to have a set of generic capability checks in
the core DRM, in addition to the driver-specific ioctls that already
exist.This patch defines an ioctl to do as such, but does not yet define any
capabilities.[airlied: drop the driver callback for now.]
Signed-off-by: Ben Skeggs
Signed-off-by: Dave Airlie
07 Feb, 2011
1 commit
-
This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.Signed-off-by: Dave Airlie
04 Aug, 2010
1 commit
-
I wrote this for the prime sharing work, but I also noticed other external
non-upstream drivers from a large company carrying a similiar patch, so I
may as well ship it in master.Signed-off-by: Dave Airlie
08 Dec, 2009
1 commit
-
This merges the upstream Intel tree and fixes up numerous conflicts
due to patches merged into Linus tree later in -rc cycle.Conflicts:
drivers/char/agp/intel-agp.c
drivers/gpu/drm/drm_dp_i2c_helper.c
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/i915_suspend.c
04 Dec, 2009
2 commits
-
This commit adds a ioctl and property to allow userspace
to notify the kernel that a framebuffer has changed. Instead
of snooping the command stream this allows finer grained
tracking of which areas have changed.The primary user for this functionality is virtual hardware
like the vmware svga device, but also Xen hardware likes to
be notify. There is also real hardware like DisplayLink and
DisplayPort that might take advantage of this ioctl.Signed-off-by: Jakob Bornecrantz
Signed-off-by: Dave Airlie -
This let's use use the linux drm headers as the canonical source for
libdrm on all platforms.Signed-off-by: Kristian Høgsberg
Signed-off-by: Dave Airlie
02 Dec, 2009
1 commit
-
We don't actually know which frame number the flip will complete on, so
userspace needs a specific flip notification to tell it when the last flip
completed.Signed-off-by: Jesse Barnes
Signed-off-by: Eric Anholt
Acked-by: Kristian Høgsberg
18 Nov, 2009
2 commits
-
This adds a page flipping ioctl to the KMS API. The ioctl takes an fb ID
and a ctrc ID and flips the crtc to the given fb at the next vblank.
The ioctl returns immediately but the flip doesn't happen until after
any rendering that's currently queued up against the new framebuffer
is done. After submitting a page flip, any execbuffer involving the
old front buffer will block until the flip is completed.Optionally, a vblank event can be generated when the swap eventually
happens.Signed-off-by: Kristian Høgsberg
Reviewed-by: Chris Wilson
Signed-off-by: Dave Airlie -
This patch adds a new flag to the drmWaitVblank ioctl, which asks the drm
to return immediately and notify userspace when the specified vblank sequence
happens by sending an event back on the drm fd.The event mechanism works with the other flags supported by the ioctls,
specifically, the vblank sequence can be specified relatively or absolutely,
and works for primary and seconday crtc.The signal field of the vblank request is used to provide user data,
which will be sent back to user space in the vblank event.Signed-off-by: Kristian Høgsberg
Reviewed-by: Jesse Barnes
Signed-off-by: Dave Airlie
27 Mar, 2009
1 commit
-
The drm headers are traditionally shared with BSD and
could not use the strict linux integer types. This is
over now, so we can use our own types now.Cc: David Airlie
Signed-off-by: Arnd Bergmann
Signed-off-by: H. Peter Anvin
Signed-off-by: Ingo Molnar
28 Jan, 2009
1 commit
-
Schedule a vblank signal, kill the process, and we'll go walking over freed
memory. Given that no open-source userland exists using this, nor have I
ever heard of a consumer, just let this code die.Signed-off-by: Eric Anholt
Requested-by: Linus Torvalds
Acked-by: Dave Airlie
Signed-off-by: Linus Torvalds
29 Dec, 2008
4 commits
-
The replace fb ioctl replaces the backing buffer object for a modesetting
framebuffer object. This can be acheived by just creating a new
framebuffer backed by the new buffer object, setting that for the crtcs
in question and then removing the old framebuffer object.Signed-off-by: Kristian Hogsberg
Acked-by: Jakob Bornecrantz
Signed-off-by: Dave Airlie -
Add mode setting support to the DRM layer.
This is a fairly big chunk of work that allows DRM drivers to provide
full output control and configuration capabilities to userspace. It was
motivated by several factors:
- the fb layer's APIs aren't suited for anything but simple
configurations
- coordination between the fb layer, DRM layer, and various userspace
drivers is poor to non-existent (radeonfb excepted)
- user level mode setting drivers makes displaying panic & oops
messages more difficult
- suspend/resume of graphics state is possible in many more
configurations with kernel level supportThis commit just adds the core DRM part of the mode setting APIs.
Driver specific commits using these new structure and APIs will follow.Co-authors: Jesse Barnes , Jakob Bornecrantz
Contributors: Alan Hourihane , Maarten MaathuisSigned-off-by: Jesse Barnes
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
Add core support for mapping of GEM objects. Drivers should provide a
vm_operations_struct if they want to support page faulting of objects.
The code for handling GEM object offsets was taken from TTM, which was
written by Thomas Hellström.Signed-off-by: Jesse Barnes
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
This is step one towards having multiple masters sharing a drm
device in order to get fast-user-switching to work.It splits out the information associated with the drm master
into a separate kref counted structure, and allocates this when
a master opens the device node. It also allows the current master
to abdicate (say while VT switched), and a new master to take over
the hardware.It moves the Intel and radeon drivers to using the sarea from
within the new master structures.Signed-off-by: Dave Airlie
18 Oct, 2008
3 commits
-
GEM allows the creation of persistent buffer objects accessible by the
graphics device through new ioctls for managing execution of commands on the
device. The userland API is almost entirely driver-specific to ensure that
any driver building on this model can easily map the interface to individual
driver requirements.GEM is used by the 2d driver for managing its internal state allocations and
will be used for pixmap storage to reduce memory consumption and enable
zero-copy GLX_EXT_texture_from_pixmap, and in the 3d driver is used to enable
GL_EXT_framebuffer_object and GL_ARB_pixel_buffer_object.Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
Previously, drivers supporting vblank interrupt waits would run the interrupt
all the time, or all the time that any 3d client was running, preventing the
CPU from sleeping for long when the system was otherwise idle. Now, interrupts
are disabled any time that no client is waiting on a vblank event. The new
method uses vblank counters on the chipsets when the interrupts are turned
off, rather than counting interrupts, so that we can continue to present
accurate vblank numbers.Co-author: Michel Dänzer
Signed-off-by: Jesse Barnes
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
There is no point in considering FreeBSD et al. in the linux kernel
source code.Signed-off-by: Carlos R. Mafra
Signed-off-by: Andrew Morton
Signed-off-by: Dave Airlie
14 Jul, 2008
1 commit
-
With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach was getting very ugly and
starting to be unmanageable.This restructures the drm along the lines of other kernel components.
It creates a drivers/gpu/drm directory and moves the hw drivers into
subdirectores. It moves the includes into an include/drm, and
sets up the unifdef for the userspace headers we should be exporting.Signed-off-by: Dave Airlie