similar to: [PATCH 03/24] drm/virtio: Place GEM BOs in drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:15PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse those. > > Signed-off-by: Daniel Stone <daniels at collabora.com> > Cc:

On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone <daniels at collabora.com> wrote: > Hi, > I've been working on a getfb2[0] ioctl, which amongst other things > supports multi-planar framebuffers as well as modifiers. getfb > currently calls the framebuffer's handle_create hook, which doesn't > support multiple planes. > > Thanks to Noralf's recent work,

No need to have our own implementation, atomic helpers can do it for us. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 7 -- drivers/gpu/drm/virtio/virtgpu_display.c | 20 +-- drivers/gpu/drm/virtio/virtgpu_fb.c | 150 ----------------------- drivers/gpu/drm/virtio/Makefile | 2 +- 4 files changed, 3 insertions(+), 176

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 Fri, Mar 30, 2018 at 03:11:16PM +0100, Daniel Stone wrote: > Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer, > we can drop it. > > Signed-off-by: Daniel Stone <daniels at collabora.com> > Cc: Dave Airlie <airlied at redhat.com> > Cc: Gerd Hoffmann <kraxel at redhat.com> > Cc: virtualization at lists.linux-foundation.org > ---

Den 09.08.2017 01.42, skrev Joe Kniss: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle() function pointer from drm_framebuffer_funcs. The > corresponding *_create_handle() function is removed from each

On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss <djmk at google.com> wrote: > On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <noralf at tronnes.org> wrote: >> >> Den 09.08.2017 01.42, skrev Joe Kniss: >>> >>> Because all drivers currently use gem objects for framebuffer planes, >>> the virtual create_handle() is not required. This change adds a

On 9 August 2017 at 09:42, Joe Kniss <djmk at chromium.org> wrote: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle() function pointer from drm_framebuffer_funcs. The > corresponding *_create_handle()

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

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

Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just the virtio resource handle. This is needed to lookup the scatter list of the object, for dma sync. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++++-- drivers/gpu/drm/virtio/virtgpu_fb.c | 2

On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <noralf at tronnes.org> wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >> create_handle()

On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <noralf at tronnes.org> wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >> create_handle()

On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <noralf at tronnes.org> wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >> create_handle()

Add create_handle support to virtio fb. Without this, screenshot tool in chromium OS can't work. Signed-off-by: Lepton Wu <ytht.net at gmail.com> --- drivers/gpu/drm/virtio/virtgpu_display.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c index b6d52055a11f..274b4206ca96 100644 ---

Add create_handle support to virtio fb. Without this, screenshot tool in chromium OS can't work. Signed-off-by: Lepton Wu <ytht.net at gmail.com> --- drivers/gpu/drm/virtio/virtgpu_display.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c index b6d52055a11f..274b4206ca96 100644 ---

Ping. On Wed, Nov 8, 2017 at 10:42 AM, Lepton Wu <ytht.net at gmail.com> wrote: > Add create_handle support to virtio fb. Without this, screenshot tool > in chromium OS can't work. > > Signed-off-by: Lepton Wu <ytht.net at gmail.com> > --- > drivers/gpu/drm/virtio/virtgpu_display.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git