From: Daniel Vetter <daniel@ffwll.ch>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Emil Velikov <emil.l.velikov@gmail.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fbdev <linux-fbdev@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Teddy Wang <teddy.wang@siliconmotion.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Dave Airlie <airlied@redhat.com>,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: Re: No more new fbdev drivers, please
Date: Tue, 29 Sep 2015 09:07:28 +0200 [thread overview]
Message-ID: <20150929070728.GA3383@phenom.ffwll.local> (raw)
In-Reply-To: <5609C47A.6030809@tronnes.org>
On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:
>
> Den 27.09.2015 18:08, skrev Emil Velikov:
> >Hi all,
> >
> >On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
> >>Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> >>>Hi all,
> >>>
> >>>fbdev is (more or less) maintained, but it's a deprecated framework. All
> >>>new Linux display drivers should be done on DRM.
> >>>
> >>>So let's not add any more new fbdev drivers.
> >>>
> >>>I will continue to maintain the current fbdev drivers, and I don't mind
> >>>adding some new features to those current drivers, as long as the amount
> >>>of code required to add the features stays sensible.
> >>>
> >>>I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> >>>and the question is what to do with those.
> >>>
> >>>xgifb was added in 2010, and is still in staging.
> >>>
> >>>fbtft looks like maybe some kind of framework on top of fbdev, with
> >>>fbtft specific subdrivers... I didn't look at it in detail, but my gut
> >>>says "never".
> >>
> >>I have done some work [1] to try and make fbtft look more like the rest
> >>of the kernel (doc [2]), but that work will result in an almost complete
> >>rewrite of fbtft.
> > From a very quick skim fbtft looks pretty much like drm/panel. We
> >presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> >you had a look at these ?
>
> Thanks, that was useful.
> I can use drm_panel to setup the controller (prepare) and do backlight
> (enable/disable), but I need a way to send framebuffer changes.
> I could do this:
>
> struct tinydrm_panel_funcs {
> int (*update)(struct drm_framebuffer *fb,
> struct drm_gem_cma_object *cma_obj,
> unsigned flags, unsigned color,
> struct drm_clip_rect *clips, unsigned num_clips);
> };
>
> struct tinydrm_panel {
> struct drm_panel panel;
> u32 width;
> u32 height;
> void *dev_private;
>
> const struct tinydrm_panel_funcs *funcs;
> };
I'm not sure whether putting the manual-update stuff into drm_panel is a
good idea - it's transport/bus (spi, dsi, ...) specific. Not sure how to
best solve that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2015-09-29 7:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 12:27 Tomi Valkeinen
2015-09-24 12:46 ` Thomas Petazzoni
2015-09-24 15:21 ` Austin S Hemmelgarn
2015-09-24 15:38 ` Alex Deucher
2015-09-24 15:59 ` Daniel Vetter
2015-09-24 16:17 ` Austin S Hemmelgarn
2015-09-24 17:12 ` Ondrej Zary
2015-09-24 18:05 ` Daniel Vetter
2015-09-24 15:23 ` Daniel Vetter
2015-09-26 8:28 ` Geert Uytterhoeven
2015-09-26 17:07 ` Alex Deucher
2015-09-26 18:01 ` Geert Uytterhoeven
2015-09-26 18:13 ` David Herrmann
2015-09-26 18:46 ` Geert Uytterhoeven
2015-09-26 20:49 ` Rob Clark
2015-09-26 21:55 ` Dave Airlie
2015-09-30 11:59 ` Emil Velikov
2015-09-28 7:39 ` Gerd Hoffmann
2015-09-28 12:36 ` Daniel Vetter
2015-09-29 8:23 ` Gerd Hoffmann
2015-09-29 8:33 ` Laurent Pinchart
2015-09-28 20:56 ` Bernie Thompson
[not found] ` <CAF1V4O_9LC9QM_AcE7gaV4hp4jcEe47nzKj=CXxvsnH_L=YRYw@mail.gmail.com>
2015-09-29 7:05 ` Daniel Vetter
2015-09-25 8:49 ` Aaro Koskinen
2015-09-25 11:00 ` Ondrej Zary
2015-09-26 7:15 ` Sudip Mukherjee
2015-09-26 7:29 ` Ilia Mirkin
2015-09-27 13:09 ` Noralf Trønnes
2015-09-27 16:08 ` Emil Velikov
2015-09-28 22:51 ` Noralf Trønnes
2015-09-29 7:07 ` Daniel Vetter [this message]
2015-09-25 10:41 Kamil Lulko
2015-09-25 13:09 ` Tomi Valkeinen
2015-09-25 18:44 ` Daniel Vetter
2015-09-26 9:03 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150929070728.GA3383@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@redhat.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noralf@tronnes.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=teddy.wang@siliconmotion.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome