similar to: [PATCH 02/24] drm/cirrus: cirrus_framebuffer -> 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 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 ---

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

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

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

On Thu, Jun 22, 2017 at 08:06:23AM +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. > > I have obviously not tested all of this with more than a

On Tue, Jul 04, 2017 at 12:36:56PM +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. > > I have obviously not tested all of this with more than a

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. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

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. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

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. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest