Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver.  It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you rebase.  And then try to get the vendor to
> add support for dmabuf so that the patch on top of upstream can
> eventually be dropped.  Maybe someone else has a better suggestion,
> but I don't think we can merge those phys ioctls upstream, and I'd
> really hate to 'throw the baby out with the bathwater' in this case
> and not at least get the modesetting part of the driver merged.

What you're saying is basically:

1. Throw out DRM_ARMADA_GEM_CREATE_PHYS, which cripples video playback
   on existing gstreamer, xbmc and other implementations without someone
   rewriting all that code.

2. Throw out DRM_ARMADA_GEM_PROP, which prevents any form of passing
   the GEM objects to the GPU libraries in userspace, thereby preventing
   any kind of GPU based acceleration.

That makes the driver just be a dumb scanout only driver.  Sorry,
that *really* does not interest me one bit, because the CPU doing
framebuffer accesses is pig slow.

There's really no point in such a driver; people might as well just
use the standard fbdev driver instead.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux