linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bernie@plugable.com
To: linux-fbdev@vger.kernel.org
Subject: [PATCH 5/6] udlfb: Enable fb_defio by default
Date: Sun, 21 Aug 2011 20:35:38 +0000	[thread overview]
Message-ID: <1313958939-5681-5-git-send-email-bernie@plugable.com> (raw)

From: Bernie Thompson <bernie@plugable.com>

Enables page fault based detection of mmap writes to the framebuffer,
which allows standard fbdev apps (like the generic fbdev xorg driver)
to work on DisplayLink devices.

Not all bugs are shaken out of the fb_defio path of udlfb, but it's
tantalizingly close, so this seems a good time to enable by default.

Alternatively, option can be disabled when running with an xorg driver
that can more directly communicate damaged regions of the framebuffer
via IOCTL. This is a simpler, higher perf option, when available.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
 Documentation/fb/udlfb.txt |   24 ++++++++++++++++--------
 drivers/video/udlfb.c      |    4 ++--
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
index 473ceed..c6d90a6 100644
--- a/Documentation/fb/udlfb.txt
+++ b/Documentation/fb/udlfb.txt
@@ -87,20 +87,28 @@ 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
+modprobe udlfb fb_defio=0 console=1 shadow=1
 
-Or for permanent option, create file like /etc/modprobe.d/options with text
-options udlfb defio=1 console=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.
 
-Accepted options:
+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, may be able to work with this enabled.
-		Disabled by default because of overhead and other issues.
+		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.
 
-console		Allow fbcon to attach to udlfb provided framebuffers. This
+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.
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 5a13dc5..5207bd2 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -71,7 +71,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 
 /* module options */
 static int console;   /* Optionally allow fbcon to consume first framebuffer */
-static int fb_defio;  /* Optionally enable experimental fb_defio mmap support */
+static int fb_defio = 1;  /* Detect mmap writes using page faults */
 static int shadow = 1; /* Optionally disable shadow framebuffer */
 
 /* dlfb keeps a list of urbs for efficient bulk transfers */
@@ -1961,7 +1961,7 @@ module_param(console, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
 MODULE_PARM_DESC(console, "Allow fbcon to consume first framebuffer found");
 
 module_param(fb_defio, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
-MODULE_PARM_DESC(fb_defio, "Enable fb_defio mmap support. *Experimental*");
+MODULE_PARM_DESC(fb_defio, "Page fault detection of mmap writes");
 
 module_param(shadow, bool, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
 MODULE_PARM_DESC(shadow, "Shadow vid mem. Disable to save mem but lose perf");
-- 
1.7.4.1


                 reply	other threads:[~2011-08-21 20:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1313958939-5681-5-git-send-email-bernie@plugable.com \
    --to=bernie@plugable.com \
    --cc=linux-fbdev@vger.kernel.org \
    /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).