1. 02 Oct, 2012 1 commit
  2. 23 Aug, 2012 1 commit
  3. 21 Aug, 2012 1 commit
  4. 19 Jul, 2012 1 commit
  5. 12 Jun, 2012 1 commit
    • Paulo Zanoni's avatar
      drm: increase DRM_OBJECT_MAX_PROPERTY to 24 · fe456168
      Paulo Zanoni authored
      
      
      Before Kernel 3.5, no one was checking for the return value of
      drm_connector_attach_property, so we never noticed that we were unable
      to create some properties. Commit "drm: WARN() when
      drm_connector_attach_property fails" added a WARN when we fail to
      create a property, and the transition from "connector properties" to
      "object properties" changed the warning message a little bit.
      
      On i915 machines with many TV connectors we hit the maximum number of
      properties (since each TV connector uses a lot of properties), so we
      get a few backtraces in our logs. This commit increases the maximum
      number of properties to 24 hoping we'll have enough room for
      everybody.
      
      Chris suggested that we convert this code to "lists", but I believe
      this conversion can come after we make sure people's dmesgs are not
      spammed by our driver.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Tested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      fe456168
  6. 22 May, 2012 4 commits
  7. 17 May, 2012 5 commits
  8. 27 Apr, 2012 1 commit
  9. 20 Apr, 2012 4 commits
  10. 20 Mar, 2012 1 commit
    • Carsten Emde's avatar
      drm: allow loading an EDID as firmware to override broken monitor · da0df92b
      Carsten Emde authored
      
      
      Broken monitors and/or broken graphic boards may send erroneous or no
      EDID data. This also applies to broken KVM devices that are unable to
      correctly forward the EDID data of the connected monitor but invent
      their own fantasy data.
      
      This patch allows to specify an EDID data set to be used instead of
      probing the monitor for it. It contains built-in data sets of frequently
      used screen resolutions. In addition, a particular EDID data set may be
      provided in the /lib/firmware directory and loaded via the firmware
      interface. The name is passed to the kernel as module parameter of the
      drm_kms_helper module either when loaded
        options drm_kms_helper edid_firmware=edid/1280x1024.bin
      or as kernel commandline parameter
        drm_kms_helper.edid_firmware=edid/1280x1024.bin
      
      It is also possible to restrict the usage of a specified EDID data set
      to a particular connector. This is done by prepending the name of the
      connector to the name of the EDID data set using the syntax
        edid_firmware=[<connector>:]<edid>
      such as, for example,
        edid_firmware=DVI-I-1:edid/1920x1080.bin
      in which case no other connector will be affected.
      
      The built-in data sets are
      Resolution    Name
      --------------------------------
      1024x768      edid/1024x768.bin
      1280x1024     edid/1280x1024.bin
      1680x1050     edid/1680x1050.bin
      1920x1080     edid/1920x1080.bin
      
      They are ignored, if a file with the same name is available in the
      /lib/firmware directory.
      
      The built-in EDID data sets are based on standard timings that may not
      apply to a particular monitor and even crash it. Ideally, EDID data of
      the connected monitor should be used. They may be obtained through the
      drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
      of a correctly working graphics adapter.
      
      It is even possible to specify the name of an EDID data set on-the-fly
      via the /sys/module interface, e.g.
      echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
      The new screen mode is considered when the related kernel function is
      called for the first time after the change. Such calls are made when the
      X server is started or when the display settings dialog is opened in an
      already running X server.
      Signed-off-by: default avatarCarsten Emde <C.Emde@osadl.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      da0df92b
  11. 15 Mar, 2012 6 commits
  12. 16 Feb, 2012 1 commit
    • Dave Airlie's avatar
      drm: add some caps for userspace to discover more info for dumb KMS driver (v2) · 019d96cb
      Dave Airlie authored
      
      
      For the simple KMS driver case we need some more info about what the preferred
      depth and if a shadow framebuffer is preferred.
      
      I've only added this for intel/radeon which support the dumb ioctls so far.
      
      If you need something really fancy you should be writing a real X.org driver.
      
      v2: drop cursor information, just return an error from the cursor ioctls
      and we can make userspace fallback to sw cursor in that case, cursor
      info was getting too messy, best to start smaller.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      019d96cb
  13. 09 Feb, 2012 2 commits
  14. 03 Feb, 2012 1 commit
  15. 13 Jan, 2012 1 commit
  16. 05 Jan, 2012 1 commit
    • Rob Clark's avatar
      drm: add support for private planes · 0a7eb243
      Rob Clark authored
      
      
      In cases where the scanout hw is sufficiently similar between "overlay"
      and traditional crtc layers, it might be convenient to allow the driver
      to create internal drm_plane helper objects used by the drm_crtc
      implementation, rather than duplicate code between the plane and crtc.
      A private plane is not exposed to userspace.
      Signed-off-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0a7eb243
  17. 20 Dec, 2011 2 commits
  18. 06 Dec, 2011 6 commits