Thread (54 messages) 54 messages, 17 authors, 2016-12-22

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2016-12-08 14:22:14
Also in: dri-devel, lkml

Hi Daniel,

On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter [off-list ref] wrote:
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
quoted
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter [off-list ref] wrote:
quoted
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
Since the fbdev framework is in maintenance mode and all new display drivers
should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be
applied. Only for review.
I missed the discussion where this decision was made, I admit I am
unimpressed by it.

DRM drivers don't strike me as suitable for small/slow cores with dumb
framebuffers or simple 2D only accel, such as the one found in the ASpeed
BMCs.
We have a helper for simple drivers now, if you take into account the
massive helper libraries for everything that comes along with drm I expect
if even dumb panels behind slow spi buses drm is now the more suitable
subsytem.
This has been going on your years:
  1. Fbdev is obsolete, everybody should use DRM instead!
  2. Can you please point me to a small sample driver for a dumb frame buffer?
  3. Several are being written, but none of them is upstream yet.
  4. Goto 1.
Wut. We have like 20+ small atomic drivers nowdays.
That's fast! Only two weeks ago you said:

| Bummer, they still haven't landed. But afaik there's at least 4 of
| them floating around in various places ...
quoted
quoted
That's correct, and drm can cope. And compared to fbdev there's a very
active community who improves&refactors it every kernel release to make it
even better. Since about 2 years (when atomic landed) we merge new drivers at
a rate of 2-3 per kernel release, and those new drivers get ever simpler
and smaller thanks to all this work.
You mean the kind of refactoring that causes severe merge conflicts between
drm-next and Linus' tree about every single day?
(sorry, couldn't resist ;-)
Yeah, for a subsystem that only consists of 10% of the overall kernel (by
patch count) we do an extremly shitty job. Maybe we should just all slow
down and stop merging support for new hw, and fuck Android and CrOS and
the billions of devices that don't ship upstream, who cares about those
folks.
My apologies. In hindsight, my comment sounded much more insulting than it
was meant to be.
If you're this good at mainting gpu and display subsystems, maybe you want
to take over?
No please ;-)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help