Re: 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 <geert@xxxxxxxxxxxxxx>
>  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/