1. 30 8月, 2013 1 次提交
    • D
      drm: implement experimental render nodes · 1793126f
      David Herrmann 提交于
      Render nodes provide an API for userspace to use non-privileged GPU
      commands without any running DRM-Master. It is useful for offscreen
      rendering, GPGPU clients, and normal render clients which do not perform
      modesetting.
      
      Compared to legacy clients, render clients no longer need any
      authentication to perform client ioctls. Instead, user-space controls
      render/client access to GPUs via filesystem access-modes on the
      render-node. Once a render-node was opened, a client has full access to
      the client/render operations on the GPU. However, no modesetting or ioctls
      that affect global state are allowed on render nodes.
      
      To prevent privilege-escalation, drivers must explicitly state that they
      support render nodes. They must mark their render-only ioctls as
      DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
      support clients without any attached master.
      
      If filesystem access-modes are not enough for fine-grained access control
      to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
      you may still fall-back to fd-passing from server to client (which allows
      arbitrary access-control). However, note that revoking access is
      currently impossible and unlikely to get implemented.
      
      Note: Render clients no longer have any associated DRM-Master as they are
      supposed to be independent of any server state. DRM core highly depends on
      file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
      Therefore, drivers must be very careful to not require DRM-Master if they
      support DRIVER_RENDER.
      
      So far render-nodes are protected by "drm_rnodes". As long as this
      module-parameter is not set to 1, a driver will not create render nodes.
      This allows us to experiment with the API a bit before we stabilize it.
      
      v2: drop insecure GEM_FLINK to force use of dmabuf
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1793126f
  2. 21 8月, 2013 1 次提交
  3. 23 10月, 2012 1 次提交
  4. 03 10月, 2012 1 次提交
  5. 07 3月, 2012 1 次提交
  6. 01 11月, 2011 1 次提交
  7. 15 7月, 2011 1 次提交
  8. 07 2月, 2011 1 次提交
  9. 14 9月, 2010 1 次提交
    • D
      drm: fix race between driver loading and userspace open. · b64c115e
      Dave Airlie 提交于
      Not 100% sure this is due to BKL removal, its most likely a combination
      of that + userspace timing changes in udev/plymouth. The drm adds the sysfs
      device before the driver has completed internal loading, this causes udev
      to make the node and plymouth to open it before we've completed loading.
      
      The proper solution is to delay the sysfs manipulation until later in loading
      however this causes knock on issues with sysfs connector nodes, so we can use
      the global mutex to serialise loading and userspace opens.
      
      Reported-by: Toni Spets (hifi on #radeon)
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b64c115e
  10. 01 6月, 2010 1 次提交