On Fri, Jan 11, 2019 at 10:43:42AM +0100, Gerd Hoffmann wrote: > On Fri, Jan 11, 2019 at 10:11:09AM +0100, Daniel Vetter wrote: > > On Fri, Jan 11, 2019 at 10:08 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > > > > On Fri, Jan 11, 2019 at 01:17:47AM -0500, Ilia Mirkin wrote: > > > > Hi Gerd, > > > > > > > > What happened with this series (and the next one)? > > > > > > Landed upstream in 4.20. > > > > > > > Semi-relatedly, I wonder if it wouldn't be better to just dump the > > > > BIG_ENDIAN flag and just define the "host" format to be the right one > > > > for a consistent little-endian interpretation. > > > > > > Not fully sure what you mean here. > > > > > > The big endian flag is needed to specify RGB565 or XRGB1555 format in > > > big endian byte order. For 32 bit depth we don't need it because > > > XRGB8888 big endian == BGRX8888 little endian (see also > > > include/drm/drm_fourcc.h). > > > > Yeah we'd need to add a few more fourcc codes for the missing > > big-endian versions. > > If we do that then yes we can drop the BIG_ENDIAN flag. > > Not sure what the userspace API implications are, > ADDFB2 ioctl comes to mind. > > > Aside from that I like Ilia's idea of removing > > the BIG_ENDIAN flag, it causes lots of aliasing among formats, doesn't > > change anything with others, and we probably have a huge mess already > > ... > > Shouldn't be too messy. The place where the DRM_FORMAT_HOST_* formats > are defined (include/drm/drm_fourcc.h) is almost the only place where > DRM_FORMAT_BIG_ENDIAN is used, and for the DRM_FORMAT_HOST_* users the > switch should be transparent. Yeah we'd need to review current userspace, but I suspect the overlap of "uses addfb2" and "runs on BE platform" is 0. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
