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
