mirror of
https://github.com/genesi/linux-legacy.git
synced 2026-07-09 02:06:28 +00:00
udlfb: remove since it's been merged to mainline, todo backport
This commit is contained in:
Matt Sealey
@@ -1,14 +0,0 @@
|
||||
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 an experimental driver for DisplayLink USB devices
|
||||
that provides a framebuffer device. A normal framebuffer can
|
||||
be used with this driver, or xorg can be run on the device
|
||||
using it.
|
||||
@@ -1 +0,0 @@
|
||||
obj-$(CONFIG_FB_UDL) += udlfb.o
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,117 +0,0 @@
|
||||
#ifndef UDLFB_H
|
||||
#define UDLFB_H
|
||||
|
||||
/*
|
||||
* TODO: Propose standard fb.h ioctl for reporting damage,
|
||||
* using _IOWR() and one of the existing area structs from fb.h
|
||||
* Consider these ioctls deprecated, but they're still used by the
|
||||
* DisplayLink X server as yet - need both to be modified in tandem
|
||||
* when new ioctl(s) are ready.
|
||||
*/
|
||||
#define DLFB_IOCTL_RETURN_EDID 0xAD
|
||||
#define DLFB_IOCTL_REPORT_DAMAGE 0xAA
|
||||
struct dloarea {
|
||||
int x, y;
|
||||
int w, h;
|
||||
int x2, y2;
|
||||
};
|
||||
|
||||
struct urb_node {
|
||||
struct list_head entry;
|
||||
struct dlfb_data *dev;
|
||||
struct delayed_work release_urb_work;
|
||||
struct urb *urb;
|
||||
};
|
||||
|
||||
struct urb_list {
|
||||
struct list_head list;
|
||||
spinlock_t lock;
|
||||
struct semaphore limit_sem;
|
||||
int available;
|
||||
int count;
|
||||
size_t size;
|
||||
};
|
||||
|
||||
struct dlfb_data {
|
||||
struct usb_device *udev;
|
||||
struct device *gdev; /* &udev->dev */
|
||||
struct fb_info *info;
|
||||
struct urb_list urbs;
|
||||
struct kref kref;
|
||||
char *backing_buffer;
|
||||
int fb_count;
|
||||
bool virtualized; /* true when physical usb device not present */
|
||||
struct delayed_work free_framebuffer_work;
|
||||
atomic_t usb_active; /* 0 = update virtual buffer, but no usb traffic */
|
||||
atomic_t lost_pixels; /* 1 = a render op failed. Need screen refresh */
|
||||
char *edid; /* null until we read edid from hw or get from sysfs */
|
||||
size_t edid_size;
|
||||
int sku_pixel_limit;
|
||||
int base16;
|
||||
int base8;
|
||||
u32 pseudo_palette[256];
|
||||
/* blit-only rendering path metrics, exposed through sysfs */
|
||||
atomic_t bytes_rendered; /* raw pixel-bytes driver asked to render */
|
||||
atomic_t bytes_identical; /* saved effort with backbuffer comparison */
|
||||
atomic_t bytes_sent; /* to usb, after compression including overhead */
|
||||
atomic_t cpu_kcycles_used; /* transpired during pixel processing */
|
||||
};
|
||||
|
||||
#define NR_USB_REQUEST_I2C_SUB_IO 0x02
|
||||
#define NR_USB_REQUEST_CHANNEL 0x12
|
||||
|
||||
/* -BULK_SIZE as per usb-skeleton. Can we get full page and avoid overhead? */
|
||||
#define BULK_SIZE 512
|
||||
#define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
|
||||
#define WRITES_IN_FLIGHT (4)
|
||||
|
||||
#define MIN_EDID_SIZE 128
|
||||
#define MAX_EDID_SIZE 128
|
||||
|
||||
#define MAX_VENDOR_DESCRIPTOR_SIZE 256
|
||||
|
||||
#define GET_URB_TIMEOUT HZ
|
||||
#define FREE_URB_TIMEOUT (HZ*2)
|
||||
|
||||
#define BPP 2
|
||||
#define MAX_CMD_PIXELS 255
|
||||
|
||||
#define RLX_HEADER_BYTES 7
|
||||
#define MIN_RLX_PIX_BYTES 4
|
||||
#define MIN_RLX_CMD_BYTES (RLX_HEADER_BYTES + MIN_RLX_PIX_BYTES)
|
||||
|
||||
#define RLE_HEADER_BYTES 6
|
||||
#define MIN_RLE_PIX_BYTES 3
|
||||
#define MIN_RLE_CMD_BYTES (RLE_HEADER_BYTES + MIN_RLE_PIX_BYTES)
|
||||
|
||||
#define RAW_HEADER_BYTES 6
|
||||
#define MIN_RAW_PIX_BYTES 2
|
||||
#define MIN_RAW_CMD_BYTES (RAW_HEADER_BYTES + MIN_RAW_PIX_BYTES)
|
||||
|
||||
#define DL_DEFIO_WRITE_DELAY 5 /* fb_deferred_io.delay in jiffies */
|
||||
#define DL_DEFIO_WRITE_DISABLE (HZ*60) /* "disable" with long delay */
|
||||
|
||||
/* remove these once align.h patch is taken into kernel */
|
||||
#define DL_ALIGN_UP(x, a) ALIGN(x, a)
|
||||
#define DL_ALIGN_DOWN(x, a) ALIGN(x-(a-1), a)
|
||||
|
||||
/* remove once this gets added to sysfs.h */
|
||||
#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store)
|
||||
|
||||
/*
|
||||
* udlfb is both a usb device, and a framebuffer device.
|
||||
* They may exist at the same time, but during various stages
|
||||
* inactivity, teardown, or "virtual" operation, only one or the
|
||||
* other will exist (one will outlive the other). So we can't
|
||||
* call the dev_*() macros, because we don't have a stable dev object.
|
||||
*/
|
||||
#define dl_err(format, arg...) \
|
||||
pr_err("udlfb: " format, ## arg)
|
||||
#define dl_warn(format, arg...) \
|
||||
pr_warning("udlfb: " format, ## arg)
|
||||
#define dl_notice(format, arg...) \
|
||||
pr_notice("udlfb: " format, ## arg)
|
||||
#define dl_info(format, arg...) \
|
||||
pr_info("udlfb: " format, ## arg)
|
||||
|
||||
#endif
|
||||
@@ -1,144 +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; optinally 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 notifcations 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 notifcation.
|
||||
|
||||
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 defio=1 console=1
|
||||
|
||||
Or for permanent option, create file like /etc/modprobe.d/options with text
|
||||
options udlfb defio=1 console=1
|
||||
|
||||
Accepted 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, may be able to work with this enabled.
|
||||
Disabled by default because of overhead and other issues.
|
||||
|
||||
console Allow fbcon to attach to udlfb provided framebuffers. This
|
||||
is disabled by default because fbcon will aggressively consume
|
||||
the first framebuffer it finds, which isn't usually what the
|
||||
user wants in the case of USB displays.
|
||||
|
||||
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 <bernie@plugable.com>
|
||||
Reference in New Issue
Block a user