No more new fbdev drivers, please

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

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

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:

quoted

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

On 2015-09-24 08:46, Thomas Petazzoni wrote:

Hello,

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

quoted

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

On Thu, Sep 24, 2015 at 11:21 AM, Austin S Hemmelgarn
[off-list ref] wrote:

On 2015-09-24 08:46, Thomas Petazzoni wrote:

quoted

Hello,

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

quoted

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

On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:

On 2015-09-24 08:46, Thomas Petazzoni wrote:

quoted

Hello,

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

quoted

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

On 2015-09-24 11:59, Daniel Vetter wrote:

On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:

quoted

On 2015-09-24 08:46, Thomas Petazzoni wrote:

quoted

Hello,

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

quoted

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.

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:

quoted

On 2015-09-24 08:46, Thomas Petazzoni wrote:

quoted

Hello,

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

quoted

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

On Thu, Sep 24, 2015 at 07:12:27PM +0200, Ondrej Zary wrote:

On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:

quoted

On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:

quoted

On 2015-09-24 08:46, Thomas Petazzoni wrote:

quoted

Hello,

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

quoted

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

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.

On Friday 25 September 2015, Aaro Koskinen wrote:

Hi,

On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:

quoted

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

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.

<snip>

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

On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee
[off-list ref] 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

Hi Daniel,

On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter [off-list ref] wrote:

On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:

quoted

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

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

Hi Daniel,

On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter [off-list ref] wrote:

quoted

On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:

quoted

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

Hi Alex,

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher [off-list ref] wrote:

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter [off-list ref] wrote:

quoted

On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:

quoted

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

Hi

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
[off-list ref] wrote:

Hi Alex,

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter [off-list ref] wrote:

quoted

On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:

quoted

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

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann [off-list ref] wrote:

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

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

On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
[off-list ref] wrote:

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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

On 27 September 2015 at 06:49, Rob Clark [off-list ref] wrote:

On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

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.

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, &cfg);
         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

Hi all,

On 27 September 2015 at 14:09, Noralf Trønnes [off-list ref] wrote:

Den 24.09.2015 14:27, skrev Tomi Valkeinen:

quoted

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

  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

On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:

  Hi,

quoted

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

On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven
[off-list ref] 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

Den 27.09.2015 18:08, skrev Emil Velikov:

Hi all,

On 27 September 2015 at 14:09, Noralf Trønnes [off-list ref] wrote:

quoted

Den 24.09.2015 14:27, skrev Tomi Valkeinen:

quoted

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;
};

On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:

Den 27.09.2015 18:08, skrev Emil Velikov:

quoted

Hi all,

On 27 September 2015 at 14:09, Noralf Trønnes [off-list ref] wrote:

quoted

Den 24.09.2015 14:27, skrev Tomi Valkeinen:

quoted

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

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:

quoted

  Hi,

quoted

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

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:

quoted

On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:

quoted

  Hi,
  

quoted

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

Hi all,

On 26 September 2015 at 19:46, Geert Uytterhoeven [off-list ref] wrote:

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher [off-list ref] wrote:

quoted

On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

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