Preparing more udlfb patches for linux-next

Posted on 12. Feb, 2010 by in UGA-2K-A

There are limits on how much a small device company can and should do in contributing to open source driver support. But with a historical connection to DisplayLink and more products coming with the technology included, contributing what we can to the generic DisplayLink driver on Linux makes some sense.

Also note this driver is just a foundation on which other stuff (like X) sits, so it doesn’t mean Linux is easy for real end users yet. But it’s getting closer.

Here’s the announce that went to the list today:

The next patch series for udlfb is “nearly ready” for submission, hopefully will be coming in the next few days.

Testing and any problem reports would be helpful. The code that will be submitted is at http://git.plugable.com/gitphp/index.php?p=udlfb&a=summary

There are many dozens of checkins in git as inter-related problems have been explored and the code incrementally improved. Before submitting, I’ll be reconstituting them into a smaller number of more analyzable email patches: make everything checkpatch.pl clean, reorganize things to match final layout, then per-feature patches. We’ll see how that goes.

Major features:

* Support for standard fbdev clients (via defio)
* Improved performance (about 20% average improvement over a variety of “benchmarks” like x11perf, gtkperf, glxgears)
* Asynchronous urb dispatch and no mutexes held for extended periods during render
* Slightly lower CPU consumption, less touching memory, slightly higher average compression
* Better handling of switching from X to fbcon VTs and back
* Driver should unload cleanly from either bottom-up (USB removal) or top-down (shutdown). Problem reports welcome.
* Performance metrics reported through sysfs (read /sys/class/graphics/fbX/*metrics*)
* EDID reported through sysfs (read /sys/class/graphics/graphics/fbX/edid)
* Can compile as module with or without defio or sys_ dependencies
* Lots of cleanup – tested on 64-bit, closer to endian clean, checkpatch.pl clean

What it does not have:

* The defio rendering problems (e.g. with xf86-video-fbdev X server) are still unsolved
* Still 16bpp only. Pseudo-truecolor 32->16 is on the wishlist.
* No DL 1×5 SKU detection yet (you’ll get a blank screen if your monitor’s res exceeds the adapter)

DisplayLink Linux Rotation

Posted on 02. Jan, 2010 by in UGA-2K-A

[updated 8/14/2011 with latest udlfb info]

The xorg generic fbdev driver (xf86-video-fbdev) supports rotation with a custom option (note it disables DGA and xrandr when it rotated mode). DisplayLink devices can use this driver two ways:

  • With the udlfb fb_defio option enabled to detect framebuffer writes based on page faults
  • With the fbdev xorg server patched to report damage (writes to the framebuffer). Instructions for compiling and adding the ReportDamage option to xorg.conf are at the end of this post.

To enable rotation, in the xorg.conf “Device” section, add a Rotate option, setting it to CW, CCW, or UD.

Section "Device"
  Identifier "dl"
  Driver "fbdev"
  Option "rotate" "CCW"
  Option "ReportDamage" "true"
  Option "fbdev" "/dev/fb1"
EndSection

One downside is rendering is significantly slower, as the extra work of rotation is done at the X level and the page-fault behavior of defio means even small updates refresh much of the screen. Here’s some numbers that can be compared to earlier posts (in non-rotate mode):

bernie@bernie-aspireone:~/git/misc-udlfb$ ./udlfb-perf.sh fb0 gtkperf -a
Xlib:  extension "RANDR" missing on display ":3.0".
GtkPerf 0.40 - Starting testing: Fri Jan  1 09:47:20 2010
 
GtkEntry - time:  0.00
GtkComboBox - time:  3.73
GtkComboBoxEntry - time:  2.08
GtkSpinButton - time:  0.49
GtkProgressBar - time:  0.69
GtkToggleButton - time:  0.47
GtkCheckButton - time:  0.44
GtkRadioButton - time:  0.79
GtkTextView - Add text - time:  2.30
GtkTextView - Scroll - time:  1.24
GtkDrawingArea - Lines - time:  4.14
GtkDrawingArea - Circles - time:  4.56
GtkDrawingArea - Text - time:  4.11
GtkDrawingArea - Pixbufs - time:  0.90
 ---
Total time: 25.96
 
Quitting..
 
model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
cpu MHz         : 800.000
cpu MHz         : 800.000
MemTotal:        2052144 kB
Framebuffer Mode: 1920,1080
 
Rendered bytes:  1238913024 (total pixels * Bpp)
Identical bytes: 1070725304 (skipped via shadow buffer check)
sent bytes:      125732225 (compressed usb data, including overhead)
K CPU cycles:    7478653 (transpired, may include context switches)
 
% pixels found to be unchanged: 86.00 %
Compression of changed pixels : 25.00 %
Total CPU cycles spent per input pixel: 6
Total CPU cycles spent per output pixel: 59
USB Mbps: 35.52 (theoretical USB 2.0 peak 480)

udlfb 0.4.0

Posted on 11. Nov, 2009 by in USB-VGA-165

[Update Dec 29, 2011: udlfb was promoted from the staging to the mainline kernel tree in 2.6.38. And in kernel 3.3 pagefault detection and console are enabled by default. See all our udlfb posts for the latest news.]

[Update March 14, 2010: udlfb versions have moved to being released with the Linux kernel. Update on udlfb support in Linux kernel 2.6.34]

[Update Feb 6, 2010: additional features and fixes post-0.4 are available at the plugable git page. Background is in later posts. One major udlfb patch with these changes has made it into linux-next (slated for 2.6.34), and additional patches will be coming as they're ready.]

This is a new release of the DisplayLink kernel framebuffer driver, udlfb.

udlfb was accepted into the Linux kernel staging tree of 2.6 a few months ago. It needs some work to add key features and get it moving from the staging tree, into mainline. Roberto De Iorio, the author of udlfb and displaylink-mod, is focusing on X server work, and is happy with this work happening in parallel to move udlfb forward.

This first release intentionally adds no fundamentally new features. It only gets udlfb up to sync with the displaylink-mod branch (up to Roberto’s last 0.3 release in July 2009) that has been in use the past few months. With this update, displaylink-mod users should be able to switch to this version of udlfb transparently.

Bug reports are very welcome, especially regressions or problems that would stand in the way of moving this driver forward out of staging (comments here are fine for bug reports).

New in 0.4.0 (since 0.2.3 currently in the Linux kernel staging tree)

  • Add dynamic modeset support (from displaylink-mod 0.3 and libdlo)
    • udlfb uses EDID to find the monitor’s preferred mode
    • udlfb no longer has fixed mode tables – it’s able to set any mode (within the capabilities of the chip) dynamically, from the standard VESA timing characteristics of the mode
  • Fix teardown synchronization issues (from displaylink-mod 0.3)
  • Other minor changes related to probe/modeset (from displaylink-mod 0.3)
  • Functionally identical to displaylink-mod 0.3
  • Retains basic layout of udlfb to make diffs more transparent and understandable

Download

See the git project summary page at http://git.plugable.com/gitphp/index.php?p=udlfb&a=summary for information.

Switching from displaylink-mod to udlfb.

Both these drivers match against all displaylink devices. So you don’t want both loading on your system. To clear out displaylink-mod:

sudo rmmod displaylink
sudo rm /lib/modules/`uname -r`/extra/displaylink.ko
sudo depmod -a

Then download, compile, install udlfb 0.4

./configure
make
sudo make install
sudo depmod -a

Todo

  • Merge in enhancements from Jaya Kumar’s displaylinkfb branch (defio support)
  • Merge in enhancements from Bernie’s displaylink-mod branch (performance)
  • Clear up remaining endian issues, to make sure it works on ARM and others
  • Add performance metrics, and sysfs attributes to read/reset them
  • Make allocation/use of backbuffer a runtime option, with param and sysfs switch
  • Figure out what KMS (Kernel Mode Setting) means to framebuffer drivers
  • Move from single URB with synchronous dispatch to ring of USB URBs, with asynchronous dispatch
  • Enhance probe() to better handle chip type detection
  • Enahance mode selection to better handle limits of DisplayLink chip
  • Add simulated hardware cursor support, to prioritize mouse movement

Any feedback or ideas on these todos are very welcome. And, as always, patches are very welcome and will be incorporated as quickly as possible.

Page 11 of 11« First...7891011