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. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
