From: Sebastian Frias <hidden> Date: 2015-12-29 13:15:35
Hi,
We are wondering what is the recommended way of adding support for a
framebuffer driver on the Linux kernel.
Below you can find a patch with a proposed solution.
Our frambuffer driver source code is provided separately, but right now
it requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be
provided by the kernel.
Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
Since we are in the process of migrating to 4.x and upstreaming changes
along the way, we would like to know if the patch below is the way to go
with it or if you have suggestions to improve it.
Thanks in advance,
Sebastian
-- >8 --
Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Signed-off-by: Sebastian Frias <redacted>
---
drivers/video/fbdev/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Frans Klaver <hidden> Date: 2015-12-29 13:49:18
On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias [off-list ref] wrote:
Hi,
We are wondering what is the recommended way of adding support for a
framebuffer driver on the Linux kernel.
Below you can find a patch with a proposed solution.
That's not really a solution to add a driver to the kernel. You'd have
to include some actual driver code as well.
Our frambuffer driver source code is provided separately, but right now it
requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be provided
by the kernel.
Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
Since we are in the process of migrating to 4.x and upstreaming changes
along the way, we would like to know if the patch below is the way to go
with it or if you have suggestions to improve it.
Is the below patch really a patch you intend to upstream, or are you
just wondering about what your Kconfig entry should look like when you
upstream your driver?
quoted hunk
Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Signed-off-by: Sebastian Frias <redacted>
---
drivers/video/fbdev/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Sebastian Frias <hidden> Date: 2015-12-29 14:06:43
On 12/29/2015 02:49 PM, Frans Klaver wrote:
On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias [off-list ref] wrote:
quoted
Hi,
We are wondering what is the recommended way of adding support for a
framebuffer driver on the Linux kernel.
Below you can find a patch with a proposed solution.
That's not really a solution to add a driver to the kernel. You'd have
to include some actual driver code as well.
We are not attempting to upstream the driver yet, that's why its code is
not included.
The patch is an attempt to allow the user to enable Framebuffer support
by providing an option for the user and then setting FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
It does the job, but we feel (and you have sort of confirmed it) that it
may not be a good idea to do it that way.
quoted
Our frambuffer driver source code is provided separately, but right now it
requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be provided
by the kernel.
Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
Since we are in the process of migrating to 4.x and upstreaming changes
along the way, we would like to know if the patch below is the way to go
with it or if you have suggestions to improve it.
Is the below patch really a patch you intend to upstream, or are you
just wondering about what your Kconfig entry should look like when you
upstream your driver?
Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:
- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
If that is not possible, I guess we will have to keep a forked tree
until the driver is upstreamed, but we would like to avoid that, hence
the question.
quoted
Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Signed-off-by: Sebastian Frias <redacted>
---
drivers/video/fbdev/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Frans Klaver <hidden> Date: 2015-12-29 14:16:36
On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias [off-list ref] wrote:
On 12/29/2015 02:49 PM, Frans Klaver wrote:
quoted
On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias [off-list ref] wrote:
quoted
Hi,
We are wondering what is the recommended way of adding support for a
framebuffer driver on the Linux kernel.
Below you can find a patch with a proposed solution.
That's not really a solution to add a driver to the kernel. You'd have
to include some actual driver code as well.
We are not attempting to upstream the driver yet, that's why its code is not
included.
The patch is an attempt to allow the user to enable Framebuffer support by
providing an option for the user and then setting FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
It does the job, but we feel (and you have sort of confirmed it) that it may
not be a good idea to do it that way.
quoted
quoted
Our frambuffer driver source code is provided separately, but right now
it
requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be
provided
by the kernel.
Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
Since we are in the process of migrating to 4.x and upstreaming changes
along the way, we would like to know if the patch below is the way to go
with it or if you have suggestions to improve it.
Is the below patch really a patch you intend to upstream, or are you
just wondering about what your Kconfig entry should look like when you
upstream your driver?
Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:
- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
If that is not possible, I guess we will have to keep a forked tree until
the driver is upstreamed, but we would like to avoid that, hence the
question.
I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.
Cheers,
Frans
From: Sebastian Frias <hidden> Date: 2015-12-29 16:51:28
On 12/29/2015 03:16 PM, Frans Klaver wrote:
On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias [off-list ref] wrote:
quoted
Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:
- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
If that is not possible, I guess we will have to keep a forked tree until
the driver is upstreamed, but we would like to avoid that, hence the
question.
I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.
From: Tomi Valkeinen <hidden> Date: 2015-12-30 08:07:20
Hi,
On 29/12/15 18:51, Sebastian Frias wrote:
On 12/29/2015 03:16 PM, Frans Klaver wrote:
quoted
On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias [off-list ref]
wrote:
quoted
Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:
- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
If that is not possible, I guess we will have to keep a forked tree
until
the driver is upstreamed, but we would like to avoid that, hence the
question.
I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.
Ok, thanks.
Also note that I don't want new fbdev drivers into the mainline kernel.
You should implement a DRM based driver instead.
Tomi
From: Sebastian Frias <hidden> Date: 2015-12-30 09:32:07
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
From: Tomi Valkeinen <hidden> Date: 2015-12-30 10:32:51
On 30/12/15 11:31, Sebastian Frias wrote:
Hi,
On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
quoted
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?
I don't think you should "port" the driver from fbdev to DRM, as the
frameworks are just so different. You should implement the driver from
scratch. Of course, the bits of code that actually touch the hardware
can possibly be copied directly.
Kernel docs contain documentation about DRM, but I don't know if there's
really a "how to write a DRM driver" style documentation. There's an
active mailing list and irc channel, though.
Does DRM provides a "fbdev" backward compatible API? Would that be
feasible?
DRM provides an fbdev "emulation". I think it's mainly aimed at
providing fb console, but many fbdev applications should work fine on
top of it.
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.
I'm not familiar with Mali, so I have no idea.
If "implement a DRM driver" is a lot of work, it would end up as a
business decision and probably would not happen.
True. It's, of course, up to you. If the fbdev driver works fine for you
and provides all the features, and you're happy with it, and there's no
requirement to get the driver to the mainline Linux, there's not much
point in going for a DRM driver.
Would you say there are good solid arguments to shake our current stack
(other than for dusting it off)?
Fbdev is the legacy framework, hopefully deprecated at some point, and
DRM is the current display framework. So DRM has much more features, is
actively developed, has a community that may help you with your issues, etc.
From purely technical point of view, it depends on the hardware in
question. If the HW supports hardware overlays and multiple outputs, DRM
supports those fully, whereas fbdev does not.
I'm not that familiar with the 3D side, but I think that can be
implemented properly with DRM, whereas on fbdev supporting 3D is always
more or less a hack.
By the way, does DRM improves 2D acceleration support over fbdev?
I don't know enough about 2D acceleration to answer that.
Tomi
From: Daniel Vetter <hidden> Date: 2016-01-04 07:09:08
On Wed, Dec 30, 2015 at 12:32:00PM +0200, Tomi Valkeinen wrote:
On 30/12/15 11:31, Sebastian Frias wrote:
quoted
Hi,
On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
quoted
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?
I don't think you should "port" the driver from fbdev to DRM, as the
frameworks are just so different. You should implement the driver from
scratch. Of course, the bits of code that actually touch the hardware
can possibly be copied directly.
Kernel docs contain documentation about DRM, but I don't know if there's
really a "how to write a DRM driver" style documentation. There's an
active mailing list and irc channel, though.
Laurent Pinchart has a presentation which gives a good overview over drm
for display drivers:
https://www.youtube.com/watch?v=5uHMpjz68HE
DRM docs are at http://dri.freedesktop.org/docs/drm/ (this version is
using asciidoc for more pretties, but you can also build it locally with
make htmldocs and then look at it in
Documentation/DocBook/drm/index.html).
quoted
Does DRM provides a "fbdev" backward compatible API? Would that be
feasible?
DRM provides an fbdev "emulation". I think it's mainly aimed at
providing fb console, but many fbdev applications should work fine on
top of it.
Modeset side should be full featured out of the box (i.e. you can change
modes), drivers have the option to overallocate (to allow the fake page
flipping using set_par) and adding 2d accel is possible.
quoted
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.
I'm not familiar with Mali, so I have no idea.
quoted
If "implement a DRM driver" is a lot of work, it would end up as a
business decision and probably would not happen.
True. It's, of course, up to you. If the fbdev driver works fine for you
and provides all the features, and you're happy with it, and there's no
requirement to get the driver to the mainline Linux, there's not much
point in going for a DRM driver.
quoted
Would you say there are good solid arguments to shake our current stack
(other than for dusting it off)?
Fbdev is the legacy framework, hopefully deprecated at some point, and
DRM is the current display framework. So DRM has much more features, is
actively developed, has a community that may help you with your issues, etc.
From purely technical point of view, it depends on the hardware in
question. If the HW supports hardware overlays and multiple outputs, DRM
supports those fully, whereas fbdev does not.
I'm not that familiar with the 3D side, but I think that can be
implemented properly with DRM, whereas on fbdev supporting 3D is always
more or less a hack.
quoted
By the way, does DRM improves 2D acceleration support over fbdev?
I don't know enough about 2D acceleration to answer that.
We've tried in-kernel accel of 2d fbdev ops in i915 and realized it's too
much work and pretty pointless. But it's definitely possible to do that,
on top of the provided fbdev emulation (e.g. gma500 has some scrolling
accel tricks). Otherwise same as 3D really, using the split
kernel/userspace driver approach.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch