similar to: [PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer

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

On Wed, Apr 3, 2019 at 9:23 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Time to kill some bad sample code people are copying from ;) > > This is a complete rewrite of the cirrus driver. The cirrus_mode_set() > function is pretty much the only function which is carried over largely > unmodified. Everything else is upside down. > > It is a single monster patch.

Time to kill some bad sample code people are copying from ;) This is a complete rewrite of the cirrus driver. The cirrus_mode_set() function is pretty much the only function which is carried over largely unmodified. Everything else is upside down. It is a single monster patch. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

Time to kill some bad sample code people are copying from ;) This is a complete rewrite of the cirrus driver. The cirrus_mode_set() function is pretty much the only function which is carried over largely unmodified. Everything else is upside down. It is a single monster patch. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. Typically either 32bpp or 16bpp are used. Using 32bpp would limit the resolution to 800x600 due to hardware constrains. So lets go with 16bpp. Also

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

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

Time to kill some bad sample code people are copying from ;) This is a complete rewrite of the cirrus driver. The cirrus_mode_set() function is pretty much the only function which is carried over largely unmodified. Everything else is upside down. It is a single monster patch. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

Time to kill some bad sample code people are copying from ;) This is a complete rewrite of the cirrus driver. The cirrus_mode_set() function is pretty much the only function which is carried over largely unmodified. Everything else is upside down. It is a single monster patch. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.h | 1 - drivers/gpu/drm/cirrus/cirrus_mode.c | 9 ++------- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h b/drivers/gpu/drm/cirrus/cirrus_drv.h index 915709739257..828b150cdb20 100644 --- a/drivers/gpu/drm/cirrus/cirrus_drv.h +++

On Fri, Mar 30, 2018 at 03:11:17PM +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:

cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm" instead of "git rm" on them so they are still in present the tree. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.h | 250 --------------------- drivers/gpu/drm/cirrus/cirrus_ttm.c |

cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm" instead of "git rm" on them so they are still in present the tree. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.h | 250 --------------------- drivers/gpu/drm/cirrus/cirrus_ttm.c |

The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. Typically either 32bpp or 16bpp are used. Using 32bpp would limit the resolution to 800x600 due to hardware constrains. So lets go with 16bpp. Also

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,

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 Tue, Jun 20, 2017 at 09:25:24PM +0200, Peter Rosin wrote: > Hi! > > While trying to get CLUT support for the atmel_hlcdc driver, and > specifically for the emulated fbdev interface, I received some > push-back that my feeble in-driver attempts should be solved > by the core. This is my attempt to do it right. > > Boris and Daniel, was this approximately what you had in

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