Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1232084 > unrolled thread

No more new fbdev drivers, please

Back to article view | Back to linux.kernel

Contents

  No more new fbdev drivers, please Tomi Valkeinen <tomi.valkeinen@ti.com> - 2015-09-24 14:30 +0200
    Re: No more new fbdev drivers, please Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2015-09-24 14:50 +0200
      Re: No more new fbdev drivers, please Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-24 17:30 +0200
        Re: No more new fbdev drivers, please Alex Deucher <alexdeucher@gmail.com> - 2015-09-24 17:40 +0200
        Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-24 18:00 +0200
          Re: No more new fbdev drivers, please Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-24 18:20 +0200
          Re: No more new fbdev drivers, please Ondrej Zary <linux@rainbow-software.org> - 2015-09-24 19:20 +0200
            Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-24 20:10 +0200
      Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-24 17:30 +0200
        Re: No more new fbdev drivers, please Geert Uytterhoeven <geert@linux-m68k.org> - 2015-09-26 10:30 +0200
          Re: No more new fbdev drivers, please Alex Deucher <alexdeucher@gmail.com> - 2015-09-26 19:10 +0200
            Re: No more new fbdev drivers, please Geert Uytterhoeven <geert@linux-m68k.org> - 2015-09-26 20:10 +0200
              Re: No more new fbdev drivers, please David Herrmann <dh.herrmann@gmail.com> - 2015-09-26 20:20 +0200
                Re: No more new fbdev drivers, please Geert Uytterhoeven <geert@linux-m68k.org> - 2015-09-26 20:50 +0200
                  Re: No more new fbdev drivers, please Rob Clark <robdclark@gmail.com> - 2015-09-26 22:50 +0200
                    Re: No more new fbdev drivers, please Dave Airlie <airlied@gmail.com> - 2015-09-27 00:00 +0200
                  Re: No more new fbdev drivers, please Emil Velikov <emil.l.velikov@gmail.com> - 2015-09-30 14:00 +0200
                Re: No more new fbdev drivers, please Gerd Hoffmann <kraxel@redhat.com> - 2015-09-28 09:50 +0200
                  Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-28 14:40 +0200
                    Re: No more new fbdev drivers, please Gerd Hoffmann <kraxel@redhat.com> - 2015-09-29 10:30 +0200
                      Re: No more new fbdev drivers, please Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2015-09-29 10:40 +0200
              Re: No more new fbdev drivers, please Bernie Thompson <bernie@plugable.com> - 2015-09-28 23:00 +0200
              Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-29 09:10 +0200
    Re: No more new fbdev drivers, please Aaro Koskinen <aaro.koskinen@iki.fi> - 2015-09-25 11:00 +0200
      Re: No more new fbdev drivers, please Ondrej Zary <linux@rainbow-software.org> - 2015-09-25 13:10 +0200
    Re: No more new fbdev drivers, please Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-26 09:20 +0200
      Re: No more new fbdev drivers, please Ilia Mirkin <imirkin@alum.mit.edu> - 2015-09-26 09:40 +0200
    Re: No more new fbdev drivers, please Noralf Trønnes <noralf@tronnes.org> - 2015-09-27 15:20 +0200
      Re: No more new fbdev drivers, please Emil Velikov <emil.l.velikov@gmail.com> - 2015-09-27 18:10 +0200
        Re: No more new fbdev drivers, please Noralf Trønnes <noralf@tronnes.org> - 2015-09-29 01:00 +0200
          Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-29 09:10 +0200

Page 1 of 2  [1] 2  Next page →

#1232084 — No more new fbdev drivers, please

[Multipart message — attachments visible in raw view] — view raw

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".

SM750 hardware seems to support multiple outputs, hardware overlays, 2D
accelerator... I think it's pointless to write an fbdev driver for such
a HW, as it's not possible to use those features with fbdev (without
custom API).

So, without spending too much time looking at those drivers, and without
speaking to the authors, my initial suggestion is to remove them.

 Tomi

[toc] | [next] | [standalone]

#1232091

Hello,

On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:

> 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".

fbtft mainly drives some very simple I2C-based or SPI-based displays,
and DRM is I believe overkill for such displays. Last time I talked
with Laurent Pinchart about such drivers, I believe he said that such
simple drivers could probably continue to use the fbdev subsystem.

Or are there some plans to make the writing of DRM drivers for very
simple/trivial devices a bit simpler?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232187

[Multipart message — attachments visible in raw view] — view raw

On 2015-09-24 08:46, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>
>> 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".
>
> fbtft mainly drives some very simple I2C-based or SPI-based displays,
> and DRM is I believe overkill for such displays. Last time I talked
> with Laurent Pinchart about such drivers, I believe he said that such
> simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the 
devices in question are (AFAIK) simple I2C or SPI connected frame-buffer 
chips that are hooked up to equally simple TFT displays.  There's no 3d 
acceleration at all from what I can tell, there's _very_ limited 2d 
acceleration, and most of the stuff that the DRM framework provides 
call-backs for would have to be done on the CPU anyway.  On top of that, 
it's targeted at small embedded systems with limited memory, and the DRM 
framework is by no-means lightweight (TBH, fbdev isn't really either, 
but it's much more light weight than DRM).

[toc] | [prev] | [next] | [standalone]

#1232197

On Thu, Sep 24, 2015 at 11:21 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2015-09-24 08:46, Thomas Petazzoni wrote:
>>
>> Hello,
>>
>> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>>
>>> 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".
>>
>>
>> fbtft mainly drives some very simple I2C-based or SPI-based displays,
>> and DRM is I believe overkill for such displays. Last time I talked
>> with Laurent Pinchart about such drivers, I believe he said that such
>> simple drivers could probably continue to use the fbdev subsystem.
>
> I have to agree, using DRM _really_ doesn't make sense for these, the
> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> chips that are hooked up to equally simple TFT displays.  There's no 3d
> acceleration at all from what I can tell, there's _very_ limited 2d
> acceleration, and most of the stuff that the DRM framework provides
> call-backs for would have to be done on the CPU anyway.

Just about all of the acceleration stuff is vendor specific so there's
really nothing you need to provide.  As Daniel noted there are several
drm drivers for simple devices that do not support any kind of 2D or
3D acceleration.  There are no requirements to provide any sort of
acceleration.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232220

On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> On 2015-09-24 08:46, Thomas Petazzoni wrote:
> >Hello,
> >
> >On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> >
> >>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".
> >
> >fbtft mainly drives some very simple I2C-based or SPI-based displays,
> >and DRM is I believe overkill for such displays. Last time I talked
> >with Laurent Pinchart about such drivers, I believe he said that such
> >simple drivers could probably continue to use the fbdev subsystem.
> I have to agree, using DRM _really_ doesn't make sense for these, the
> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> chips that are hooked up to equally simple TFT displays.  There's no 3d
> acceleration at all from what I can tell, there's _very_ limited 2d
> acceleration, and most of the stuff that the DRM framework provides
> call-backs for would have to be done on the CPU anyway.  On top of that,
> it's targeted at small embedded systems with limited memory, and the DRM
> framework is by no-means lightweight (TBH, fbdev isn't really either, but
> it's much more light weight than DRM).

See my other mail, but you can write very simple drm drivers. And if
there's really a bloat problem for small systems we can add Kconfig knobs
to throw out everything not needed for simple drivers. The only problem
really is that everyone with such simple drivers doesn't even consider drm
"because I don't have a desktop gpu" which is just silly - drm has become
rather flexible. And that's essentially why writing simple drm drivers
still has a bit too much boilerplate, since no one yet bothered to add a
bit of helper support needed.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232230

[Multipart message — attachments visible in raw view] — view raw

On 2015-09-24 11:59, Daniel Vetter wrote:
> On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
>> On 2015-09-24 08:46, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>>>
>>>> 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".
>>>
>>> fbtft mainly drives some very simple I2C-based or SPI-based displays,
>>> and DRM is I believe overkill for such displays. Last time I talked
>>> with Laurent Pinchart about such drivers, I believe he said that such
>>> simple drivers could probably continue to use the fbdev subsystem.
>> I have to agree, using DRM _really_ doesn't make sense for these, the
>> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
>> chips that are hooked up to equally simple TFT displays.  There's no 3d
>> acceleration at all from what I can tell, there's _very_ limited 2d
>> acceleration, and most of the stuff that the DRM framework provides
>> call-backs for would have to be done on the CPU anyway.  On top of that,
>> it's targeted at small embedded systems with limited memory, and the DRM
>> framework is by no-means lightweight (TBH, fbdev isn't really either, but
>> it's much more light weight than DRM).
>
> See my other mail, but you can write very simple drm drivers. And if
> there's really a bloat problem for small systems we can add Kconfig knobs
> to throw out everything not needed for simple drivers. The only problem
> really is that everyone with such simple drivers doesn't even consider drm
> "because I don't have a desktop gpu" which is just silly - drm has become
> rather flexible. And that's essentially why writing simple drm drivers
> still has a bit too much boilerplate, since no one yet bothered to add a
> bit of helper support needed.
>
Rather ironically, I got your other mail right after I sent this one.  I 
hadn't realized most of the points you made there (it's been a long time 
since I looked at any drm related code (largely because I've had 
absolutely 0 issues on my systems with it, which is a good thing :))). 
I do think being able to compile out some of the drm stuff that isn't 
used on a given system would be nice, and some good helper functions to 
simplify writing basic drivers would be absolutely wonderful.

As far as not considering it 'because I don't have a desktop GPU' goes, 
I agree, that is silly, although for some people it may be 'because my 
chip doesn't do any "rendering"', which brings up the rather complicated 
discussion of what constitutes a GPU and what 'rendering' means.

[toc] | [prev] | [next] | [standalone]

#1232266

On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
> On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> > On 2015-09-24 08:46, Thomas Petazzoni wrote:
> > >Hello,
> > >
> > >On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> > >>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".
> > >
> > >fbtft mainly drives some very simple I2C-based or SPI-based displays,
> > >and DRM is I believe overkill for such displays. Last time I talked
> > >with Laurent Pinchart about such drivers, I believe he said that such
> > >simple drivers could probably continue to use the fbdev subsystem.
> >
> > I have to agree, using DRM _really_ doesn't make sense for these, the
> > devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> > chips that are hooked up to equally simple TFT displays.  There's no 3d
> > acceleration at all from what I can tell, there's _very_ limited 2d
> > acceleration, and most of the stuff that the DRM framework provides
> > call-backs for would have to be done on the CPU anyway.  On top of that,
> > it's targeted at small embedded systems with limited memory, and the DRM
> > framework is by no-means lightweight (TBH, fbdev isn't really either, but
> > it's much more light weight than DRM).
>
> See my other mail, but you can write very simple drm drivers. And if
> there's really a bloat problem for small systems we can add Kconfig knobs
> to throw out everything not needed for simple drivers. The only problem
> really is that everyone with such simple drivers doesn't even consider drm
> "because I don't have a desktop gpu" which is just silly - drm has become
> rather flexible. And that's essentially why writing simple drm drivers
> still has a bit too much boilerplate, since no one yet bothered to add a
> bit of helper support needed.

Is there a simple way to convert existing fbdev drivers to DRM? Let's say I 
want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect, 
copyarea, imageblit) to be usable by the console (and maybe extend it to X11 
using some generic 2D driver?)

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232321

On Thu, Sep 24, 2015 at 07:12:27PM +0200, Ondrej Zary wrote:
> On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
> > On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> > > On 2015-09-24 08:46, Thomas Petazzoni wrote:
> > > >Hello,
> > > >
> > > >On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> > > >>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".
> > > >
> > > >fbtft mainly drives some very simple I2C-based or SPI-based displays,
> > > >and DRM is I believe overkill for such displays. Last time I talked
> > > >with Laurent Pinchart about such drivers, I believe he said that such
> > > >simple drivers could probably continue to use the fbdev subsystem.
> > >
> > > I have to agree, using DRM _really_ doesn't make sense for these, the
> > > devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> > > chips that are hooked up to equally simple TFT displays.  There's no 3d
> > > acceleration at all from what I can tell, there's _very_ limited 2d
> > > acceleration, and most of the stuff that the DRM framework provides
> > > call-backs for would have to be done on the CPU anyway.  On top of that,
> > > it's targeted at small embedded systems with limited memory, and the DRM
> > > framework is by no-means lightweight (TBH, fbdev isn't really either, but
> > > it's much more light weight than DRM).
> >
> > See my other mail, but you can write very simple drm drivers. And if
> > there's really a bloat problem for small systems we can add Kconfig knobs
> > to throw out everything not needed for simple drivers. The only problem
> > really is that everyone with such simple drivers doesn't even consider drm
> > "because I don't have a desktop gpu" which is just silly - drm has become
> > rather flexible. And that's essentially why writing simple drm drivers
> > still has a bit too much boilerplate, since no one yet bothered to add a
> > bit of helper support needed.
> 
> Is there a simple way to convert existing fbdev drivers to DRM? Let's say I 
> want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect, 
> copyarea, imageblit) to be usable by the console (and maybe extend it to X11 
> using some generic 2D driver?)

DRM doesn't do generic 2d accel, it's all driver specific. And consensus
for 2d accel (at least in X) is pretty much that if you have a 3d gpu use
glamour. If you don't have that then use the cpu. There's a hint for drm
userspace whether to use shadowfb for cpu rendering or not.

What you can do though if you want is keep your accel code for the fbdev
emulation on top of the drm modesetting driver, there's a few oddball
drivers who do that. And panning is of course already supported by the
modeset api.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232188

On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> 
> > 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".
> 
> fbtft mainly drives some very simple I2C-based or SPI-based displays,
> and DRM is I believe overkill for such displays. Last time I talked
> with Laurent Pinchart about such drivers, I believe he said that such
> simple drivers could probably continue to use the fbdev subsystem.
> 
> Or are there some plans to make the writing of DRM drivers for very
> simple/trivial devices a bit simpler?

Since years I'm trying to sell someone on implementing support for
drm_simple_outputs which would collapse the crtc->encoder->connector
chain into 1 entity. Would be trivial to implement and then trivial to
write simple drivers on top of that. And besides that drm already has
piles of reallly simple drivers with just one output and one framebuffer.

There's no reason not to use drm for gfx drivers at all.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233169

Hi Daniel,

On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>> Or are there some plans to make the writing of DRM drivers for very
>> simple/trivial devices a bit simpler?
>
> Since years I'm trying to sell someone on implementing support for
> drm_simple_outputs which would collapse the crtc->encoder->connector
> chain into 1 entity. Would be trivial to implement and then trivial to
> write simple drivers on top of that. And besides that drm already has
> piles of reallly simple drivers with just one output and one framebuffer.
>
> There's no reason not to use drm for gfx drivers at all.

Good to hear that!

For the (mailing list) record, can you please provide some explicit pointers
to these existing really simple drivers?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233231

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Daniel,
>
> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>>> Or are there some plans to make the writing of DRM drivers for very
>>> simple/trivial devices a bit simpler?
>>
>> Since years I'm trying to sell someone on implementing support for
>> drm_simple_outputs which would collapse the crtc->encoder->connector
>> chain into 1 entity. Would be trivial to implement and then trivial to
>> write simple drivers on top of that. And besides that drm already has
>> piles of reallly simple drivers with just one output and one framebuffer.
>>
>> There's no reason not to use drm for gfx drivers at all.
>
> Good to hear that!
>
> For the (mailing list) record, can you please provide some explicit pointers
> to these existing really simple drivers?

See the tilcdc, ast, mgag200, and udl drivers for example.

Alex

>
> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233254

Hi Alex,

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>>>> Or are there some plans to make the writing of DRM drivers for very
>>>> simple/trivial devices a bit simpler?
>>>
>>> Since years I'm trying to sell someone on implementing support for
>>> drm_simple_outputs which would collapse the crtc->encoder->connector
>>> chain into 1 entity. Would be trivial to implement and then trivial to
>>> write simple drivers on top of that. And besides that drm already has
>>> piles of reallly simple drivers with just one output and one framebuffer.
>>>
>>> There's no reason not to use drm for gfx drivers at all.
>>
>> Good to hear that!
>>
>> For the (mailing list) record, can you please provide some explicit pointers
>> to these existing really simple drivers?
>
> See the tilcdc, ast, mgag200, and udl drivers for example.

Thanks for the list!

The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
several fbdev drivers that have less than 200 LoC.
Granted, these really small ones support a single fixed video mode only, but
you can write a simple fbdev driver with mode setting in less than 1000 LoC.

I'm sure DRM can do better?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233262

Hi

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Alex,
>
> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>>>>> Or are there some plans to make the writing of DRM drivers for very
>>>>> simple/trivial devices a bit simpler?
>>>>
>>>> Since years I'm trying to sell someone on implementing support for
>>>> drm_simple_outputs which would collapse the crtc->encoder->connector
>>>> chain into 1 entity. Would be trivial to implement and then trivial to
>>>> write simple drivers on top of that. And besides that drm already has
>>>> piles of reallly simple drivers with just one output and one framebuffer.
>>>>
>>>> There's no reason not to use drm for gfx drivers at all.
>>>
>>> Good to hear that!
>>>
>>> For the (mailing list) record, can you please provide some explicit pointers
>>> to these existing really simple drivers?
>>
>> See the tilcdc, ast, mgag200, and udl drivers for example.
>
> Thanks for the list!
>
> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
> several fbdev drivers that have less than 200 LoC.
> Granted, these really small ones support a single fixed video mode only, but
> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>
> I'm sure DRM can do better?

Is counting lines really the level of the discussion to go here?

DRM is a big set of helpers, nothing else. If many trivial, small
drivers share common code, developers are more than welcome to
contribute them to drm-core and help making drivers less complex.

As Daniel mentioned, the connector+encoder+crtc combination is one of
those simplifications that would make sense if more such drivers are
added. Furthermore, the not-yet-merged SimpleDRM driver is one example
how to implement multiple of those dumb-fb drivers with a shared
code-base.

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233263

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>> to these existing really simple drivers?
>>>
>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>
>> Thanks for the list!
>>
>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>> several fbdev drivers that have less than 200 LoC.
>> Granted, these really small ones support a single fixed video mode only, but
>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>
>> I'm sure DRM can do better?
>
> Is counting lines really the level of the discussion to go here?

LoC is not the most important. But if the smallest DRM driver needs an order
of magnitude more LoC than the smallest fbdev driver, I start to wonder.

E.g. if I want to write a new simple driver for my new shiny hardware, it
can make a big difference if I have to write (and test/debug) 800 LoC, or
3000 LoC.

> DRM is a big set of helpers, nothing else. If many trivial, small
> drivers share common code, developers are more than welcome to
> contribute them to drm-core and help making drivers less complex.

Good. But from the figures above, I don't think we're at that point yet that
writing a new DRM driver is less/equal amount of work than writing a new
fbdev driver, at least for some classes of hardware. So it may be a bit
premature to put a moratorium on new fbdev drivers.
I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem
as I'd like to be.

> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added. Furthermore, the not-yet-merged SimpleDRM driver is one example
> how to implement multiple of those dumb-fb drivers with a shared
> code-base.

Thanks, looking forward to SimpleDRM!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233301

On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi David,
>
> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>> to these existing really simple drivers?
>>>>
>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>
>>> Thanks for the list!
>>>
>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>> several fbdev drivers that have less than 200 LoC.
>>> Granted, these really small ones support a single fixed video mode only, but
>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>
>>> I'm sure DRM can do better?
>>
>> Is counting lines really the level of the discussion to go here?
>
> LoC is not the most important. But if the smallest DRM driver needs an order
> of magnitude more LoC than the smallest fbdev driver, I start to wonder.

I think most of the drm/kms drivers are bigger due to more features..
iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb),
but it already supported multiple modes, page flipping, vblank
notification, etc.  It has grown since then.  Although still probably
smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using
the same tda998x bridge code with several other drivers too, compared
to downstream solution for the same)..

Probably there is room for more helpers for even more restrictive hw.

BR,
-R

> E.g. if I want to write a new simple driver for my new shiny hardware, it
> can make a big difference if I have to write (and test/debug) 800 LoC, or
> 3000 LoC.
>
>> DRM is a big set of helpers, nothing else. If many trivial, small
>> drivers share common code, developers are more than welcome to
>> contribute them to drm-core and help making drivers less complex.
>
> Good. But from the figures above, I don't think we're at that point yet that
> writing a new DRM driver is less/equal amount of work than writing a new
> fbdev driver, at least for some classes of hardware. So it may be a bit
> premature to put a moratorium on new fbdev drivers.
> I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem
> as I'd like to be.
>
>> As Daniel mentioned, the connector+encoder+crtc combination is one of
>> those simplifications that would make sense if more such drivers are
>> added. Furthermore, the not-yet-merged SimpleDRM driver is one example
>> how to implement multiple of those dumb-fb drivers with a shared
>> code-base.
>
> Thanks, looking forward to SimpleDRM!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233486

On 27 September 2015 at 06:49, Rob Clark <robdclark@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi David,
>>
>> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>>> <geert@linux-m68k.org> wrote:
>>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>>> to these existing really simple drivers?
>>>>>
>>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>>
>>>> Thanks for the list!
>>>>
>>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>>> several fbdev drivers that have less than 200 LoC.
>>>> Granted, these really small ones support a single fixed video mode only, but
>>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>>
>>>> I'm sure DRM can do better?
>>>
>>> Is counting lines really the level of the discussion to go here?
>>
>> LoC is not the most important. But if the smallest DRM driver needs an order
>> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
>
> I think most of the drm/kms drivers are bigger due to more features..
> iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb),
> but it already supported multiple modes, page flipping, vblank
> notification, etc.  It has grown since then.  Although still probably
> smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using
> the same tda998x bridge code with several other drivers too, compared
> to downstream solution for the same)..
>
> Probably there is room for more helpers for even more restrictive hw.

My main worry for having helpers for "simple" hw, is that people start
using them
to have a minimal 400loc driver, but once they add any feature outside
the helper
they have to rewrite their driver to avoid the helpers.

Most of the drm driver is boilerplate, we could possibly reduce the boilerplate,
but I'm not sure it's worth the effort to save somebody a small bit of
trouble at
bringup.

loc is a pointless tool for measuring this, a small drm driver will be as simple
as a small fbdev driver, and will likely provide more features that people need.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236215

Hi all,

On 26 September 2015 at 19:46, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi David,
>
> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>> to these existing really simple drivers?
>>>>
>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>
>>> Thanks for the list!
>>>
>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>> several fbdev drivers that have less than 200 LoC.
>>> Granted, these really small ones support a single fixed video mode only, but
>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>
>>> I'm sure DRM can do better?
>>
>> Is counting lines really the level of the discussion to go here?
>
> LoC is not the most important. But if the smallest DRM driver needs an order
> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
>
> E.g. if I want to write a new simple driver for my new shiny hardware, it
> can make a big difference if I have to write (and test/debug) 800 LoC, or
> 3000 LoC.
>
Ftr, the smallest DRM/KMS driver that I could see is the layerscape
(fsl-dcu) one. It is roughly 1.4k LoC which includes ~300 worth of
defines, licence headers and build glue. Admittedly not it's not as
low as 200-800 LoC, but it's an example that they can get smaller, as
helpers in drm core are added. udl has been written quite some time
ago and doesn't make use of atomics, etc. the latter of which should
make things easier/shorter.

Regards,
Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233922

  Hi,

> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added.

Another one is memory management.  It's pretty complex because it can
handle _way_ more than what simple drivers need, and the result is
_alot_ of ttm boilerplate in the drivers.

cheers,
  Gerd


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234093

On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > those simplifications that would make sense if more such drivers are
> > added.
> 
> Another one is memory management.  It's pretty complex because it can
> handle _way_ more than what simple drivers need, and the result is
> _alot_ of ttm boilerplate in the drivers.

ttm is pretty impressive overkill for most simplistic drm drivers. If you
just need contiguous framebuffers for display then the cma helpers should
take care of pretty much all the boilerplate for you. They have ready-made
simple gem and dumb framebuffer mmap support, which is all a basic kms
driver needs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234807

On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > those simplifications that would make sense if more such drivers are
> > > added.
> > 
> > Another one is memory management.  It's pretty complex because it can
> > handle _way_ more than what simple drivers need, and the result is
> > _alot_ of ttm boilerplate in the drivers.
> 
> ttm is pretty impressive overkill for most simplistic drm drivers. If you
> just need contiguous framebuffers for display then the cma helpers should
> take care of pretty much all the boilerplate for you. They have ready-made
> simple gem and dumb framebuffer mmap support, which is all a basic kms
> driver needs.

Does that work on !arm meanwhile?  Last time I checked (when writing
bochsdrm, around v3.14) the cma helpers didn't even build on x86 ...

cheers,
  Gerd


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web