Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

A bitmask property is similar to an enum.  The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).

[airlied: 1LL -> 1ULL]
Signed-off-by: NRob Clark <rob@ti.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Useless for connector properties (since they already have their own
ioctls), but useful when we add properties to CRTCs, planes and other
objects.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Tested-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This addresses some header check warnings.  DRM headers which include
"drm.h" have been excluded, as they indirectly include types.h.
Signed-off-by: NBobby Powers <bobbypowers@gmail.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Dave Airlie <airlied@linux.ie>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The code happened to compile because the flag wasn't actually used yet.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.
Reported-by: NHaogang Chen <haogangchen@gmail.com>
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This will allow us to attach various properties specific to virtual
monitors in the future.

Note that we don't export an EDID property for "Virtual" connectors.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

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: NDave Airlie <airlied@redhat.com>

There's no convenient/reliable way for drivers to both obey the dithering
mode property, and to be able to attempt to provide a good default in all
cases.

This commit adds an "auto" method to the property which drivers can default
to if they wish, whilst still allowing the user to override the choice as
they do now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a new connector type for eDP (embedded displayport)

eDP is more or less the same as DP but there are some
cases when you might want to handle it separately.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This let's use use the linux drm headers as the canonical source for
libdrm on all platforms.
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NKristian Høgsberg <krh@bitplanet.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that we're using the scaling property in the Intel driver I noticed
that the names were a bit confusing.  I've corrected them according to
our discussion on IRC and the mailing list, though I've left out
potential new additions for a new scaling property with an integer (or
two) for the scaling factor.  None of the drivers implement that today,
but if someone wants to do it, I think it could be done with the
addition of a single new type and a new property to describe the
scaling factor in the X and Y directions.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The existing TV connector types are often unsuitable either because
there is no way to probe them until they're actually plugged in or
because they can change during run time (e.g. 7-pin DIN connectors
that behave as S-Video, Component, Composite or SCART depending on the
adaptor plugged in).
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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 <airlied@linux.ie>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The initially merged modesetting API has some uglies in it, this
cleans up the struct members and ioctl ordering for initial submission.

It also removes the unneeded hotplug infrastructure.

airlied:- I've pulled this patch in from git modesetting-gem tree.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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 support

This 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 <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>