On Fri, Jan 11, 2019, 05:26 Daniel Vetter <dan...@ffwll.ch wrote: > 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 <kra...@redhat.com> > 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. >
Huh. I must have been looking at an option tree. > > > > > > > > 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). > Bleargh. I was thinking xrgb1555 le == bgrx5551 be, but that's clearly false. Made sense to me last night though. That makes my suggestion considerably less appealing. > > > > > 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. > Most importantly, "uses bigendian flag" is 0 since we would previously error out on such modesets. Although the need to double up on the 16bpp formats makes this not really worth it. Ohhh well. -ilia
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
