linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	linux-fbdev@vger.kernel.org, geert+renesas@glider.be,
	corbet@lwn.net, daniel.vetter@ffwll.ch,
	linux-doc@vger.kernel.org, bernie@plugable.com,
	dri-devel@lists.freedesktop.org, sam@ravnborg.org
Subject: Re: [PATCH] fbdev: Remove udlfb driver
Date: Mon, 30 Nov 2020 16:41:47 +0100	[thread overview]
Message-ID: <20201130154147.GT401619@phenom.ffwll.local> (raw)
In-Reply-To: <alpine.LRH.2.02.2011300843270.29199@file01.intranet.prod.int.rdu2.redhat.com>

On Mon, Nov 30, 2020 at 09:31:15AM -0500, Mikulas Patocka wrote:
> 
> 
> On Mon, 30 Nov 2020, Thomas Zimmermann wrote:
> 
> > Udlfb has been superseded by DRM's udl. The DRM driver is better by
> > any means and actively maintained. Remove udlfb.
> 
> Hi
> 
> I am using udlfb and it's definitely better than the DRM driver. The DRM 
> driver will crash the kernel if you unplug the device while Xorg is 
> running. The framebuffer driver doesn't crash in this case. (I have a cat 
> and the cat sometimes unplugs cables and I don't want to reboot the system 
> because of it :-)

This should be a lot better in recent kernels, there's been tons of fixes
for drm hotunplug. Might be there's still bugs in the drm/udl driver.

> The framebuffer driver is faster, it keeps back buffer and updates only 
> data that differ between the front and back buffer. The DRM driver doesn't 
> have such optimization, it will update everything in a given rectangle - 
> this increases USB traffic and makes video playback more jerky.
> 
> The framebuffer driver supports programs running full-screen directly on 
> the framebuffer console, such as web browser "links -g", image viewer 
> "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", 
> movie player "mplayer -vo fbdev". The DRM driver doesn't run them.

Hm this should in general work on drm drivers. Without that it's clear the
switch-over isn't really ready yet.

> If you seach for someone to maintain the framebuffer driver, I can do it.

We're looking for people to port the missing features over to the drm
drivers. The problem is that fbdev is full of security bugs, and we're
fixing them by removing the features. So that's why there's some push to
sunset at much as possible.
-Daniel

> 
> Mikulas
> 
> 
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> >  CREDITS                      |    5 +
> >  Documentation/fb/index.rst   |    1 -
> >  Documentation/fb/udlfb.rst   |  162 ---
> >  MAINTAINERS                  |    9 -
> >  drivers/video/fbdev/Kconfig  |   17 +-
> >  drivers/video/fbdev/Makefile |    1 -
> >  drivers/video/fbdev/udlfb.c  | 1994 ----------------------------------
> >  7 files changed, 6 insertions(+), 2183 deletions(-)
> >  delete mode 100644 Documentation/fb/udlfb.rst
> >  delete mode 100644 drivers/video/fbdev/udlfb.c
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2020-11-30 15:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 12:52 [PATCH] fbdev: Remove udlfb driver Thomas Zimmermann
2020-11-30 14:31 ` Mikulas Patocka
2020-11-30 15:41   ` Daniel Vetter [this message]
2020-11-30 18:39     ` Mikulas Patocka
2020-11-30 21:06       ` Daniel Vetter
2020-12-01 11:26         ` Mikulas Patocka
2020-12-01  8:07       ` Thomas Zimmermann
2020-12-01 11:20         ` Mikulas Patocka
2020-12-02  7:55           ` Thomas Zimmermann
2020-12-02  8:01             ` Thomas Zimmermann
2020-12-02  8:29             ` Pekka Paalanen
2020-12-02 17:52             ` Daniel Vetter
2020-12-01  8:02   ` Thomas Zimmermann
2020-12-01 10:44     ` Mikulas Patocka
2020-12-01 20:09       ` Mikulas Patocka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201130154147.GT401619@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=bernie@plugable.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=sam@ravnborg.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).