My penguin has blue feets (aka: RGB versus BGR troubles)

[Daniel Vetter]

On Fri, Jul 26, 2019 at 11:35 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Fri, Jul 26, 2019 at 4:36 PM Sam Ravnborg <sam at ravnborg.org> wrote:
> >
> > Hi all.
> >
> > The Atmel at91sam9263 has a nice LCDC IP core that supports several
> > formats:
> >     DRM_FORMAT_XBGR8888, DRM_FORMAT_BGR888, DRM_FORMAT_BGR565
> >
> > (It also supports a palletized C8 format, but thats for later).
> >
> > The formats are all BGR formats - and some boards actually reverse Blue
> > and Red when wiring up the display. I have added a DT property to
> > identify boards with this difference.
> >
> > The penguin shown during boot of the kernel had blue feet which is a
> > clear sign that RED and GREEN was reversed.
> >
> > So to fix this I (got help from imirkin on irc) I implmented a quirk.
> > See patch below.
> >
> > With the quirk enabled I see:
> > - penguin shown during kernel boot has yellow feets (OK)
> > - modetest tell the driver reports: XB24 BG24 BG16 (as expected)
> > - modetest -s fails with:
> >     # modetest -M atmel-lcdc -s 34:800x480-60Hz
> >     setting mode 800x480-60Hz at XR24 on connectors 34, crtc 32
> >     failed to set mode: Function not implemented
> >
> > Snip from dmesg:
> >
> > drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_ADDFB2
> > [drm:drm_mode_addfb2] [FB:37]
> > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETCRTC
> > [drm:drm_mode_setcrtc] [CRTC:32:crtc-0]
> > [drm:drm_mode_setcrtc] Invalid pixel format XR24 little-endian (0x34325258), modifier 0x0
> >                                             ^^^^
> > [drm:drm_mode_object_put] OBJ ID: 37 (2)
> > [drm:drm_ioctl] pid=208, ret = -22
> > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_DIRTYFB
> > [drm:drm_mode_object_put] OBJ ID: 37 (2)
> > [drm:drm_ioctl] pid=208, ret = -38
> > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_RMFB
> > [drm:drm_mode_object_put] OBJ ID: 37 (2)
> > [drm:drm_mode_object_put] OBJ ID: 37 (1)
> > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_DESTROY_DUMB
> > [drm:drm_release] open_count = 1
> > [drm:drm_file_free] pid = 208, device = 0xe201, open_count = 1
> > [drm:drm_lastclose]
> > [drm:drm_lastclose] driver lastclose completed
> >
> > Notice that somehow we have a framebuffer in XR24 format, which is not
> > supported by the driver.
> >
> >
> > I have tried to tell that my driver supports DRM_FORMAT_XRGB8888,
> > DRM_FORMAT_RGB888, DRM_FORMAT_RGB565 and then modetest works.
> > But in the output of modetest -s the blue and red colors are reversed.
> >
> > *Any* hints why modetest fails when my driver reports the correct formats?
>
> Every driver to date supports XR24. So modetest uses that by default.
> But this fails with your driver since it's an unsupported format.
> Something like:
>
> modetest -M atmel-lcdc -s 34:800x480-60Hz at XB24
>
> should do the trick. The quirk covers drivers that use AddFB().
> However modetest is fancy and uses AddFB2, which takes an explicit
> format.

Yeah I thinki for fbdev the correct fix is to look whether the driver
enabled atomic and if so, consult the fourcc format list of the
primary plane of the first crtc to figure out what you might actually
have set. Without atomic you can't realy on the format list being
correct since for drivers who get the default primary plane that
drm_crtc_init sets up the format list is garbage. Reworking the entire
fbdev emulation to use fourcc codes would be even more awesome I
guess.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch