similar to: [PATCH v3 3/5] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.

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

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 +-

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

Conversion to atomic modesetting, step three. Wire up atomic helpers. Switch planes to atomic. We are late to the party, the transitional helpers are gone, so this can't be splitted into smaller steps any more. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs_fbdev.c | 3 ++ drivers/gpu/drm/bochs/bochs_kms.c | 70

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

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

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()

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/bochs/bochs.h | 6 +- drivers/gpu/drm/bochs/bochs_kms.c | 178 +++++++++--------------------- 2 files changed, 53 insertions(+), 131 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index a7f6723bebdd..36f6ee725d13 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++

It's always NULL, so just remove it. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/bochs/bochs.h | 2 +- drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +- drivers/gpu/drm/bochs/bochs_kms.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 11 +---------- 4 files changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h

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

This patch replaces ast'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 ast_crtc_do_set_base() used to

On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > Hi, > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > +#ifdef __BIG_ENDIAN > > > + DRM_FORMAT_BGRA8888, > > > +#else > > > DRM_FORMAT_ARGB8888, > > > +#endif > > > > DRM formats are supposed to be little endian, so this isn't really

Hi, > Hmm. Maybe it's still possible to salvage something by redefining the > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > might still result in something usable. Also at least for the virtual machine use case this doesn't buy us much. The drm drivers (at least the ones used on both big and little endian guests) support only 32 bpp + depth 24

On Fr, 2017-04-07 at 11:45 +0300, Ville Syrj?l? wrote: > On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > Hmm. Maybe it's still possible to salvage something by redefining the > > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > > might still result in something usable. > >

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > > > > DRM_FORMAT_ARGB8888, > >