kernel/linux.git/include/drm/drm_mode.h, branch v3.4.112

drm: Pad drm_mode_get_connector to 64-bit boundary

2014-06-07T23:02:13+00:00

commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream. Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting the 4 bytes beyond the end of its structure with a 32-bit userspace running on a 64-bit kernel. This is due to the padding gcc inserts as the drm_mode_get_connector struct includes a u64 and its size is not a natural multiple of u64s. 64-bit kernel: sizeof(drm_mode_get_connector)=80, alignof=8 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 32-bit userspace: sizeof(drm_mode_get_connector)=76, alignof=4 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 Fortuituously we can insert explicit padding to the tail of our structures without breaking ABI. Reported-by: Pavel Roskin Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings Cc: Weng Meiling Signed-off-by: Greg Kroah-Hartman

drm: Check for invalid cursor flags

2012-10-02T17:30:23+00:00

commit 7c4eaca4162d0b5ad4fb39f974d7ffd71b9daa09 upstream. Signed-off-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

headers: include linux/types.h where appropriate

2012-03-23T23:58:31+00:00

This addresses some header check warnings. DRM headers which include "drm.h" have been excluded, as they indirectly include types.h. Signed-off-by: Bobby Powers Cc: Chris Ball Cc: Dave Airlie Cc: James Bottomley Cc: Takashi Iwai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge tag 'v3.2-rc6' of /home/airlied/devel/kernel/linux-2.6 into drm-core-next

2011-12-20T14:43:53+00:00

Merge in the upstream tree to bring in the mainline fixes. Conflicts: drivers/gpu/drm/exynos/exynos_drm_fbdev.c drivers/gpu/drm/nouveau/nouveau_sgdma.c

drm: Add a missing ')'

2011-12-20T10:01:42+00:00

The code happened to compile because the flag wasn't actually used yet. Signed-off-by: Ville Syrjälä Signed-off-by: Dave Airlie

drm: integer overflow in drm_mode_dirtyfb_ioctl()

2011-11-23T08:59:28+00:00

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: Haogang Chen Signed-off-by: Xi Wang Cc: stable@kernel.org Signed-off-by: Dave Airlie

drm: add an fb creation ioctl that takes a pixel format v5

2011-11-15T19:53:23+00:00

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

drm: add plane support v3

2011-11-15T19:53:10+00:00

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

drm: Introduce "Virtual" connectors and encoders

2011-11-01T16:01:42+00:00

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: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi