20 Dec, 2011

2 commits


23 Nov, 2011

1 commit

  • 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

    Xi Wang
     

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

    Jesse Barnes
     
  • 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

    Jesse Barnes
     

02 Nov, 2011

1 commit


31 Mar, 2011

1 commit


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

    Dave Airlie
     

21 Jul, 2010

1 commit

  • 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

    Ben Skeggs
     

01 Feb, 2010

1 commit


08 Jan, 2010

1 commit

  • 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

    Alex Deucher
     

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

    Jakob Bornecrantz
     
  • 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

    Kristian Høgsberg
     

18 Nov, 2009

1 commit

  • 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

    Kristian Høgsberg
     

19 Aug, 2009

1 commit

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

    Jesse Barnes
     

04 Aug, 2009

2 commits


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

    Arnd Bergmann
     

29 Dec, 2008

2 commits

  • 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: Dave Airlie

    Jakob Bornecrantz
     
  • 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 , Jakob Bornecrantz
    Contributors: Alan Hourihane , Maarten Maathuis

    Signed-off-by: Jesse Barnes
    Signed-off-by: Eric Anholt
    Signed-off-by: Dave Airlie

    Dave Airlie