On Tue, Apr 23, 2013 at 12:34 PM, Tom Cooksey <tom.cooksey@xxxxxxx> wrote: >> It appears exynos is passing the generic flags from the dumb ioctls >> straight into the the GEM creation code. >> >> The dumb flags are NOT driver specific, and are NOT to be used in this >> fashion. Please remove this use of the flags from your driver. >> >> I was going to add one new flag to the interface for SCANOUT vs CURSOR >> for some drivers. > > Having a flag to indicate a dumb buffer allocation is to be used as a > scan-out buffer would be useful for xf86-video-armsoc. We're trying to > keep that driver as generic as possible and currently the main device- > specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for > scanout & non-scanout buffer allocations. If a generic scanout flag could > be added, it would simplify armsoc a fair bit and also allow the DRM > drivers we're using armsoc with to comply with the don't pass device- > specific flags to create dumb. well, by definition, *all* dumb buffers are scanout buffers ;-) I don't really think directly using dumb buffers is such a great idea. It might more or less work on current drivers, but it really is a bit of a misuse of the API. I suppose one possibility would be to use libkms, which will fallback to dumb scanout. If some particular platform needs something special, they could implement their own libkms backend rather than using the dumb buffer fallback. > For reference, the device-specific bits of armsoc are currently abstracted > here: > > <https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=blob;f=src/drmmode_driver.h >> > > > Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap > and DRI2 buffers and have not come across any issues with doing that. > Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and > the display controller's in SoCs shipping Mali also seem to happily > scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might > need a device-specific allocation function to allocate the tiled format > used on OMAP, but only for efficient 90-degree rotations (if I understood > Rob correctly). So maybe we could also one day add a "this buffer will be > rotated 90 degrees" flag? In omap ddx, it is a bit more complicated than that, since we do some tricks to re-allocate the buffer if one or more of the crtcs is rotated/mirrored. (IIRC, that support might have been added after your forked off of xf86-video-omap) Ideal perfect DDX solution would, I think, look something like some helpers for drmmode_display stuff, which a platform specific DDX could choose to use all, part, or none of, depending on it's needs. Whether it makes sense to spend a lot of time on that, or instead spend the effort on wayland, I'm not sure. Living w/ some cut/paste code for a year or two isn't such a big deal. BR, -R > > Cheers, > > Tom > > PS: I've stuck in a fd.o bugzilla ticket to move xf86-video-armsoc to > freedesktop.org infrastructure, so hopefully it will live in a more > appropriate place soon, not to mention have a mailing list, etc.! > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
