Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hi Gerd,
On Wed, Nov 15, 2023 at 10:22 AM Gerd Hoffmann wrote:
> On Wed, Nov 15, 2023 at 09:33:28AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
> > 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_XRGB, which
> > is XR24 on little-endian, and BX24 on big-endian. I.e. on big-endian,
> > virtgpu does not support XR24.
>
> Driver and device support both XR24 and BX24 on both little endian and
> big endian just fine.
OK.
> Problem is both fbdev interfaces and the ADDFB ioctl specify the format
> using bpp instead of fourcc, and advertising only one framebuffer format
> -- in native byte order -- used to worked best, especially on bigendian
> machines.
>
> That was years ago though, IIRC predating the generic fbdev emulation,
> so maybe it's time to revisit that. Changing it should be as simple as
> updating the format arrays:
>
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -30,11 +30,13 @@
> #include "virtgpu_drv.h"
>
> static const uint32_t virtio_gpu_formats[] = {
> - DRM_FORMAT_HOST_XRGB,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_BGRX,
> };
>
> static const uint32_t virtio_gpu_cursor_formats[] = {
> - DRM_FORMAT_HOST_ARGB,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_BGRA,
> };
>
> uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
Thanks!
Almost there, the check in virtio_gpu_user_framebuffer_create()
must be extended, too.
I have submitted a patch
https://lore.kernel.org/r/282a31154172a78165912c832a09f6502515d139.1700140178.git.ge...@linux-m68k.org/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
On Wed, Nov 15, 2023 at 09:33:28AM +0100, Geert Uytterhoeven wrote:
> Hi Christian,
>
> CC virtgpu
>
> On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
> 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_XRGB, which
> is XR24 on little-endian, and BX24 on big-endian. I.e. on big-endian,
> virtgpu does not support XR24.
Driver and device support both XR24 and BX24 on both little endian and
big endian just fine.
Problem is both fbdev interfaces and the ADDFB ioctl specify the format
using bpp instead of fourcc, and advertising only one framebuffer format
-- in native byte order -- used to worked best, especially on bigendian
machines.
That was years ago though, IIRC predating the generic fbdev emulation,
so maybe it's time to revisit that. Changing it should be as simple as
updating the format arrays:
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -30,11 +30,13 @@
#include "virtgpu_drv.h"
static const uint32_t virtio_gpu_formats[] = {
- DRM_FORMAT_HOST_XRGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_BGRX,
};
static const uint32_t virtio_gpu_cursor_formats[] = {
- DRM_FORMAT_HOST_ARGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGRA,
};
uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
HTH,
Gerd
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hi Christian,
CC virtgpu
On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
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_XRGB, 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_XRGB)
> > + format = DRM_FORMAT_HOST_XRGB;
> > + if (format == DRM_FORMAT_ARGB)
> > + format = DRM_FORMAT_HOST_ARGB;
> > + 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
Thanks for testing!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
Thanks for your report!
I can confirm there is no graphics output with m68k/virt, and
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_XRGB)
+ format = DRM_FORMAT_HOST_XRGB;
+ if (format == DRM_FORMAT_ARGB)
+ format = DRM_FORMAT_HOST_ARGB;
+ 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?
If not, please add
pr_info("%s: format = %p4cc\n", __func__, );
to drivers/gpu/drm/drm_client.c:drm_client_buffer_addfb(), and,
after reverting commit 6ae2ff23aa43a0c4, add
pr_info("%s: bpp %u/depth %u => r.pixel_format = %p4cc\n",
__func__, or->bpp, or->depth, _format);
to drivers/gpu/drm/drm_framebuffer.c:drm_mode_addfb(), so we know the
translation in your case?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --ge...@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
Geert,
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
Cheers,
Christian
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
Hi Christian,
On Sun, Nov 12, 2023 at 3:23 PM Christian Zigotzky
wrote:
On 07 November 2023 at 09:36 am, Christian Zigotzky wrote:
I have found out that fbdev no longer works with virtio-gpu-pci and
virtio-vga. It is not a problem with the penguin logos.
Could you please check fbdev in QEMU virtual machines with
virtio-gpu-pci and virtio-vga graphics?
On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote:
There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The
penguins are not displayed at boot time)
Error message: [0.889302] virtio-pci :00:02.0: [drm] *ERROR*
fbdev: Failed to setup generic emulation (ret=-2)
The kernel 6.6 final doesn't have this issue.
Please check the fbdev changes in the drm updates
'drm-next-2023-10-31-1'.
Thanks for your report!
I can confirm there is no graphics output with m68k/virt, and
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_XRGB)
+ format = DRM_FORMAT_HOST_XRGB;
+ if (format == DRM_FORMAT_ARGB)
+ format = DRM_FORMAT_HOST_ARGB;
+ 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?
If not, please add
pr_info("%s: format = %p4cc\n", __func__, );
to drivers/gpu/drm/drm_client.c:drm_client_buffer_addfb(), and,
after reverting commit 6ae2ff23aa43a0c4, add
pr_info("%s: bpp %u/depth %u => r.pixel_format = %p4cc\n",
__func__, or->bpp, or->depth, _format);
to drivers/gpu/drm/drm_framebuffer.c:drm_mode_addfb(), so we know the
translation in your case?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Hi Geert,
Thanks for your answer! I use a big-endian system.
Cheers,
Christian
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hi Christian,
On Sun, Nov 12, 2023 at 3:23 PM Christian Zigotzky
wrote:
> On 07 November 2023 at 09:36 am, Christian Zigotzky wrote:
> > I have found out that fbdev no longer works with virtio-gpu-pci and
> > virtio-vga. It is not a problem with the penguin logos.
> >
> > Could you please check fbdev in QEMU virtual machines with
> > virtio-gpu-pci and virtio-vga graphics?
>
> > On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote:
> >> There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The
> >> penguins are not displayed at boot time)
> >>
> >> Error message: [0.889302] virtio-pci :00:02.0: [drm] *ERROR*
> >> fbdev: Failed to setup generic emulation (ret=-2)
> >>
> >> The kernel 6.6 final doesn't have this issue.
> >>
> >> Please check the fbdev changes in the drm updates
> >> 'drm-next-2023-10-31-1'.
Thanks for your report!
I can confirm there is no graphics output with m68k/virt, and
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_XRGB)
+ format = DRM_FORMAT_HOST_XRGB;
+ if (format == DRM_FORMAT_ARGB)
+ format = DRM_FORMAT_HOST_ARGB;
+ 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?
If not, please add
pr_info("%s: format = %p4cc\n", __func__, );
to drivers/gpu/drm/drm_client.c:drm_client_buffer_addfb(), and,
after reverting commit 6ae2ff23aa43a0c4, add
pr_info("%s: bpp %u/depth %u => r.pixel_format = %p4cc\n",
__func__, or->bpp, or->depth, _format);
to drivers/gpu/drm/drm_framebuffer.c:drm_mode_addfb(), so we know the
translation in your case?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
+ Helge Deller + Gerd Knorr + Geert Uytterhoeven On 07 November 2023 at 09:36 am, Christian Zigotzky wrote: Hello, I have found out that fbdev no longer works with virtio-gpu-pci and virtio-vga. It is not a problem with the penguin logos. Could you please check fbdev in QEMU virtual machines with virtio-gpu-pci and virtio-vga graphics? Many thanks in advance, Christian On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote: Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please check the fbdev changes in the drm updates 'drm-next-2023-10-31-1'. Thanks, Christian
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hello, I have found out that fbdev no longer works with virtio-gpu-pci and virtio-vga. It is not a problem with the penguin logos. Could you please check fbdev in QEMU virtual machines with virtio-gpu-pci and virtio-vga graphics? Many thanks in advance, Christian On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote: Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please check the fbdev changes in the drm updates 'drm-next-2023-10-31-1'. Thanks, Christian
Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please check the fbdev changes in the drm updates 'drm-next-2023-10-31-1'. Thanks, Christian
