Thread (1 message) 1 message, 1 author, 2015-09-29

Re: No more new fbdev drivers, please

From: Daniel Vetter <hidden>
Date: 2015-09-29 07:02:25
Also in: dri-devel, lkml

On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote:
On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven [off-list ref]
 wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help