similar to: [PATCH 4/6] drm: fourcc byteorder: adapt bochs-drm to drm_mode_legacy_fb_format update

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Create our own plane and use drm_crtc_init_with_planes() instead of depending on the default created by drm_crtc_init(). That way the plane format list is correct on bigendian machines.

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver feature flag so drm_mode_addfb() asks for the correct format code. Create our own plane and use drm_crtc_init_with_planes() instead of depending on the default created by drm_crtc_init(). That way the plane format list is correct on bigendian machines. With

On Wed, Sep 05, 2018 at 04:41:27PM +0200, Peter Wu wrote: > Currently unloading bochs_drm (after unbinding the vtconsole) results in > a warning about a leaked connector: > > [drm:drm_mode_config_cleanup] *ERROR* connector Virtual-3 leaked! > > While investigating a potential fix I noticed that a lot of open-coded > functionality is already implemented elsewhere, so

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 2 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ------------------------------- 2 files changed, 1 insertion(+), 32 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index cc025d8fbe..4f2c2dc731 100644 ---

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 2 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ------------------------------- 2 files changed, 1 insertion(+), 32 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index cc025d8fbe..4f2c2dc731 100644 ---

bochs_fbdev.c is almost empty now. Move the remaining framebuffer bits over to bochs_kms.c. Pure code motion. No functional change. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs_fbdev.c | 29 ----------------------------- drivers/gpu/drm/bochs/bochs_kms.c | 17 +++++++++++++++++ drivers/gpu/drm/bochs/Makefile | 2 +- 3 files changed, 18

Add bochs_hw_set_*_endian() helper functions, to set the framebuffer byteorder at mode set time. Support both DRM_FORMAT_XRGB8888 and DRM_FORMAT_BGRX8888 framebuffer formats, no matter what the native machine byte order is. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs.h | 4 ++- drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +-

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Create our own plane and use drm_crtc_init_with_planes() instead of depending on the default created by drm_crtc_init(). That way the plane format list is correct on bigendian machines.

While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: support a single format only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 5 ++++-

While wading through the code I've noticed we have a little issue in virtio: We attach a format to the bo when it is created (DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer (DRM_IOCTL_MODE_ADDFB). Easy way out: support a single format only. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 5 ++++-

Factors out code, no functional change. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_fb.c | 58 +---------------------------- drivers/gpu/drm/virtio/virtgpu_plane.c | 68 ++++++++++++++++++++++++++++++++++ 3 files changed, 71 insertions(+), 56 deletions(-) diff --git

Factors out code, no functional change. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_fb.c | 58 +---------------------------- drivers/gpu/drm/virtio/virtgpu_plane.c | 68 ++++++++++++++++++++++++++++++++++ 3 files changed, 71 insertions(+), 56 deletions(-) diff --git

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb()

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb()

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver feature flag so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb()

On Mon, Apr 03, 2017 at 09:08:44AM +0200, Gerd Hoffmann wrote: > Factors out code, no functional change. > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Ugh on the big endian define, I guess we'll never managed to figure this aspect of drm pixel formats out correctly - they're supposed to encode endinaness. But the copy-paste looks correct :-) Acked-by: Daniel

Not needed any more, bochs uses the generic emulation now. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs.h | 9 --- drivers/gpu/drm/bochs/bochs_drv.c | 6 -- drivers/gpu/drm/bochs/bochs_fbdev.c | 137 ------------------------------------ 3 files changed, 152 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h

The bochs driver (and virtual hardware) requires buffer objects to reside in video ram to display them to the screen. So it can not display the framebuffer console because the respective buffer object is permanently pinned in system memory. Using a shadow buffer for the console solves this problem. The console emulation will pin the buffer object only during updates from the shadow buffer.

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 14 --- drivers/gpu/drm/virtio/virtgpu_display.c | 1 - drivers/gpu/drm/virtio/virtgpu_drv.c | 9 +- drivers/gpu/drm/virtio/virtgpu_fb.c | 191 ------------------------------- drivers/gpu/drm/virtio/virtgpu_kms.c | 8 -- 5 files changed, 8 insertions(+), 215 deletions(-)

This patch replaces mgag200's framebuffer console with DRM's generic implememtation. All respective code is being removed from the driver. The console is set up with a shadow buffer. The actual buffer object is not permanently pinned in video ram, but just another buffer object that the driver moves in and out of vram as necessary. The driver's function mga_crtc_do_set_base() used to