[v2] drm/virtio: Add suppport for non-native buffer formats

Message ID 47a81d2e0e47b1715718779b6978a8b595cc7c5d.1700140609.git.geert@linux-m68k.org
State New
Headers
Series [v2] drm/virtio: Add suppport for non-native buffer formats |

Commit Message

Geert Uytterhoeven Nov. 16, 2023, 1:16 p.m. UTC
  When using virtgpu on a big-endian machine, e.g. powerpc QEMU:

    virtio-pci 0000:00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)

or m68k/virt:

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

and the graphical display fails to come up.

Before, the call to drm_mode_addfb() caused a translation from a fourcc
format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc
format (BX24 on big-endian), due to the quirk processing in
drm_driver_legacy_fb_format().  After, the original fourcc format (XR24)
is passed unmodified.

However, the virtgpu DRM driver supports only a single format for its
main plane: 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, which is the default DRM format, and must be supported by all
drivers.  Before, this was reported, but didn't lead to a failure:

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

As the core virtgpu driver and device support both XR24 and BX24 on both
little-endian and big-endian just fine, fix this extending the list of
supported formats for main plane and cursor plane to XR24/BX24 resp.
AR24/BA24.

Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670ebdbc@xenosoft.de
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v2:
  - Fix truncated one-line summary.
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++--
 drivers/gpu/drm/virtio/virtgpu_plane.c   |  6 ++++--
 2 files changed, 13 insertions(+), 4 deletions(-)
  

Comments

Javier Martinez Canillas Nov. 16, 2023, 1:22 p.m. UTC | #1
Geert Uytterhoeven <geert@linux-m68k.org> writes:

> When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
>
>     virtio-pci 0000:00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
>
> or m68k/virt:
>
>     virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
>
> and the graphical display fails to come up.
>
> Before, the call to drm_mode_addfb() caused a translation from a fourcc
> format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc
> format (BX24 on big-endian), due to the quirk processing in
> drm_driver_legacy_fb_format().  After, the original fourcc format (XR24)
> is passed unmodified.
>
> However, the virtgpu DRM driver supports only a single format for its
> main plane: 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, which is the default DRM format, and must be supported by all
> drivers.  Before, this was reported, but didn't lead to a failure:
>
>     virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
>     virtio-mmio virtio-mmio.125: [drm] No compatible format found
>
> As the core virtgpu driver and device support both XR24 and BX24 on both
> little-endian and big-endian just fine, fix this extending the list of
> supported formats for main plane and cursor plane to XR24/BX24 resp.
> AR24/BA24.
>
> Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670ebdbc@xenosoft.de
> Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> v2:
>   - Fix truncated one-line summary.
> ---

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
  
Gerd Hoffmann Nov. 16, 2023, 2:44 p.m. UTC | #2
On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote:
> When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
> 
>     virtio-pci 0000:00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
> 
> or m68k/virt:
> 
>     virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
> 
> and the graphical display fails to come up.
> 
> Before, the call to drm_mode_addfb() caused a translation from a fourcc
> format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc
> format (BX24 on big-endian), due to the quirk processing in
> drm_driver_legacy_fb_format().  After, the original fourcc format (XR24)
> is passed unmodified.
> 
> However, the virtgpu DRM driver supports only a single format for its
> main plane: 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, which is the default DRM format, and must be supported by all
> drivers.  Before, this was reported, but didn't lead to a failure:
> 
>     virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
>     virtio-mmio virtio-mmio.125: [drm] No compatible format found
> 
> As the core virtgpu driver and device support both XR24 and BX24 on both
> little-endian and big-endian just fine, fix this extending the list of
> supported formats for main plane and cursor plane to XR24/BX24 resp.
> AR24/BA24.
> 
> Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670ebdbc@xenosoft.de
> Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
  
Christian Zigotzky Nov. 19, 2023, 4:27 p.m. UTC | #3
On 16 November 2023 at 03:44 pm, Gerd Hoffmann wrote:
> On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote:
>> When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
>>
>>      virtio-pci 0000:00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
>>
>> or m68k/virt:
>>
>>      virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
>>
>> and the graphical display fails to come up.
>>
>> Before, the call to drm_mode_addfb() caused a translation from a fourcc
>> format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc
>> format (BX24 on big-endian), due to the quirk processing in
>> drm_driver_legacy_fb_format().  After, the original fourcc format (XR24)
>> is passed unmodified.
>>
>> However, the virtgpu DRM driver supports only a single format for its
>> main plane: 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, which is the default DRM format, and must be supported by all
>> drivers.  Before, this was reported, but didn't lead to a failure:
>>
>>      virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
>>      virtio-mmio virtio-mmio.125: [drm] No compatible format found
>>
>> As the core virtgpu driver and device support both XR24 and BX24 on both
>> little-endian and big-endian just fine, fix this extending the list of
>> supported formats for main plane and cursor plane to XR24/BX24 resp.
>> AR24/BA24.
>>
>> Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
>> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>> Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670ebdbc@xenosoft.de
>> Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
>
Hi All,

The new patch works but I don't see the virtio-mouse-pci pointer 
anymore. I see the pointer with -device usb-tablet. Please check the 
second patch. I will use the first patch for the RC2 of kernel 6.7.

Thanks,
Christian
  
Geert Uytterhoeven Nov. 19, 2023, 6:33 p.m. UTC | #4
Hi Christian,

On Sun, Nov 19, 2023 at 5:28 PM Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
> On 16 November 2023 at 03:44 pm, Gerd Hoffmann wrote:
> > On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote:
> >> When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
> >>
> >>      virtio-pci 0000:00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
> >>
> >> or m68k/virt:
> >>
> >>      virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
> >>
> >> and the graphical display fails to come up.
> >>
> >> Before, the call to drm_mode_addfb() caused a translation from a fourcc
> >> format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc
> >> format (BX24 on big-endian), due to the quirk processing in
> >> drm_driver_legacy_fb_format().  After, the original fourcc format (XR24)
> >> is passed unmodified.
> >>
> >> However, the virtgpu DRM driver supports only a single format for its
> >> main plane: 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, which is the default DRM format, and must be supported by all
> >> drivers.  Before, this was reported, but didn't lead to a failure:
> >>
> >>      virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
> >>      virtio-mmio virtio-mmio.125: [drm] No compatible format found
> >>
> >> As the core virtgpu driver and device support both XR24 and BX24 on both
> >> little-endian and big-endian just fine, fix this extending the list of
> >> supported formats for main plane and cursor plane to XR24/BX24 resp.
> >> AR24/BA24.
> >>
> >> Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
> >> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> >> Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670ebdbc@xenosoft.de
> >> Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
> >> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
>
> The new patch works but I don't see the virtio-mouse-pci pointer
> anymore. I see the pointer with -device usb-tablet. Please check the
> second patch. I will use the first patch for the RC2 of kernel 6.7.

That's probably partially explained by commit 99748ab64fcc8578 ("drm:
virtio: fix virtio_gpu_cursor_formats"), which forced BA24 for the
cursor plane on big-endian, but unfortunately linked thread doesn't
contain the full picture.

Where is the default cursor format defined?
I see virtio_gpu_mode_dumb_create() still defaults to
DRM_FORMAT_HOST_XRGB8888.  However, that can't be the cause, as the
cursor formats require an alpha channel.

Gr{oetje,eeting}s,

                        Geert
  
Christian Zigotzky Nov. 25, 2023, 10:06 a.m. UTC | #5
On 19 November 2023 at 07:33 pm, Geert Uytterhoeven wrote:
> Hi Christian,
>
> On Sun, Nov 19, 2023 at 5:28 PM Christian Zigotzky
> <chzigotzky@xenosoft.de> wrote:
>> On 16 November 2023 at 03:44 pm, Gerd Hoffmann wrote:
>>> On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote:
>>>> When using virtgpu on a big-endian machine, e.g. powerpc QEMU:
>>>>
>>>>       virtio-pci 0000:00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
>>>>
>>>> or m68k/virt:
>>>>
>>>>       virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2)
>>>>
>>>> and the graphical display fails to come up.
>>>>
>>>> Before, the call to drm_mode_addfb() caused a translation from a fourcc
>>>> format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc
>>>> format (BX24 on big-endian), due to the quirk processing in
>>>> drm_driver_legacy_fb_format().  After, the original fourcc format (XR24)
>>>> is passed unmodified.
>>>>
>>>> However, the virtgpu DRM driver supports only a single format for its
>>>> main plane: 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, which is the default DRM format, and must be supported by all
>>>> drivers.  Before, this was reported, but didn't lead to a failure:
>>>>
>>>>       virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported
>>>>       virtio-mmio virtio-mmio.125: [drm] No compatible format found
>>>>
>>>> As the core virtgpu driver and device support both XR24 and BX24 on both
>>>> little-endian and big-endian just fine, fix this extending the list of
>>>> supported formats for main plane and cursor plane to XR24/BX24 resp.
>>>> AR24/BA24.
>>>>
>>>> Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()")
>>>> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>>>> Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670ebdbc@xenosoft.de
>>>> Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
>>>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
>> The new patch works but I don't see the virtio-mouse-pci pointer
>> anymore. I see the pointer with -device usb-tablet. Please check the
>> second patch. I will use the first patch for the RC2 of kernel 6.7.
> That's probably partially explained by commit 99748ab64fcc8578 ("drm:
> virtio: fix virtio_gpu_cursor_formats"), which forced BA24 for the
> cursor plane on big-endian, but unfortunately linked thread doesn't
> contain the full picture.
>
> Where is the default cursor format defined?
> I see virtio_gpu_mode_dumb_create() still defaults to
> DRM_FORMAT_HOST_XRGB8888.  However, that can't be the cause, as the
> cursor formats require an alpha channel.
>
> Gr{oetje,eeting}s,
>
>                          Geert
>
Hi Geert,

Could you please revert the v2 patch because of the issue with the 
virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of 
kernel 6.7.

Thanks,
Christian
  
John Paul Adrian Glaubitz Nov. 25, 2023, 11:09 a.m. UTC | #6
On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote:
> Could you please revert the v2 patch because of the issue with the 
> virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of 
> kernel 6.7.

I don't understand why the v2 patch should yield any different results as
the only change compared to v1 is the fixed patch subject. There are no
functional differences, I just diffed the patches against each other:

--- geert-patch-v1.patch        2023-11-25 12:09:19.122936658 +0100
+++ geert-patch-v2.patch        2023-11-25 12:09:36.313039085 +0100
@@ -34,6 +34,9 @@
 Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
 Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
 ---
+v2:
+  - Fix truncated one-line summary.
+---
  drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++--
  drivers/gpu/drm/virtio/virtgpu_plane.c   |  6 ++++--
  2 files changed, 13 insertions(+), 4 deletions(-)

Adrian
  
Christian Zigotzky Nov. 25, 2023, 12:22 p.m. UTC | #7
On 25 November 2023 at 12:09 pm, John Paul Adrian Glaubitz wrote:
> On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote:
>> Could you please revert the v2 patch because of the issue with the
>> virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of
>> kernel 6.7.
> I don't understand why the v2 patch should yield any different results as
> the only change compared to v1 is the fixed patch subject. There are no
> functional differences, I just diffed the patches against each other:
>
> --- geert-patch-v1.patch        2023-11-25 12:09:19.122936658 +0100
> +++ geert-patch-v2.patch        2023-11-25 12:09:36.313039085 +0100
> @@ -34,6 +34,9 @@
>   Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
>   Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>   ---
> +v2:
> +  - Fix truncated one-line summary.
> +---
>    drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++--
>    drivers/gpu/drm/virtio/virtgpu_plane.c   |  6 ++++--
>    2 files changed, 13 insertions(+), 4 deletions(-)
>
> Adrian
>
Hi Adrian,

Thank you for the hint. I think you are right. I use the the following 
patch.

--- a/drivers/gpu/drm/drm_client.c    2023-11-13 01:19:07.000000000 +0100
+++ b/drivers/gpu/drm/drm_client.c    2023-11-14 09:45:44.964199272 +0100
@@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struc

      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;

This patch solved the issue.

Christian
  
Christian Zigotzky Nov. 25, 2023, 12:35 p.m. UTC | #8
On 25 November 2023 at 01:22 pm, Christian Zigotzky wrote:
> On 25 November 2023 at 12:09 pm, John Paul Adrian Glaubitz wrote:
>> On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote:
>>> Could you please revert the v2 patch because of the issue with the
>>> virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of
>>> kernel 6.7.
>> I don't understand why the v2 patch should yield any different 
>> results as
>> the only change compared to v1 is the fixed patch subject. There are no
>> functional differences, I just diffed the patches against each other:
>>
>> --- geert-patch-v1.patch        2023-11-25 12:09:19.122936658 +0100
>> +++ geert-patch-v2.patch        2023-11-25 12:09:36.313039085 +0100
>> @@ -34,6 +34,9 @@
>>   Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
>>   Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>   ---
>> +v2:
>> +  - Fix truncated one-line summary.
>> +---
>>    drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++--
>>    drivers/gpu/drm/virtio/virtgpu_plane.c   |  6 ++++--
>>    2 files changed, 13 insertions(+), 4 deletions(-)
>>
>> Adrian
>>
> Hi Adrian,
>
> Thank you for the hint. I think you are right. I use the following patch.
>
> --- a/drivers/gpu/drm/drm_client.c    2023-11-13 01:19:07.000000000 +0100
> +++ b/drivers/gpu/drm/drm_client.c    2023-11-14 09:45:44.964199272 +0100
> @@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struc
>
>      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;
>
> This patch solved the issue.
>
> Christian
This was the first solution and it works without any problems.

Christian
  
Christian Zigotzky Dec. 8, 2023, 10:52 a.m. UTC | #9
On 25 November 2023 at 01:35 pm, Christian Zigotzky wrote:
> On 25 November 2023 at 01:22 pm, Christian Zigotzky wrote:
>> On 25 November 2023 at 12:09 pm, John Paul Adrian Glaubitz wrote:
>>> On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote:
>>>> Could you please revert the v2 patch because of the issue with the
>>>> virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of
>>>> kernel 6.7.
>>> I don't understand why the v2 patch should yield any different 
>>> results as
>>> the only change compared to v1 is the fixed patch subject. There are no
>>> functional differences, I just diffed the patches against each other:
>>>
>>> --- geert-patch-v1.patch        2023-11-25 12:09:19.122936658 +0100
>>> +++ geert-patch-v2.patch        2023-11-25 12:09:36.313039085 +0100
>>> @@ -34,6 +34,9 @@
>>>   Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
>>>   Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>>   ---
>>> +v2:
>>> +  - Fix truncated one-line summary.
>>> +---
>>>    drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++--
>>>    drivers/gpu/drm/virtio/virtgpu_plane.c   |  6 ++++--
>>>    2 files changed, 13 insertions(+), 4 deletions(-)
>>>
>>> Adrian
>>>
>> Hi Adrian,
>>
>> Thank you for the hint. I think you are right. I use the following 
>> patch.
>>
>> --- a/drivers/gpu/drm/drm_client.c    2023-11-13 01:19:07.000000000 
>> +0100
>> +++ b/drivers/gpu/drm/drm_client.c    2023-11-14 09:45:44.964199272 
>> +0100
>> @@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struc
>>
>>      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;
>>
>> This patch solved the issue.
>>
>> Christian
> This was the first solution and it works without any problems.
>
> Christian
Hi All,

The issue with the virtio-mouse-pci cursor still exists. I still use the 
patch for "a/drivers/gpu/drm/drm_client.c".

Is there any news regarding a solution?

Thanks,
Christian
  

Patch

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index ad924a8502e9025c..49c89000aec33f23 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -301,9 +301,16 @@  virtio_gpu_user_framebuffer_create(struct drm_device *dev,
 	struct virtio_gpu_framebuffer *virtio_gpu_fb;
 	int ret;
 
-	if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB8888 &&
-	    mode_cmd->pixel_format != DRM_FORMAT_HOST_ARGB8888)
+	switch (mode_cmd->pixel_format) {
+	case DRM_FORMAT_XRGB8888:
+	case DRM_FORMAT_ARGB8888:
+	case DRM_FORMAT_BGRX8888:
+	case DRM_FORMAT_BGRA8888:
+		break;
+
+	default:
 		return ERR_PTR(-ENOENT);
+	}
 
 	/* lookup object associated with res handle */
 	obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
index a2e045f3a0004a1b..a547d76b8fb0a77d 100644
--- 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_XRGB8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_BGRX8888,
 };
 
 static const uint32_t virtio_gpu_cursor_formats[] = {
-	DRM_FORMAT_HOST_ARGB8888,
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_BGRA8888,
 };
 
 uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)