On Wed, Jan 26, 2022 at 12:18 PM Helge Deller <deller@xxxxxx> wrote: > > On 1/26/22 11:31, Daniel Vetter wrote: > > On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote: > >>> Let's maintain occasional fixes to the fbtft driver. > >>> > >>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > >>> --- > >>> MAINTAINERS | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >>> index ea3e6c914384..16e614606ac1 100644 > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -7372,9 +7372,11 @@ F: Documentation/fault-injection/ > >>> F: lib/fault-inject.c > >>> > >>> FBTFT Framebuffer drivers > >>> +M: Andy Shevchenko <andy@xxxxxxxxxx> > >>> L: dri-devel@xxxxxxxxxxxxxxxxxxxxx > >>> L: linux-fbdev@xxxxxxxxxxxxxxx > >>> -S: Orphan > >>> +S: Maintained > >>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-fbtft.git > >> > >> I'm ok with the files moving if the dri developers agree with it. It's > >> up to them, not me. > > > > On one hand I'm happy anytime someone volunteers to help out. > > > > On the other hand ... why does it have to be resurrecting fbdev? > > There's an entire community of people who really know graphics and > > display and spent considerable amount of effort on creating useful and > > documented helpers for pretty much anything you might ever want to do. > > And somehow we have to go back to typing out things the hard way, with > > full verbosity, for an uapi that distros are abandoning (e.g. even for > > sdl the direction is to run it on top of drm with a compat layer, > > afaiui fedora is completely ditching any userspace that still even > > uses /dev/fb/0). And yes I know there's still some gaps in drm, > > largely for display features which were really en vogue about 20 years > > ago. And we're happy to add that support, if someone who still has > > such hardware can put in the little bit of work needed ... > > > > I don't get this. > > You are describing a transitioning over to DRM - which is Ok. > But on that way there is no need to ignore, deny or even kill usage scenarios > which are different compared to your usage scenarios (e.g. embedded devices, > old platforms, slow devices, slow busses, no 3D hardware features, > low-color devices, ...). This patchset isn't about killing existing support. This is about adding new drivers to a subsystem where consensus the past 6 years or so was that it's closed for new drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
