From: Sebastian Frias <sf84@laposte.net>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>,
laurent.pinchart@ideasonboard.com,
David Airlie <airlied@linux.ie>
Cc: "Frans Klaver" <fransklaver@gmail.com>,
"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
linux-fbdev@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
mason <slash.tmp@free.fr>, "Måns Rullgård" <mans@mansr.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Date: Wed, 30 Dec 2015 09:31:56 +0000 [thread overview]
Message-ID: <5683A48C.80203@laposte.net> (raw)
In-Reply-To: <5683908C.5040001@ti.com>
Hi,
On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
>
> Also note that I don't want new fbdev drivers into the mainline kernel.
> You should implement a DRM based driver instead.
>
Thanks, is there a porting guide to go from fbdev to DRM?
Does DRM provides a "fbdev" backward compatible API? Would that be feasible?
I did not find much about that.
Currently our stack is something like:
Qt -> eglfs -> Mali -> fbdev -> mem -> output
(HW) (HW)
We don't control the eglfs/Mali (GPU) part.
From what I could see, Mali uses DRM with X11 which we do not need
(note: I'm not a Mali expert and just took a quick look at the code so I
may be wrong), which could be a problem.
If "implement a DRM driver" is a lot of work, it would end up as a
business decision and probably would not happen.
Would you say there are good solid arguments to shake our current stack
(other than for dusting it off)?
By the way, does DRM improves 2D acceleration support over fbdev?
Thanks,
Sebastian
next prev parent reply other threads:[~2015-12-30 9:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-29 13:15 [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko Sebastian Frias
2015-12-29 13:49 ` Frans Klaver
2015-12-29 14:06 ` Sebastian Frias
2015-12-29 14:16 ` Frans Klaver
2015-12-29 16:51 ` Sebastian Frias
2015-12-30 8:06 ` Tomi Valkeinen
2015-12-30 9:31 ` Sebastian Frias [this message]
2015-12-30 10:32 ` Tomi Valkeinen
2016-01-04 7:08 ` Daniel Vetter
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=5683A48C.80203@laposte.net \
--to=sf84@laposte.net \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=fransklaver@gmail.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mans@mansr.com \
--cc=plagnioj@jcrosoft.com \
--cc=slash.tmp@free.fr \
--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;
as well as URLs for NNTP newsgroup(s).