user/sven/linux.git/include/drm/drm_mode.h, branch v3.2.53

drm: Pad drm_mode_get_connector to 64-bit boundary

2013-11-28T14:02:05Z

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

drm: Check for invalid cursor flags

2012-09-19T14:04:33Z

commit 7c4eaca4162d0b5ad4fb39f974d7ffd71b9daa09 upstream. Signed-off-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings

drm: integer overflow in drm_mode_dirtyfb_ioctl()

2011-11-23T08:59:28Z

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: Introduce "Virtual" connectors and encoders

2011-11-01T16:01:42Z

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:23Z

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

drm: dumb scanout create/mmap for intel/radeon (v3)

2011-02-07T02:16:14Z

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

drm: add "auto" dithering method

2010-07-21T01:19:45Z

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: Ben Skeggs Signed-off-by: Dave Airlie

drm/kms: Remove incorrect comment in struct drm_mode_modeinfo

2010-02-01T01:26:39Z

Signed-off-by: Dave Airlie

drm: Add eDP connector type

2010-01-08T03:04:04Z

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: Alex Deucher Signed-off-by: Dave Airlie

drm: Add dirty ioctl and property

2009-12-03T23:25:47Z

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