On Tue, Oct 15, 2019 at 07:48:29PM +0200, Daniel Vetter wrote: > On Tue, Oct 15, 2019 at 7:28 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > > > Hi Daniel > > > > Am 15.10.19 um 16:33 schrieb Daniel Vetter: > > > Hi Thomas, > > > > > > On Mon, Oct 14, 2019 at 04:04:01PM +0200, Thomas Zimmermann wrote: > > >> (was: DRM driver for fbdev devices) > > >> > > >> This is version 2 of the fbdev conversion helpers. It's more or less a > > >> rewrite of the original patchset. > > >> > > >> The fbdev subsystem is considered legacy and will probably be removed at > > >> some point. This would mean the loss of a signifanct number of drivers. > > >> Some of the affected hardware is not in use any longer, but some hardware > > >> is still around and provides good(-enough) framebuffers. > > >> > > >> The fbconv helpers allow for running the current DRM stack on top of fbdev > > >> drivers. It's a set of functions that convert between fbdev interfaces and > > >> DRM interfaces. Based on SHMEM and simple KMS helpers, it only offers the > > >> basic functionality of a framebuffer, but should be compatible with most > > >> existing fbdev drivers. > > >> > > >> A DRM driver using fbconv helpers consists of > > >> > > >> * DRM stub code that calls into fbconv helpers, and > > >> * the original fbdev driver code. > > >> > > >> The fbdev driver code has to be modified to register itself with the > > >> stub driver instead of the fbdev core framework. A tutorial on how to use > > >> the helpers is part of this patchset. The resulting driver hybrid can be > > >> refactored into a first-class DRM driver. The fbconv helpers contain a > > >> number of comments, labeled 'DRM porting note', which explain the required > > >> steps. > > >> > > >> I tested the current patchset with the following drivers: atyfb, aty128fb, > > >> matroxfb, pm2fb, pm3fb, rivafb, s3fb, savagefb, sisfb, tdfxfb and tridentfb. > > >> With each, I was able to successfully start with fbcon enabled, run weston and > > >> X11. The drivers are available at [1]. For reference, the patchset includes > > >> the Matrox stub driver. > > > > > > So I really don't want to rain on the parade here, since if you think this > > > is useful when converting fbdev drivers I'll buy that, and I'm all for > > > getting more modern drivers into drm. > > > > > > But I have a bunch of concerns with the approach you're proposing here: > > > > > > - we've tried staging for drm driver refactoring, it hurts. Separate tree > > > plus the quick pace in refactoring create lots of pains. And for small > > > drivers refacotoring before it's not buying you anything above > > > refactoring in your own personal tree. And for big drivers we're fairly > > > lenient with merging drivers that aren't fully polished yet, if there's > > > a team serious enough with cleaning up the mess. I think even merging > > > partial drivers directly under drivers/gpu (but behind CONFIG_BROKEN) is > > > better than staging. > > > > I mostly put this into staging, because it's the kind of code you'd > > expect there. > > Yeah, except we tried, it's a real pain. Conclusion by everyone > involved is that staging doesn't work for the drm subsystem. As the staging maintainer, I too agree with this. No drm drivers/code in staging please. thanks, greg k-h _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
