No more new fbdev drivers, please

[Emil Velikov]

Hi all,

On 26 September 2015 at 19:46, Geert Uytterhoeven  
wrote:
> Hi David,
>
> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann  
> wrote:
>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>  wrote:
>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  
>>> wrote:
 On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
  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

No more new fbdev drivers, please

[Laurent Pinchart]

Hi Gerd,

On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote:
> 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 ...

config DRM_GEM_CMA_HELPER
bool
depends on DRM && HAVE_DMA_ATTRS
help
  Choose this if you need the GEM CMA helper functions

x86 defines HAVE_DMA_ATTRS.

-- 
Regards,

Laurent Pinchart

No more new fbdev drivers, please

[Gerd Hoffmann]

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

No more new fbdev drivers, please

[Daniel Vetter]

On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:
> 
> Den 27.09.2015 18:08, skrev Emil Velikov:
> >Hi all,
> >
> >On 27 September 2015 at 14:09, Noralf Trønnes  wrote:
> >>Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> >>>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".
> >>
> >>I have done some work [1] to try and make fbtft look more like the rest
> >>of the kernel (doc [2]), but that work will result in an almost complete
> >>rewrite of fbtft.
> > From a very quick skim fbtft looks pretty much like drm/panel. We
> >presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> >you had a look at these ?
> 
> Thanks, that was useful.
> I can use drm_panel to setup the controller (prepare) and do backlight
> (enable/disable), but I need a way to send framebuffer changes.
> I could do this:
> 
> struct tinydrm_panel_funcs {
> int (*update)(struct drm_framebuffer *fb,
>   struct drm_gem_cma_object *cma_obj,
>   unsigned flags, unsigned color,
>   struct drm_clip_rect *clips, unsigned num_clips);
> };
> 
> struct tinydrm_panel {
> struct drm_panel panel;
> u32 width;
> u32 height;
> void *dev_private;
> 
> const struct tinydrm_panel_funcs *funcs;
> };

I'm not sure whether putting the manual-update stuff into drm_panel is a
good idea - it's transport/bus (spi, dsi, ...) specific. Not sure how to
best solve that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

No more new fbdev drivers, please

[Daniel Vetter]

On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote:
> On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven 
>  wrote:
> > The smallest of these (udl) still counts in at ca. 2800 LoC,
> 
> Note udlfb.c, the original fbdev driver that I helped write and that the
> udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in
> the ballpark of 2x (rather than 10x) between fbdev and DRM in this case.
> That said, the complexity difference is probably higher than the LoC
> difference. I know I personally have struggled in the shift from
> understanding fbdev to understanding DRM.

udl has a bit of room for improvement, we really should push the worker
logicy for fbdev emulation into the core drm fbdev helpers using the
->dirtyfb callback. That should rip out quite a few lines.

The other thing to consider is that drm/udl supports PRIME buffer sharing
for seamlessly extending your desktop by just plugging in an usb dongle.

> The fact that there's drivers of both types and USB hardware might make udl
> may be a good driver to use as a base for any additional simplification /
> helper work. David Airlie and David Herrmann both have this hardware. David
> Airlie did the port from fbdev to DRM, so he's made it an exemplary
> driver.  And if anyone needs any hardware which works with udlfb and udl,
> we're happy to send free hardware to any programmers who are willing to
> contribute in the form of code or testing:
> http://plugable.com/projects/plugable-open-source-hardware-samples-program

For example drivers I think it's better to look at the latest drm driver
merged - those are up-to-date wrt best practices. udl has already
accumulated a bit of cruft (e.g. still using legacy modeset helpers and
not the atomic ones).

> More simplification and documentation would be great. In particular, the
> optimization for the connector+encoder+crtc combination others have
> mentioned seems like it would be worthwhile.

Atomic helpers already make almost everything optional except for the
crtc-level enable/disable callbacks and the per-plane atomic_plane_update
(for buffer flips/panning/rotation/...). So a comibined helper would be
mostly for cutting down the structure setup/teardown boilerplate. So
should be fairly easy to implement even for drm beginners (when using one
of the latest drivers as a template for what needs to be done).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

No more new fbdev drivers, please

[Noralf Trønnes]

Den 27.09.2015 18:08, skrev Emil Velikov:
> Hi all,
>
> On 27 September 2015 at 14:09, Noralf Trønnes  wrote:
>> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>> 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".
>>
>> I have done some work [1] to try and make fbtft look more like the rest
>> of the kernel (doc [2]), but that work will result in an almost complete
>> rewrite of fbtft.
>  From a very quick skim fbtft looks pretty much like drm/panel. We
> presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> you had a look at these ?

Thanks, that was useful.
I can use drm_panel to setup the controller (prepare) and do backlight
(enable/disable), but I need a way to send framebuffer changes.
I could do this:

struct tinydrm_panel_funcs {
 int (*update)(struct drm_framebuffer *fb,
   struct drm_gem_cma_object *cma_obj,
   unsigned flags, unsigned color,
   struct drm_clip_rect *clips, unsigned num_clips);
};

struct tinydrm_panel {
 struct drm_panel panel;
 u32 width;
 u32 height;
 void *dev_private;

 const struct tinydrm_panel_funcs *funcs;
};

No more new fbdev drivers, please

[Daniel Vetter]

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

No more new fbdev drivers, please

[Bernie Thompson]

On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven 
 wrote:
> The smallest of these (udl) still counts in at ca. 2800 LoC,

Note udlfb.c, the original fbdev driver that I helped write and that the
udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in
the ballpark of 2x (rather than 10x) between fbdev and DRM in this case.
That said, the complexity difference is probably higher than the LoC
difference. I know I personally have struggled in the shift from
understanding fbdev to understanding DRM.

The fact that there's drivers of both types and USB hardware might make udl
may be a good driver to use as a base for any additional simplification /
helper work. David Airlie and David Herrmann both have this hardware. David
Airlie did the port from fbdev to DRM, so he's made it an exemplary
driver.  And if anyone needs any hardware which works with udlfb and udl,
we're happy to send free hardware to any programmers who are willing to
contribute in the form of code or testing:
http://plugable.com/projects/plugable-open-source-hardware-samples-program

More simplification and documentation would be great. In particular, the
optimization for the connector+encoder+crtc combination others have
mentioned seems like it would be worthwhile.

Cheers,
Bernie

>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

No more new fbdev drivers, please

[Gerd Hoffmann]

  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

No more new fbdev drivers, please

[Emil Velikov]

Hi all,

On 27 September 2015 at 14:09, Noralf Trønnes  wrote:
>
> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>
>> 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".
>
>
> I have done some work [1] to try and make fbtft look more like the rest
> of the kernel (doc [2]), but that work will result in an almost complete
> rewrite of fbtft.
>From a very quick skim fbtft looks pretty much like drm/panel. We
presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
you had a look at these ?

Cheers,
Emil

No more new fbdev drivers, please

[Noralf Trønnes]

Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> 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".

I have done some work [1] to try and make fbtft look more like the rest
of the kernel (doc [2]), but that work will result in an almost complete
rewrite of fbtft. When Tomi showed reluctance to move sm712fb out of
staging [3], I started to look at DRM to see if I could find my way
through the myriad of helpers and objects/structs.

I now have this simplified view of DRM [4]:

struct tinydrm_device {
 struct drm_device *base;
 struct drm_plane plane;
 struct drm_crtc crtc;
 struct drm_encoder encoder;
 struct drm_connector connector;
 struct drm_fbdev_cma *fbdev_cma;
 bool enabled;
 u32 width, height;
 void *dev_private;

 int (*enable)(struct tinydrm_device *tdev);
 int (*disable)(struct tinydrm_device *tdev);

 int (*dirty)(struct drm_framebuffer *fb,
  struct drm_gem_cma_object *cma_obj,
  unsigned flags, unsigned color,
  struct drm_clip_rect *clips, unsigned num_clips);
 /* blank() is missing */
 /* maybe some modeset() function to set hw rotation */
};

Currently I'm able to get fbdev framebuffer changes through as dirty()
calls. Next step is to hook up some of the rewritten fbtft code to
actually get something on the display.

This is the display controller abstraction I use in the rewritten fbtft:

struct lcdctrl {
 struct lcdreg *lcdreg;
 u32 width;
 u32 height;
 u32 rotation;
 bool enabled;
 struct regulator *power_supply;
 void *driver_private;
 u64 flags;

 int (*poweron)(struct lcdctrl *ctrl);
 void (*poweroff)(struct lcdctrl *ctrl);
 int (*update)(struct lcdctrl *ctrl, struct lcdctrl_update *update);
 int (*rotate)(struct lcdctrl *ctrl, u32 rotation);
 int (*blank)(struct lcdctrl *ctrl, bool blank);
 bool (*check)(struct lcdctrl *ctrl, u32 value);
};

So what I would like, is to have a simple struct like this to hide the
complexity of the graphics subsystem. Leaving the driver with just a
few lines of code to setup the controller:

static int ada_mipifb_1480_poweron(struct lcdctrl *ctrl)
{
 lcdreg_reset(reg);
 lcdreg_writereg(reg, ILI9340_PWCTRL1, 0x23);
[...]
}

static int ada_mipifb_probe(struct spi_device *spi)
{
 cfg.width = 240;
 cfg.height = 320;
 cfg.addr_mode0 = ILI9340_MADCTL_MX;
 cfg.addr_mode90 = ILI9340_MADCTL_MV | ILI9340_MADCTL_MY |
   ILI9340_MADCTL_MX;
 cfg.addr_mode180 = ILI9340_MADCTL_MY;
 cfg.addr_mode270 = ILI9340_MADCTL_MV;
 cfg.bgr = true;

 reg = devm_lcdreg_spi_init(spi, LCDREG_SPI_4WIRE);

 ctrl = devm_mipi_dbi_init(reg, );
 ctrl->poweron = ada_mipifb_1480_poweron;

 return devm_lcdctrl_register(ctrl);
}


For me personally it doesn't matter whether these drivers are drm or fbdev.
fbdev has everything these drivers need, but maybe it's not such a good 
choice
for the future.


Noralf.


[1] https://github.com/notro/linux-staging/commits/next
[2] 
https://github.com/notro/linux-staging/blob/next/drivers/staging/fbtft/Documentation/fb/fbtft.txt
[3] https://lkml.org/lkml/2015/9/1/274
[4] https://gist.github.com/notro/59e0c064bc512e85e9b2

No more new fbdev drivers, please

[Dave Airlie]

On 27 September 2015 at 06:49, Rob Clark  wrote:
> On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
>  wrote:
>> Hi David,
>>
>> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann  
>> wrote:
>>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>>  wrote:
 On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  
 wrote:
> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>  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.

No more new fbdev drivers, please

[Geert Uytterhoeven]

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann  
wrote:
> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>  wrote:
>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  
>> wrote:
>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>  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 at 
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

No more new fbdev drivers, please

[David Herrmann]

Hi

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
 wrote:
> Hi Alex,
>
> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  
> wrote:
>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>  wrote:
>>> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter  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

No more new fbdev drivers, please

[Geert Uytterhoeven]

Hi Alex,

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  wrote:
> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>  wrote:
>> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter  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 at 
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

No more new fbdev drivers, please

[Rob Clark]

On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
 wrote:
> Hi David,
>
> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann  
> wrote:
>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>  wrote:
>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  
>>> wrote:
 On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
  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 at 
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

No more new fbdev drivers, please

[Alex Deucher]

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
 wrote:
> Hi Daniel,
>
> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter  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 at 
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

No more new fbdev drivers, please

[Sudip Mukherjee]

On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> Hi all,
> 
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.

> 
> 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).
Yes, it supports these and even SM712 which was recently moved out of
staging to fbdev area (which is the main reason that this thread
started) also supports dual display and 2D acceleration but those
features are not yet done in that driver.
SM750 will also have its code cleaned in few months so that it will be
ready to be moved out of staging. Right now we only have the framebuffer
driver and this hardware is being used in many laptops and notebooks. As
of now drm driver is not there for both SM712 and SM750. So then what
happens after SM750 is ready to be moved out? Will it be accepted in
fbdev or it will have to stay in staging untill a drm driver is ready?

BTW, I had a doubt about drm drivers. Is there any library or test suite
to test the driver? I am almost halfway in making a KMS driver for SM712
but still don't know how to test it properly. I was thinkig of asking
Daniel offlist but since this thread came up so asking here.

regards
sudip

No more new fbdev drivers, please

[Geert Uytterhoeven]

On Fri, Sep 25, 2015 at 12:41 PM, Kamil Lulko  wrote:
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>
>
> What about no-mmu platforms? DRM has a big fat MMU dependency in the
> kconfig, is there a way to write DRM driver for such devices?

That would indeed be a showstopper...

I dropped the dependency, and gave it a quick try for m68knommu.
Seems like DRM currently needs pgprot_writecombine() and pte_wrprotect().
Probably that can be fixed easily.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
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

No more new fbdev drivers, please

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter  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 at 
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

No more new fbdev drivers, please

[Ilia Mirkin]

On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee
 wrote:
> BTW, I had a doubt about drm drivers. Is there any library or test suite
> to test the driver? I am almost halfway in making a KMS driver for SM712
> but still don't know how to test it properly. I was thinkig of asking
> Daniel offlist but since this thread came up so asking here.

Take a look at the modetest tool, part of libdrm:
http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest

It's quite handy and contains command-line access to a lot of the
various KMS functionality, changing modes, configuring planes,
different formats, etc.

  -ilia

No more new fbdev drivers, please

[Daniel Vetter]

On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote:
> 
> 
> On 25/09/15 13:41, Kamil Lulko wrote:
> > Hi,
> > 
> >> fbdev is (more or less) maintained, but it's a deprecated framework. All
> >> new Linux display drivers should be done on DRM.
> > 
> > What about no-mmu platforms? DRM has a big fat MMU dependency in the
> > kconfig, is there a way to write DRM driver for such devices?
> 
> I guess not.
> 
> Then again, I don't see why DRM would have a hard dependency to MMU, if
> the work is done to make DRM work optionally without MMU. How much work
> that is, I have no idea.

We have plenty drivers in drm without hw mmu, and yeah there's probably no
reason at all why the drm subsystem has a hard depency on cpu MMUs. Might
be some #ifdef fallout that needs to be done, but there shouldn't be
anything fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

No more new fbdev drivers, please

[Tomi Valkeinen]

On 25/09/15 13:41, Kamil Lulko wrote:
> Hi,
> 
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
> 
> What about no-mmu platforms? DRM has a big fat MMU dependency in the
> kconfig, is there a way to write DRM driver for such devices?

I guess not.

Then again, I don't see why DRM would have a hard dependency to MMU, if
the work is done to make DRM work optionally without MMU. How much work
that is, I have no idea.

 Tom

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

No more new fbdev drivers, please

[Ondrej Zary]

On Friday 25 September 2015, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Sep 24, 2015 at 03:27:01PM +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.
>
> I was still planning to work on xgifb as I need it on some systems for
> the console.

xgifb supports these devices:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_27
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_42

Two of them are already supported by sisfb:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40

So I think that support for the remaining two (and missing features, if any) 
should be added to sisfb.

-- 
Ondrej Zary

No more new fbdev drivers, please

[Kamil Lulko]

Hi,

> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.

What about no-mmu platforms? DRM has a big fat MMU dependency in the 
kconfig, is there a way to write DRM driver for such devices?

/Kamil

No more new fbdev drivers, please

[Aaro Koskinen]

Hi,

On Thu, Sep 24, 2015 at 03:27:01PM +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.

I was still planning to work on xgifb as I need it on some systems for
the console.

A.

No more new fbdev drivers, please

[Daniel Vetter]

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

No more new fbdev drivers, please

[Ondrej Zary]

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

No more new fbdev drivers, please

[Daniel Vetter]

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

No more new fbdev drivers, please

[Daniel Vetter]

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

No more new fbdev drivers, please

[Tomi Valkeinen]

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

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

No more new fbdev drivers, please

[Thomas Petazzoni]

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

No more new fbdev drivers, please

[Austin S Hemmelgarn]

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.


-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3019 bytes
Desc: S/MIME Cryptographic Signature
URL: 

No more new fbdev drivers, please

[Alex Deucher]

On Thu, Sep 24, 2015 at 11:21 AM, 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.

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

No more new fbdev drivers, please

[Austin S Hemmelgarn]

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


-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3019 bytes
Desc: S/MIME Cryptographic Signature
URL: