linux-kernel - Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5683B2A0.9090901@ti.com>
Date:	Wed, 30 Dec 2015 12:32:00 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Sebastian Frias <sf84@...oste.net>
CC:	<laurent.pinchart@...asonboard.com>,
	David Airlie <airlied@...ux.ie>,
	Frans Klaver <fransklaver@...il.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	<linux-fbdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
	mason <slash.tmp@...e.fr>,
	Måns Rullgård <mans@...sr.com>,
	<dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

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

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)