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 <[email protected]>
---
drivers/video/fbdev/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e6d16d6..46c4ab2 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -615,6 +615,16 @@ config FB_BF537_LQ035
To compile this driver as a module, choose M here: the
module will be called bf537-lq035.
+config FB_TANGO
+ bool "Sigma Designs FrameBuffer support"
+ depends on FB && ARCH_TANGO
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ You need to enable this if you intend to use Sigma
+ Designs' smp8xxxfb.ko driver.
+
config FB_BFIN_7393
tristate "Blackfin ADV7393 Video encoder"
depends on FB && BLACKFIN
--
1.7.10.4
On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <[email protected]> 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?
> Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
>
> Signed-off-by: Sebastian Frias <[email protected]>
> ---
> drivers/video/fbdev/Kconfig | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index e6d16d6..46c4ab2 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -615,6 +615,16 @@ config FB_BF537_LQ035
> To compile this driver as a module, choose M here: the
> module will be called bf537-lq035.
>
> +config FB_TANGO
> + bool "Sigma Designs FrameBuffer support"
> + depends on FB && ARCH_TANGO
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + help
> + You need to enable this if you intend to use Sigma
> + Designs' smp8xxxfb.ko driver.
> +
> config FB_BFIN_7393
> tristate "Blackfin ADV7393 Video encoder"
> depends on FB && BLACKFIN
Frans
On 12/29/2015 02:49 PM, Frans Klaver wrote:
> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <[email protected]> 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.
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.
>
>
>> 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.
>
>
>> Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
>>
>> Signed-off-by: Sebastian Frias <[email protected]>
>> ---
>> drivers/video/fbdev/Kconfig | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index e6d16d6..46c4ab2 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -615,6 +615,16 @@ config FB_BF537_LQ035
>> To compile this driver as a module, choose M here: the
>> module will be called bf537-lq035.
>>
>> +config FB_TANGO
>> + bool "Sigma Designs FrameBuffer support"
>> + depends on FB && ARCH_TANGO
>> + select FB_CFB_FILLRECT
>> + select FB_CFB_COPYAREA
>> + select FB_CFB_IMAGEBLIT
>> + help
>> + You need to enable this if you intend to use Sigma
>> + Designs' smp8xxxfb.ko driver.
>> +
>> config FB_BFIN_7393
>> tristate "Blackfin ADV7393 Video encoder"
>> depends on FB && BLACKFIN
>
> Frans
>
On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <[email protected]> wrote:
> On 12/29/2015 02:49 PM, Frans Klaver wrote:
>>
>> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <[email protected]> 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.
>
>
> 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.
>
>>
>>
>>> 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
On 12/29/2015 03:16 PM, Frans Klaver wrote:
> On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <[email protected]> wrote:
>> 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.
Hi,
On 29/12/15 18:51, Sebastian Frias wrote:
> On 12/29/2015 03:16 PM, Frans Klaver wrote:
>> On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <[email protected]>
>> wrote:
>>> 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
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
On 30/12/15 11:31, Sebastian Frias wrote:
> 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?
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