similar to: [PATCH] drm/cirrus: rewrite and modernize driver.

On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote: > On Wed, Apr 3, 2019 at 5:23 PM 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

On Wed, Apr 3, 2019 at 5:23 PM 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.

On Thu, Apr 4, 2019 at 7:51 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote: > > On Wed, Apr 3, 2019 at 5:23 PM 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

On Thu, Apr 4, 2019 at 7:51 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote: > > On Wed, Apr 3, 2019 at 5:23 PM 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

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

Hi, > > tinydrm_xrgb8888_to_* > > > > imo these could be put into some drm_format_helpers.c to be shared. > > I agree, my long term goal is to get rid of tinydrm.ko. Just haven't got > there yet. > > Gerd, if you end up using some of those functions, feel free to move > just those you need and I can do the rest later. But if you have time to > spare I

> > +struct cirrus_device { > > + struct drm_device *dev; > > Why not embed drm_device? It's the latest rage :-) Sure, can do that. > > +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe, > > + struct drm_plane_state *old_state) > > +{ > > + struct drm_plane_state *state =

> > +struct cirrus_device { > > + struct drm_device *dev; > > Why not embed drm_device? It's the latest rage :-) Sure, can do that. > > +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe, > > + struct drm_plane_state *old_state) > > +{ > > + struct drm_plane_state *state =

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

Den 03.04.2019 10.53, skrev Gerd Hoffmann: >>> +struct cirrus_device { >>> + struct drm_device *dev; >> >> Why not embed drm_device? It's the latest rage :-) > > Sure, can do that. > >>> +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe, >>> + struct drm_plane_state *old_state)

On Thu, Apr 4, 2019 at 10:30 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Hi, > > > > Speaking of wayland: Seems at least gnome-shell insists on using XR24. > > > > Yeah XR24 is pretty much mandatory. Noralf added a few helpers to > > convert XR24 to other formats, for display not supporting anything > > else. Because userspace. > >

On Thu, Apr 4, 2019 at 10:30 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Hi, > > > > Speaking of wayland: Seems at least gnome-shell insists on using XR24. > > > > Yeah XR24 is pretty much mandatory. Noralf added a few helpers to > > convert XR24 to other formats, for display not supporting anything > > else. Because userspace. > >

Hi, > > Speaking of wayland: Seems at least gnome-shell insists on using XR24. > > Yeah XR24 is pretty much mandatory. Noralf added a few helpers to > convert XR24 to other formats, for display not supporting anything > else. Because userspace. Have a pointer to these helpers? grepping around in drm didn't turn up anything so far ... thanks, Gerd

Den 04.04.2019 10.52, skrev Daniel Vetter: > On Thu, Apr 4, 2019 at 10:30 AM Gerd Hoffmann <kraxel at redhat.com> wrote: >> >> Hi, >> >>>> Speaking of wayland: Seems at least gnome-shell insists on using XR24. >>> >>> Yeah XR24 is pretty much mandatory. Noralf added a few helpers to >>> convert XR24 to other formats, for display

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

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

Update the cirrus driver to follow current best practices. While the driver's hardware is obsolete, the cirrus driver is still one of the go-to modules to learn about writing a DRM driver. So keep it in good shape. Patches 1 to 3 simplify blitting and convert it to the DRM's current helpers. Patches 4 to 8 replace simple-KMS helpers with DRM's regular atomic helpers. The former are