> 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. 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? 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
