From patchwork Mon Nov 30 12:52:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Zimmermann X-Patchwork-Id: 334881 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EA42C64E8A for ; Mon, 30 Nov 2020 12:52:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C5C9A207F7 for ; Mon, 30 Nov 2020 12:52:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725925AbgK3Mws (ORCPT ); Mon, 30 Nov 2020 07:52:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:55038 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725900AbgK3Mws (ORCPT ); Mon, 30 Nov 2020 07:52:48 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3996BAB63; Mon, 30 Nov 2020 12:52:03 +0000 (UTC) From: Thomas Zimmermann To: daniel.vetter@ffwll.ch, mpatocka@redhat.com, sam@ravnborg.org, geert+renesas@glider.be, bernie@plugable.com, corbet@lwn.net Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-doc@vger.kernel.org, Thomas Zimmermann Subject: [PATCH] fbdev: Remove udlfb driver Date: Mon, 30 Nov 2020 13:52:00 +0100 Message-Id: <20201130125200.10416-1-tzimmermann@suse.de> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org Udlfb has been superseded by DRM's udl. The DRM driver is better by any means and actively maintained. Remove udlfb. Signed-off-by: Thomas Zimmermann --- 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 diff --git a/CREDITS b/CREDITS index 748301954ab7..fed3518c4dd8 100644 --- a/CREDITS +++ b/CREDITS @@ -3620,6 +3620,11 @@ S: 145 Howard St. S: Northborough, MA 01532 S: USA +N: Bernie Thompson +E: bernie@plugable.com +W: http://plugable.com/category/projects/udlfb/ +D: DisplayLink USB 2.0 framebuffer driver + N: Doug Thompson E: dougthompson@xmission.com D: EDAC diff --git a/Documentation/fb/index.rst b/Documentation/fb/index.rst index baf02393d8ee..8136c84328e2 100644 --- a/Documentation/fb/index.rst +++ b/Documentation/fb/index.rst @@ -36,7 +36,6 @@ Frame Buffer sstfb tgafb tridentfb - udlfb uvesafb vesafb viafb diff --git a/Documentation/fb/udlfb.rst b/Documentation/fb/udlfb.rst deleted file mode 100644 index 732b37db3504..000000000000 --- a/Documentation/fb/udlfb.rst +++ /dev/null @@ -1,162 +0,0 @@ -============== -What is udlfb? -============== - -This is a driver for DisplayLink USB 2.0 era graphics chips. - -DisplayLink chips provide simple hline/blit operations with some compression, -pairing that with a hardware framebuffer (16MB) on the other end of the -USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI -monitor with no CPU involvement until a pixel has to change. - -The CPU or other local resource does all the rendering; optionally compares the -result with a local shadow of the remote hardware framebuffer to identify -the minimal set of pixels that have changed; and compresses and sends those -pixels line-by-line via USB bulk transfers. - -Because of the efficiency of bulk transfers and a protocol on top that -does not require any acks - the effect is very low latency that -can support surprisingly high resolutions with good performance for -non-gaming and non-video applications. - -Mode setting, EDID read, etc are other bulk or control transfers. Mode -setting is very flexible - able to set nearly arbitrary modes from any timing. - -Advantages of USB graphics in general: - - * Ability to add a nearly arbitrary number of displays to any USB 2.0 - capable system. On Linux, number of displays is limited by fbdev interface - (FB_MAX is currently 32). Of course, all USB devices on the same - host controller share the same 480Mbs USB 2.0 interface. - -Advantages of supporting DisplayLink chips with kernel framebuffer interface: - - * The actual hardware functionality of DisplayLink chips matches nearly - one-to-one with the fbdev interface, making the driver quite small and - tight relative to the functionality it provides. - * X servers and other applications can use the standard fbdev interface - from user mode to talk to the device, without needing to know anything - about USB or DisplayLink's protocol at all. A "displaylink" X driver - and a slightly modified "fbdev" X driver are among those that already do. - -Disadvantages: - - * Fbdev's mmap interface assumes a real hardware framebuffer is mapped. - In the case of USB graphics, it is just an allocated (virtual) buffer. - Writes need to be detected and encoded into USB bulk transfers by the CPU. - Accurate damage/changed area notifications work around this problem. - In the future, hopefully fbdev will be enhanced with an small standard - interface to allow mmap clients to report damage, for the benefit - of virtual or remote framebuffers. - * Fbdev does not arbitrate client ownership of the framebuffer well. - * Fbcon assumes the first framebuffer it finds should be consumed for console. - * It's not clear what the future of fbdev is, given the rise of KMS/DRM. - -How to use it? -============== - -Udlfb, when loaded as a module, will match against all USB 2.0 generation -DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID -of the monitor, and set the best common mode between the DisplayLink device -and the monitor's capabilities. - -If the DisplayLink device is successful, it will paint a "green screen" which -means that from a hardware and fbdev software perspective, everything is good. - -At that point, a /dev/fb? interface will be present for user-mode applications -to open and begin writing to the framebuffer of the DisplayLink device using -standard fbdev calls. Note that if mmap() is used, by default the user mode -application must send down damage notifications to trigger repaints of the -changed regions. Alternatively, udlfb can be recompiled with experimental -defio support enabled, to support a page-fault based detection mechanism -that can work without explicit notification. - -The most common client of udlfb is xf86-video-displaylink or a modified -xf86-video-fbdev X server. These servers have no real DisplayLink specific -code. They write to the standard framebuffer interface and rely on udlfb -to do its thing. The one extra feature they have is the ability to report -rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's -damage interface (which will hopefully be standardized for all virtual -framebuffers that need damage info). These damage notifications allow -udlfb to efficiently process the changed pixels. - -Module Options -============== - -Special configuration for udlfb is usually unnecessary. There are a few -options, however. - -From the command line, pass options to modprobe -modprobe udlfb fb_defio=0 console=1 shadow=1 - -Or modify options on the fly at /sys/module/udlfb/parameters directory via -sudo nano fb_defio -change the parameter in place, and save the file. - -Unplug/replug USB device to apply with new settings - -Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text -options udlfb fb_defio=0 console=1 shadow=1 - -Accepted boolean options: - -=============== ================================================================ -fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel - module to track changed areas of the framebuffer by page faults. - Standard fbdev applications that use mmap but that do not - report damage, should be able to work with this enabled. - Disable when running with X server that supports reporting - changed regions via ioctl, as this method is simpler, - more stable, and higher performance. - default: fb_defio=1 - -console Allow fbcon to attach to udlfb provided framebuffers. - Can be disabled if fbcon and other clients - (e.g. X with --shared-vt) are in conflict. - default: console=1 - -shadow Allocate a 2nd framebuffer to shadow what's currently across - the USB bus in device memory. If any pixels are unchanged, - do not transmit. Spends host memory to save USB transfers. - Enabled by default. Only disable on very low memory systems. - default: shadow=1 -=============== ================================================================ - -Sysfs Attributes -================ - -Udlfb creates several files in /sys/class/graphics/fb? -Where ? is the sequential framebuffer id of the particular DisplayLink device - -======================== ======================================================== -edid If a valid EDID blob is written to this file (typically - by a udev rule), then udlfb will use this EDID as a - backup in case reading the actual EDID of the monitor - attached to the DisplayLink device fails. This is - especially useful for fixed panels, etc. that cannot - communicate their capabilities via EDID. Reading - this file returns the current EDID of the attached - monitor (or last backup value written). This is - useful to get the EDID of the attached monitor, - which can be passed to utilities like parse-edid. - -metrics_bytes_rendered 32-bit count of pixel bytes rendered - -metrics_bytes_identical 32-bit count of how many of those bytes were found to be - unchanged, based on a shadow framebuffer check - -metrics_bytes_sent 32-bit count of how many bytes were transferred over - USB to communicate the resulting changed pixels to the - hardware. Includes compression and protocol overhead - -metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the - above pixels (in thousands of cycles). - -metrics_reset Write-only. Any write to this file resets all metrics - above to zero. Note that the 32-bit counters above - roll over very quickly. To get reliable results, design - performance tests to start and finish in a very short - period of time (one minute or less is safe). -======================== ======================================================== - -Bernie Thompson diff --git a/MAINTAINERS b/MAINTAINERS index c5a399541d6a..2b445f87e1ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5178,15 +5178,6 @@ F: fs/quota/ F: include/linux/quota*.h F: include/uapi/linux/quota*.h -DISPLAYLINK USB 2.0 FRAMEBUFFER DRIVER (UDLFB) -M: Bernie Thompson -L: linux-fbdev@vger.kernel.org -S: Maintained -W: http://plugable.com/category/projects/udlfb/ -F: Documentation/fb/udlfb.rst -F: drivers/video/fbdev/udlfb.c -F: include/video/udlfb.h - DISTRIBUTED LOCK MANAGER (DLM) M: Christine Caulfield M: David Teigland diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 4f02db65dede..41189b31c5d6 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -558,7 +558,7 @@ config FB_STI BIOS routines contained in a ROM chip in HP PA-RISC based machines. Enabling this option will implement the linux framebuffer device using calls to the STI BIOS routines for initialisation. - + If you enable this option, you will get a planar framebuffer device /dev/fb which will work on the most common HP graphic cards of the NGLE family, including the artist chips (in the 7xx and Bxxx series), @@ -1939,21 +1939,6 @@ config FB_SMSCUFX (USB 3.0) devices. To compile as a module, choose M here: the module name is smscufx. -config FB_UDL - tristate "Displaylink USB Framebuffer support" - depends on FB && USB - select FB_MODE_HELPERS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO - help - This is a kernel framebuffer driver for DisplayLink USB devices. - Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and - mplayer -vo fbdev. Supports all USB 2.0 era DisplayLink devices. - To compile as a module, choose M here: the module name is udlfb. - config FB_IBM_GXT4500 tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors" depends on FB diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile index 477b9624b703..49b5dd0bef02 100644 --- a/drivers/video/fbdev/Makefile +++ b/drivers/video/fbdev/Makefile @@ -106,7 +106,6 @@ obj-$(CONFIG_FB_COBALT) += cobalt_lcdfb.o obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o obj-$(CONFIG_FB_PS3) += ps3fb.o obj-$(CONFIG_FB_SM501) += sm501fb.o -obj-$(CONFIG_FB_UDL) += udlfb.o obj-$(CONFIG_FB_SMSCUFX) += smscufx.o obj-$(CONFIG_FB_XILINX) += xilinxfb.o obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c deleted file mode 100644 index f9b3c1cb9530..000000000000 --- a/drivers/video/fbdev/udlfb.c +++ /dev/null @@ -1,1994 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* - * udlfb.c -- Framebuffer driver for DisplayLink USB controller - * - * Copyright (C) 2009 Roberto De Ioris - * Copyright (C) 2009 Jaya Kumar - * Copyright (C) 2009 Bernie Thompson - * - * Layout is based on skeletonfb by James Simmons and Geert Uytterhoeven, - * usb-skeleton by GregKH. - * - * Device-specific portions based on information from Displaylink, with work - * from Florian Echtler, Henrik Bjerregaard Pedersen, and others. - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include