Fbdev issue after the drm updates 'drm-next-2023-10-31-1'

[Geert Uytterhoeven]

Hi Christian,

CC virtgpu

On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
<chzigotzky at xenosoft.de> wrote:
> On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
> > I can confirm there is no graphics output with m68k/virt, and

Before the error message you reported:

    virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup
generic emulation (ret=-2)

it also prints:

    virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
    virtio-mmio virtio-mmio.125: [drm] No compatible format found

Upon closer look, it turns out virtgpu is special in that its main
plane supports only a single format: DRM_FORMAT_HOST_XRGB8888, which
is XR24 on little-endian, and BX24 on big-endian.  I.e. on big-endian,
virtgpu does not support XR24.  Isn't this a violation of the DRM
rule that every driver must implement support for XR24?

> > bisected this to my own commit 6ae2ff23aa43a0c4 ("drm/client: Convert
> > drm_client_buffer_addfb() to drm_mode_addfb2()"), ouch...
> >
> > It turns out the old call to drm_mode_addfb() caused a translation
> > from a fourcc to a bpp/depth pair to a _different_ fourcc, due to the
> > quirk processing in drm_driver_legacy_fb_format().
> > I.e. on m68k/virt, the original requested format was XR24, which was
> > translated to BX24. The former doesn't work, the latter works.
> >
> > The following (gmail-whitespace-damaged) patch fixed the issue for me:
> >
> > --- a/drivers/gpu/drm/drm_client.c
> > +++ b/drivers/gpu/drm/drm_client.c
> > @@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struct
> > drm_client_buffer *buffer,
> >
> >         fb_req.width = width;
> >         fb_req.height = height;
> > +       if (client->dev->mode_config.quirk_addfb_prefer_host_byte_order) {
> > +               if (format == DRM_FORMAT_XRGB8888)
> > +                       format = DRM_FORMAT_HOST_XRGB8888;
> > +               if (format == DRM_FORMAT_ARGB8888)
> > +                       format = DRM_FORMAT_HOST_ARGB8888;
> > +               if (format == DRM_FORMAT_RGB565)
> > +                       format = DRM_FORMAT_HOST_RGB565;
> > +               if (format == DRM_FORMAT_XRGB1555)
> > +                       format = DRM_FORMAT_HOST_XRGB1555;
> > +       }
> >         fb_req.pixel_format = format;
> >         fb_req.handles[0] = handle;
> >         fb_req.pitches[0] = buffer->pitch;
> >
> > However, I don't think we want to sprinkle more of these
> > translations around... So perhaps we should (re)add a call to
> > drm_driver_legacy_fb_format() to drm_client_buffer_addfb()?
> >
> > Second, as I doubt you are using a big-endian system, you are probably
> > running into a slightly different issue.
> >
> > Oh wait, you did CC linuxppc-dev, so perhaps you are running on a
> > big-endian machine?
>
> Your patch works! :-) Thanks a lot!
>
> I tested it with the virtio-vga and with the virtio-gpu-pci device in a virtual ppce500 QEMU/KVM HV machine with an e5500 CPU today.
>
> Tested-by: Christian Zigotzky <chzigotzky at xenosoft.de>

Thanks for testing!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds