You can see how your 32 evdev slots are currently getting used on a system with the command

for i in {0..31..1}; do udevadm info -a -n /dev/input/event$i | grep name; done

On the Fedora 17 multiseat box I’m using now to write this post, I have 3 USB terminals sharing one box — while I’ve spent the afternoon figuring this stuff out on one of the USB terminals, at the same time the kids have been watching endless youtube videos with their headsets on the other two. On this box, the command above shows:

    ATTRS{name}=="Power Button"
    ATTRS{name}=="Power Button"
    ATTRS{name}=="Plantronics Plantronics .Audio 655 DSP"
    ATTRS{name}=="Dell Dell USB Keyboard"
    ATTRS{name}=="USB Optical Mouse"
    ATTRS{name}=="USB Optical Mouse"
    ATTRS{name}=="Dell Dell USB Keyboard"
    ATTRS{name}=="GASIA USB KB V11"
    ATTRS{name}=="GASIA USB KB V11"
    ATTRS{name}=="SIGMACHIP Usb Mouse"
    ATTRS{name}=="C-Media Electronics Inc. USB Multimedia Audio Device"
    ATTRS{name}=="CM109 USB driver"
    ATTRS{name}=="HDA Intel PCH HDMI/DP,pcm=3"
    ATTRS{name}=="HDA Intel PCH Line"
    ATTRS{name}=="HDA Intel PCH Rear Mic"
    ATTRS{name}=="HDA Intel PCH Front Mic"
    ATTRS{name}=="HDA Intel PCH Front Headphone"
    ATTRS{name}=="HDA Intel PCH Line Out"
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found

This shows I only have 14 evdev slots left (the “device node not found” ones are available slots). So I know I could only connect 7 terminals total to this machine (a USB terminal’s unused audio buttons + keyboard + mouse takes up 3, I could only get 14 / 3 = 4 more than the three I have).

We can lift the limit of USB terminals from 7 to 16 by disabling often unused input devices: hardware volume controls and system (power) buttons. The following udev rules script does that with 3 rules.

Note that this will mean you’ll have to power off / sleep from the UI, your mainboard audio will be disabled, and special keyboard multimedia keys will be disabled. Feel free to comment out the appropriate lines in the udev rules if you want to keep those.

To apply these optimizations, create a system file (as sudo) called /usr/lib/udev/rules.d/72-seat.rules
with the following contents and reboot.

#
# Bernie Thompson bernie@plugable.com
#
# These udev rules help alleviate the Linux kernel limit of 32 evdev devices.
# This file should be deleted once the kernel's 32 device limit is lifted.
#
# Background: Every input device on the system, including several for 
# power buttons, PCI audio, USB audio, keyboard multimedia keys, etc. 
# all count towards the 32 limit.  Many systems reserve at least 8 for
# these uses. So as shipped with Fedora 17, only 7 or so USB terminals 
# (like the Plugable DC-125 or Plugable UD-160-M) will work.
#
# Run this at a command line to see how your 32 event slots are being used:
#
# for i in {0..31..1}; do udevadm info -a -n /dev/input/event$i | grep name; done
#
# If you have any event slots free, you'll see a "device node not found" message for each
#
# USB terminals consume an extra event device with the USB HID device
# associated with the audio interface for volume control. The udev rule below
# frees it up. This will enable around 12 USB terminals per server.
#
SUBSYSTEMS=="usb", SUBSYSTEM=="input", ENV{ID_SEAT}!="seat0", ENV{ID_USB_INTERFACE_NUM}!="00", RUN="/bin/sh -c 'echo $id > /sys/$devpath/../../../driver/unbind'"

#
# Free up any input devices associated with audio on the PCI bus.
# *IMPORTANT* This will disable your PC's mainboard PCI audio
# (because we can only unbind the whole PCI device)
# This will enable 13 or so USB terminals per server
# Comment out the line with a "#" if you'd like PCI audio to work
#
SUBSYSTEM=="pci", ATTR{class}=="0x040300", RUN="/bin/sh -c 'echo $kernel > /sys/$devpath/driver/unbind'"

# 
# Free up any ACPI (system power) buttons. 
# *IMPORTANT* This will disable all built-in buttons on your PC (e.g. power)
# You will need to shut down, etc. from the Linux UI with administrative rights.
# This has the side-effect of making your PC slightly more secure against student tampering.
# Comment out the line with a "#" if you'd like these to work
# This will enable an extra USB terminal or so per server
# If you have no other event devices, other than the USB terminals, should get to 16 terminals.
#
SUBSYSTEM=="acpi", DRIVER=="button", RUN="/bin/sh -c 'echo $kernel > /sys/$devpath/driver/unbind'"

After creating that udev rule and rebooting, things look much more favorable in terms of evdev slots. Only the “real” USB keyboards and mice are left to consume slots:

    ATTRS{name}=="SIGMACHIP Usb Mouse"
device node not found
device node not found
    ATTRS{name}=="Dell Dell USB Keyboard"
    ATTRS{name}=="USB Optical Mouse"
    ATTRS{name}=="USB Optical Mouse"
    ATTRS{name}=="Dell Dell USB Keyboard"
    ATTRS{name}=="GASIA USB KB V11"
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found
device node not found

There are now enough free slots for 16 USB terminals (or, more specifically, their keyboards and mice).

Hopefully this is just a temporary workaround, until someone tackles the task of lifting the kernel’s limit of 32 evdev devices. That’s a very constraining limit for a whole host of reasons.

Note that one of the remaining bugs in Fedora 17 is that random USB terminals often come up to a green screen, requiring an unplug/replug to get a login. These scripts may increase the frequency of that if you have a lot of terminals, as the system bounces against the 32 device limit, then returns below it as the udev rules execute.

Hopefully in future versions of Fedora / systemd, those race conditions will be closed.

Hope you enjoy turning your one Fedora 17 PC into many. Please comment if you have any problems applying, we’ll try to help. See also our post on some huge Fedora 17 performance optimizations for USB multiseat which greatly improve the default experience.

And if you’re running more than 8 terminals with Fedora 17, please post a comment – we’d love to hear about it!

Plugable UD-160-M USB 2.0 Thin Client Full HD

Select Market

Individual GNOME 3 users can fix this by setting their desktop experience to GNOME 3 “fallback mode” which can avoid the 3D compute burden. Fallback mode is an essential setting for older PCs, VMs, USB graphics, remote desktop, etc. It also provides the (arguably) more familiar GNOME 2 like experience (Applications / Places menus, desktop icons, etc.)

It’s possible to configure fallback mode for all users, plus the login screens, centrally by changing some dconf settings. Here’s how:

First, if you don’t already have a “user” profile, then we create one — specifying a new settings database we’ll call “fallback”. Create a file /etc/dconf/profile/user (as su / sudo) which contains these two lines:

user
fallback

Then we’ll create the settings directories for that new database

sudo mkdir /etc/dconf/db/fallback.d
sudo mkdir /etc/dconf/db/fallback.d/locks

Create a settings file to also use fallback once users are logged in. Create a file called /etc/dconf/db/fallback.d/60-user-fallback with:

[org/gnome/desktop/session]
session-name='gnome-fallback'

[org/gnome/desktop/background]
show-desktop-icons = true

# This one is useful more for automatic USB multiseat
[org/gnome/desktop/lockdown]
disable-user-switching = true

And, finally, create a settings file to have login screens themselves use fallback mode. Create a file /etc/dconf/db/gdm.d/60-login-fallback with:

[org/gnome/desktop/session]
session-name='gdm-fallback'

dconf is a binary settings database (very un-unix like), so for any of these changes to take effect, you must run

sudo dconf update

Which will update the binary blobs which are then queried by GNOME to apply these settings. See the dconf admin guide for more.

And that should do it. You should see the fallback look and feel (more like GNOME 2). And if you’re running in a VM, with USB multiseat, or anywhere you don’t access to a beefy 3D processor — you should see a big drop in CPU usage.

Again, these directions have only been tested on Fedora 17. Please feel free to comment on changes (if any) to apply them for other distros.

Plugable UD-160-M USB 2.0 Thin Client Full HD

Select Market

Since this is all open source, we expect the porting process will happen in time.

For now, the best bet is the distro under which support was first developed — Fedora 17 and later. On Fedora, any supported USB terminal (like those on the right), will automatically pop up a fresh login when plugged in, no software install or licenses needed.

Plugable DC-125 USB 2.0 Thin Client

Select Market

Both the new “udl”, and older “udlfb” framebuffer driver that we maintain are present in 3.4.0. Unfortunately, the new udl DRM driver is still maturing, and can cause kernel panics. With USB graphics devices present, you can determine which driver (“udlfb” or “udl”) is getting loaded with lsmod:

lsmod | grep "udl"

This change has a particular impact with Fedora 17 — the first open source distro to have automatic USB multiseat support — which shipped with Linux kernel 3.3.

Post-ship, Fedora 17 now offers a software update to kernel 3.4.0, which unfortunately causes problems: udl may be loaded for DisplayLink-based devices, and kernel panics are common and terminals often won’t come up. To the user, it appears to break multiseat.

So to fix the issues you’ll see with 3.4.0, we recommend disabling udl for the time being. The stable udlfb driver is still present in the kernel, and will get matched against your hardware automatically once udl is no longer loaded. The easiest way to do this is to run the following commands and reboot:

echo "blacklist udl" | sudo tee --append /etc/modprobe.d/udlfb.conf
sudo depmod -a
sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

One the server reboots, udlfb should match all USB graphics devices and be fully stable. Please let us know if you have any trouble. And in coming Linux kernel versions, udl will continue to improve and at some point udlfb will be able to be retired in favor of it.

Plugable DC-125 USB 2.0 Thin Client

Select Market

Background

Fedora 17 continues to default to GNOME 3, which assumes the presence of powerful 3D hardware.

If that’s not the case (e.g. in a VM, or with Fedora 17’s new automatic USB multiseat functionality), then Fedora 17 defaults to llvmpipe based software 3D, which is software to make full use of your CPU to do all the work there.

That’s great on a fast CPU with multiple cores (Core i3 class and up), but it brings lesser processors to their knees. Users can unnecessarily perceive Linux as slow and unusable. On a USB multiseat system, where you don’t have a 3D GPU and so are using llvmpipe, the load can be unacceptable even for a single user on a Core 2 class system. But by going to GNOME 3 “fall back mode” (which depends less on 3D composting for eye candy), having 5-6 users even on a dual core Atom system is no problem. It’s a dramatic performance difference.

You can tell if Fedora 17 is running llvmpipe by opening “System Settings”, and then “Details”

Then click on the “Graphics” tab. If it shows a driver of Gallium on llvmpipe, and “Standard” experience, then you’re in this mode where you’ll see high CPU usage at all times (even when no graphics appear to be changing!) because of GNOME 3’s 3D effects.

How to boost performance

But by hitting the “Forced Fallback Mode” switch to on, you can drop the GNOME 3 UI, enormously reduce your CPU load, and get a user experience that’s closer to what people are used to (more GNOME 2 like — has a task bar, potential for desktop icons, etc.). Maybe they should have renamed the setting …

On a Fedora 17 system with a bunch of USB thin clients attached, you can gain a ton of performance by making this change. But you’ll likely want to make this change in dconf configuration (so it also applies to the login screens). For that, read the follow-up post on configuring all users for GNOME 3 fallback.

Plugable DC-125 USB 2.0 Thin Client

Select Market

What is possible, however, is running a single DisplayLink adapter, or several with a Xinerama or multiseat configuration — just as long as you don’t expect to use your main GPU at the same time.

The single-display case is relatively easy to set up, and we’ll cover that here.

First, make sure you’re running kernel version 2.6.35 or later (Ubuntu 10.10 or later). For older kernel versions, you’ll need to update udlfb and run a modified fbdev X server (not covered in this post). On these kernel versions, when you plug in your DisplayLink-based USB graphics device, you should get a green screen. This means that at the driver built into the Linux kernel is happy, healthy, and talking to the device.

Second, if you are running Unity Desktop in Ubuntu 11.04 or later, you’ll need to switch back to Classic Mode so you’re running straight X. Here’s how on Ubuntu:

Click on the power button in the upper right corner (mine looks like a light switch) and choose the last option, System Settings. Search for Login Screen, Double-click to display, Choose Unlock and enter your password, Select Ubuntu Classic as default session.

Third, if you’re running kernel versions between 2.6.35 to 3.1, enable the fb_defio option of udlfb. To do this, create or edit a file like
/etc/modprobe.d/50-displaylink.conf

and add the single line

options udlfb fb_defio=1

And reboot (or run “sudo depmod -a” and unplug/replug your adapter). This will turn on defio (page fault change detection) support. This option is already enabled by default in kernels 3.2+.

Lastly, create an X config file called 60-plugable.conf (or similar) with the following contents and place it in /usr/share/X11/xorg.conf.d (on recent distros; on older distros, make this your xorg.conf):

Section "Device" 
  Identifier "uga" 
  driver "fbdev" 
  Option "fbdev" "/dev/fb0" 
  Option "ShadowFB" "off"
EndSection 

Section "Monitor" 
  Identifier "monitor" 
EndSection 

Section "Screen" 
  Identifier "screen" 
  Device "uga" 
  Monitor "monitor" 
EndSection 

Section "ServerLayout" 
  Identifier "default" 
  Screen 0 "screen" 0 0 
EndSection

Note: if your main GPU creates a /dev/fb0 even when the USB display is not attached, then your USB display is probably getting assigned to /dev/fb1. In that case, change /dev/fb0 in the “Device” section above to /dev/fb1

Now, on reboot, you should (hopefully!) see your login come up on your DisplayLink USB attached display!

This kind of simple setup is useful for:

• Testing or playing with your USB graphics adatper on Linux.
• Embedded systems with USB but no GPU.
• As a backup method when the main GPU or its driver isn’t available or working.
• Systems where a USB graphics adapter enables higher modes (up to 2048×1152) than the main GPU screen.

Please comment if you have any trouble with this single display case. See our past posts for additional information about the DisplayLink Linux kernel driver and some more involved setups.

The instructed here work on all Plugable USB 2.0 graphics adapters and Plugable USB 2.0 docking stations and thin clients (and should also generally work on all DisplayLink based products).

So we’re excited to launch a hub with a lots of expandability (10 ports), but with a simple and clean design.

• Full USB 2.0/1.1 performance and compatibility. No compromises. Works on all platforms with no drivers (i.e. it’s a standard USB 2.0 hub)
• Cascaded Terminus Technology chipsets – the best designed, lowest power, most reliable USB 2.0 hub controller out there right now
• The 10 ports (plus upstream port to PC and AC power) are all on just two sides of the hub, minimizing cable clutter
• Two of the ports swivel to a vertical position – so if you want a flash drive or antenna to stick up, that works. If you want everything to lay flat so you can stack on the hub, no problem
• A blue LED bar down the center of the device signals power. 2.5A AC adapter included

The customer feedback from this hub design has been surprising us – you wouldn’t think in 2010 that a USB 2.0 hub could get people excited. But buyers have written with disproportionately positive feedback like “Easy to use and a really helpful device” and “Exactly what I was looking for”.

With many laptops only having 2 or 3 USB ports, the easy expandability of a hub like this is a nice win.

Check out more pics and details on the Amazon product page

Support for these devices has been in the Linux kernel since kernel 2.6.21 (file /drivers/net/usb/asix.c). However, prior to version 3.2, this driver fails to find an IP address, and comes up “disconnected”

To get the adapter working, we need to download, compile, and install the latest driver available from ASIX for the AX88X family. This driver is compatible with kernels 2.6.14+

Steps

Assumes you have another net connection on this machine. Download the driver on another machine and copy over if not.

mkdir asix
cd asix
wget http://www.asix.com.tw/FrootAttach/driver/AX88772B_772A_760_772_178_LINUX2.6.35_Driver_v3.5.0_Source.tar.bz2
tar xvjf *
sudo apt-get install module-assistant
sudo module-assistant prepare
sudo modprobe -r asix
make
sudo make install
sudo modprobe asix

Your USB network interface should now come up automatically.

These instructions have been written for our Plugable USB2-E1000 USB Gigabit Ethernet adapter, but should apply to any ASIX adapter with an ASIX AX88178 USB Ethernet controller and Realtek RTL8211CL PHY, which reports ASIX’s USB IDs VID_0B95 & PID_1780.

The steps should work identically on older Ubuntu kernel versions. It was also tested on Ubuntu 9.04, kernel 2.6.28.10. Comment here if you have any trouble, and we’ll try to figure it out.

Common errors

Before this update of the driver, the common errors you’ll see typically show up as a timeout trying to get an IP address from DHCP. You’ll see messages like

“no ipv6 routers present” in dmesg and /var/log/kern.log

And in /var/log/syslog:
“DHCP transaction took too long (>45s), stopping it”
“Marking connection ‘Auto eth1’ invalid”

Again, this update of the ‘asix’ kernel module should resolve these errors. For the future, hopefully the in-kernel ASIX driver will get patches to catch it up with the driver source available directly from ASIX.

We know how much work open source driver development is — getting hardware should be the easiest part of it. So today we’re announcing a new program to better get test devices out to developers who can use them.

If you’re a developer with a history submitting patches for Linux or other platforms, please submit your request for Plugable sample hardware here. Because we’ll have only a trickle of each type over device over time, an important part of this is having some idea of what prior driver development contributions you’ve made. We’ll try to focus on matching hardware to the developers most likely to be able to contribute improvements in that area.

Plugable’s products cover a fairly wide range of USB and other devices. See https://plugable.com/shop/ for our products that will be available from time to time under this program.

We’ve long been doing this kind of thing with the commercial vendors. Having worked on Windows and at Microsoft, we try to drop off samples to get them using, testing, and developing against our hardware. We’d do the same for Apple or others. This is our attempt to get these same benefits going with the wider open source community.

We hope this will seed some good things over time. And we welcome any feedback or suggestions on this program anytime.

Linux is a big and constantly shifting platform. With our USB graphics products (and generally for DisplayLink based products, since we try to make them work for all devices), it’s easy to output a few pixels, but configuring a USB display as an X terminal, or certainly for an extended desktop, is still a process on Linux that requires manual xorg.conf editing and is for very advanced users only. But we try to contribute what we can at Plugable, and that has meant focusing on making the kernel driver that actually talks to the hardware and everything else builds on, as solid as possible.

The contributed patches start with this post to the linux driver project list.

————–
To: devel-request@linuxdriverproject.org
[PATCH 0/11] staging: udlfb: patches from udlfb development branch (Bernie Thompson)

This patch series contains all current fixes and features from
the udlfb development branch.

udlfb is a framebuffer driver for DisplayLink USB 2.0 era chips.

Diffstat of this 11 part patch series:

udlfb.c | 989 +++++++++++++++++++++++++++++++++++++++++———————–
udlfb.h | 41 +-
2 files changed, 664 insertions(+), 366 deletions(-)

Major changes:

* Added summary documentation for users of udlfb
* Added logic to query DisplayLink chip for max area mode,
so low-end chips on high-end monitors no longer get black screen
* Added support for DPMS. X servers now control monitor
power with existing standard interface
* Added back in support for char interface (e.g. cat file > /dev/fb0)
* Systems without EDID or with failing EDID can now supply fixed
EDID to sysfs interface, also avoiding black screen
* Fixed big-endian (PowerPC) rendering
* Fixed teardown race conditions that could result in shutdown hang
* Added fb_defio and fb console module options (default off)
* Fixed udlfb’s fb_defio client code so no longer incorrectly shares
state across udlfb device instances – fixes hangs and errant rendering
* Removed IFDEFs for building against older kernels – those will
be retained in the udlfb development branches at git.plugable.com

Todo:

There have been no additional reported bugs in the last few months,
although there are several wishlist features. Udlfb may be ready
to move out of staging at this point.

Patches are against Linus’ latest 2.6 tree.

Plugable UD-160-A driving 1920x1080 display and more, all from a humble Nexus One phone

This setup uses the udlfb DisplayLink Linux driver work from here (git.plugable.com) and a bunch of other components Sven has developed or pulled together, to turn the phone into a full computer with display, keyboard, audio and more. His video of this has gone viral (over 85,000 views). You can see the video and full instructions at Sven’s site. Very cool.

The photo above is of the Plugable UD-160-A Universal Docking Station, in use at Sven’s desk (the dock is laying on its side to better fit in the photo – Sven has removed the weighted bottom stand).

The Plugable dock is perfect for this kind of application with the Nexus One phone — it includes all the USB devices in one place, all with open source drivers. The dock has its own 2.5A AC power (see the USB dual-power Y cable plugged into the front USB A and back USB B ports), along with driving the 1920×1080 monitor (the big DVI cable in the back), and providing ethernet (above the DVI) and audio (in the front – he doesn’t have them plugged in in the pic).

So this all is great for geeks, but when will this work out of the box? Several comments on Sven’s work are messages like “Google! Integrate this into Android now!”

With Google offices near here, and with related USB terminal work on the same Plugable dock being funded as a Google Summer of Code project, it would be great to demo this and get things moving… Whatcha say, Google!?

Last year, he demoed turning your router into a full-fledged computer.

This year, it’s the Google Nexus One phone as a full computer — with attached external keyboard, mouse, display, and more.

The Nexus One demo is using the udlfb Linux kernel module to talk with the DisplayLink device, and it will work with any DisplayLink device, including Plugable’s.

Note the version of udlfb in the 2.6.34 staging tree unfortunately didn’t work for Sven. So he’s now using the latest udlfb from http://git.plugable.com/, which will likely get merged in for kernel 2.6.36.

Also, he used a dual headed cable to get enough power. A powered hub or a docking station/terminal like the UD-160-A won’t need that — it supplies its own power from AC – all the hardware needed is in the one package.

It’s exciting to have all this open source work come together in interesting demos like this.

There was a question recently why udlfb doesn’t use the same compression technique as the Windows drivers. Among other reasons, one is that the RL compression used by udlfb scales down to devices like the ones Sven has been working on — it’s as light as possible on CPU load, while getting decent compression.

Stepping back, it’s clear Apple (and now Microsoft) are making a mistake by limiting the hardware ecosystem around their devices. Android and the other Linux variants have an opportunity here — and considering the Apple juggernaut, they definitely need every advantage.

Sven’s demos show how powerful these scenarios can be. The hardware is ready. Devices like Plugable’s are designed with these scenarios in mind. Now we need to get the software refined and included in standard distributions, so normal consumers can take advantage of all the possibilities and benefits here.

The goal of their project was to get an embedded platform working on Centos 5.3. You can read more in their release note for the work.

To make the contributions easier to diff, they’ve been checked into a git branch from a (best guess) of the code Endurance started from.

The changes are available here for the kernel driver and here for the X server.

To actually build it, you may need their full package.

It’s unclear what of these changes might get picked up, as things have moved on since. One of the main features of this code is providing a default EDID blob in udlfb. The plan for udlfb at this point is to allow the edid sysfs interface of udlfb to be written to, to allow (and give responsibility) to a user-mode entity to supply a default edid, if one isn’t available from hardware.

Thanks again to Endurance for being diligent about contributing changes back.

We’re very excited about the Google funded project to refine USB multiseat on Linux, with the winning proposal from Lucas Nascimento Ferreira at the Federal University of Parana in Brazil.

In addition to providing mentoring, Plugable is also providing donated hardware for this project. Two Plugable Universal Docking stations with recent enhancements for use as a terminal, were just picked up by Lucas in Brazil today. By next month, we expect to have updated versions of the DC-125 for terminal use to send down.

For those interested in learning more and potentially following Lucas’ work:

• Google’s SoC 2010 Timeline
• Lucas’ winning USB Multiseat Proposal

And we’ll post periodic status updates here.

We do this because we know you use a mix of machines, or may be thinking about switching one way or another. And when you invest in a collection of USB devices, you want them to be useful beyond your current computer. That’s what we expect, too.

All this activity can get a little noisy, though. A little too much information.

That’ll be especially true for some exciting but technically involved work that’s happening over the next few months on Linux with the Google Summer of Code project for USB multiseat, which makes use of some of our Plugable hardware.

So if you’re interested in just one platform or another, here is a way to get just the news that you care about, and get rid of the rest of the noise:

•  Subscribe – Windows News From Plugable
•  Subscribe – Mac News From Plugable
•  Subscribe – Linux News From Plugable

And for those wanting an even more customized view — just append /feed to the tail end of any category view on the site, to get an even more specific feed, if you’re interested.

Linux hasn’t had that support — it would try to set the highest mode the monitor is capable of, often resulting in a black screen. Especially common for the DL-125 chip, with its mode limits of 1440×900/1280×1024.

That’s a shame because the DL-125 chip is a smart choice in many cases – by limiting itself to those lower modes, it stays more consistently within the limits of the USB 2.0 bus, resulting in more consistent performance.

So coinciding with the launch of Plugable’s DisplayLink DL-125 based products (UGA-125, changes have been implemented to bring Linux roughly up to the level of Windows and Mac in this area for DisplayLink devices. This also helps devices like the UD-160-A when running on monitors greater than its limit of 1920×1080.

The kernel framebuffer driver udlfb has been enhanced to read the resolution limit from the firmware descriptors of the device, and adhere to it.

On the X server side, we needed a driver which would limit itself to the resulting reduced mode list. Unfortunately, the existing displaylink X server reads EDID directly, and assumes the adapter can do whatever the monitor can do.

We’ve been wanting to get rid of the need for a displaylink-specific X server, and the standard xf86-video-fbdev driver runs with the best existing mode, rather than trying to set a higher one in EDID. So this was a good trigger for converting over.

So xf86-video-fbdev has been enhanced with X Damage protocol support, ported from Roberto’s displaylink driver. This is still a little in-flux from an interface perspective, but from a functional perspective it’s done and fully performant.

So it’s now possible to run with a modified generic fbdev driver, which talks to udlfb, with full performance and without needing defio (although there’s also some good news in the defio space, which will be posted about later).

You can grab the latest udlfb kernel module with a “git clone http://git.plugable.com/webdav/udlfb”. Compile with “make && sudo make install && sudo depmod -a”

And you can grab the latest modified xf86-video-fbdev with a “git clone http://git.plugable.com/webdav/xf86-video-fbdev”. Compile with “./autogen.sh && make && sudo make install”

You’ll need a very recent xorg-macros version (1.4), which in package “sudo apt-get install xutils-dev”

To use the new X server, you must turn on the new “ReportDamage” option to fbdev. Modify your existing xorg conf like this:

Section "Device"
  Identifier "dl"
  Driver "fbdev"
  Option "ReportDamage" "true"
  Option "fbdev" "/dev/fb0"
EndSection

And you should be all set to go. This new X server should work with the existing udlfb in the staging tree of kernel 2.6.31+ for now, as it’s re-using the same original ioctl. But may require modeset changes that are only in 2.6.34+.

The main focus is USB multiseat, and the details are on the xorg wiki for SoC 2010

With all the pieces that are just coming together now, there is a potential here to do a project with huge impact, without a massive amount of engineering. There is already a very solid proposal coming from a student in Brazil who has previously been involved with the MDM multiseat project.

Google’s deadline for applications is now just a few days away: April 9th.

If there’s interest from other parties, we’ll get everyone talking – or there are other related proposals that we might be able to get in at the last minute. Foremost among those is conversion of the DisplayLink USB driver udlfb and matching X server from a fbdev driver to the KMS model.

Here’s the basics of the USB multiseat opportunity:

USB Multiseat Refinement

Linux Multiseat setups have potential to significantly reduce the cost of computing, but can be hard to configure. Some progress has been made on USB multiseat, where all components of the “terminal’ (display, keyboard, mouse, and more) are on USB, so configuration can be fully plug and play – you can just assume that all devices on the same USB hub constitute a terminal.

Some early prototypes of this are working (see https://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/). The underlying kernel drivers and X servers are largely in place.

But recent changes to the X Server, ConsoleKit, and other components open the possibility for a cleaner implementation.

This SoC project would constitute the refinement/creation of configuration scripts to enable a standard Linux or *nix computer to automatically launch additional seats when a USB terminal is plugged in

* udev rules to detect hubs/devices which should be collectively treated as terminals
* udev attributes to label the set of devices with a common seat id
* udev triggers for on-demand generation of the appropriate Xorg config files, to allow seats to coexist with the primary display/devices.
* ConsoleKit scripts to launch independent GDM/X sessions for each USB terminal seat
* InputClass rules to cause the primary X session to ignore multiseat-assigned devices, and the appropriate seat to use them
* udev rules and X init scripts to grant access to audio, storage, and other devices to the person logged into the matching seat

The one-sentence goal of this project: To make USB multiseat fully plug and play for the end-user, and ready for any distro to safely and cleanly drop in at any time.

Know any aspiring software engineering students that might be interested? Check SoC info from Google and the SoC guidelines from xorg.

There will still be some bugs and issues to resolve — but this release has most of the features, specifically related to input handling and udev-based dynamic configuration, of a more solid USB multiseat solution.

In short:

• udev rules, which already can detect a grouping of USB devices that constitute a terminal, can now tell X to ignore or use particular devices more easily through udev attributes and more dynamic/independent xorg.conf.d scripts.
• udev is now the default configuration mechanism (the torch has been passed from the less flexible hal)

So the challenges to explore are now more in the area of ConsoleKit integration and whether we can use these new capabilities support not just pure-USB multiseat setups, but also a mix of seats with PCIe attached graphics, and with fully USB seats.

You can read more about the new 1.8 configuration features which multiseat will use at Peter Hutterer’s blog.

And read more about the RC itself at Phoronix

We use NTFS-3G on Mac OS 10.4 here, in combination with the Plugable USB 2.0 SATA All-in-one Storage Dock and large TB+ SATA drives. Along with built-in NTFS support on Windows XP and up, and all recent Linux distros, this lets us easily swap a single USB cable between Windows, Mac, and Linux and have all three be able to read and write the drive(s).

Overall, this is a good solution for developers who have to span multiple platforms, for people who use boot camp to switch between Mac and Windows, or for increasingly common multi-platform offices that are using external storage docks for backup.

And it’s nice having a both an open source and a (better performing) commercially supported option.

It used to be that the venerable FAT32 filesystem was best way to format a drive to make sure you could easily read and write it from Windows, Mac, and Linux. But FAT32 has some limits that are especially problematic for today’s large drives 1 TB and up:

• Hard limit of 4GB on any individual file (think home movies of 30 mins or more)
• FAT32 needs large cluster size for large disks – which means wasted disk space in the case of many small files
• Partition size limits that can get as small as 32GB, and certainly hit at 2TB

There are various ways to read and write filesystems native to one OS on another. But there are also lots of pitfalls. All things considered, NTFS is the best compromise today.

For more background:

• Windows FAT32 filesystem limits
• Windows NTFS filesystem limits
• Mac HFS+ filesystem limits
• Linux Ext filesystem limits

A 10-part udlfb patch series with several enhancements were recently accepted into the Linux kernel staging tree of 2.6.34. Greg’s maintainer patch series passing them on starts here.

This catches the official kernel staging tree with everything on git.plugable.com up to Feb, 2010.

Background

udlfb provides Linux framebuffer (fbdev) support plus a private “damage” notification ioctl used by the Roberto DeIoris’ “displaylink” X server. Udlfb automatically detects and supports all current DisplayLink USB graphics chips – 120,160,115,125,165,195. It supports 16bpp, with modes up to the maximum supported by the DisplayLink chips. Plugging any DisplayLink device into a Linux PC with this support should result in a “green screen” which means udlfb has loaded, set the monitor default mode, and drawn to the device successfully.

What udlfb does *not* do on its own is make configuring X easy – X sits on udlfb, but getting X running still involves editing configuration files like xorg.conf in different ways depending on what you’re trying to do, what distro version you have, and what primary GPU you have.

Features in Linux kernel 2.6.34 so far

• Improved performance (about 20% average improvement over a variety of “benchmarks” like x11perf, gtkperf, glxgears). Video playback, flash games, etc. are all improved
• Asynchronous urb dispatch and no mutexes held for extended periods during render
• Slightly lower CPU consumption, fewer non-localized memory accesses, slightly higher average compression
• Better handling of switching from X to fbcon VTs and back
• Driver unloads more cleanly from either bottom-up (USB removal) or top-down (shutdown). Problem reports welcome.
• More standard EDID parsing and mode handling, using fbdev’s built in mode libraries (but creates a new dependency on them being enabled in kernel)
• Performance metrics reported through sysfs (read /sys/class/graphics/fbX/*metrics* – but will move to debugfs)
• 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
• Support for standard fbdev clients (via defio) – unfortunately buggy yet (see todos)

Depending on timing, some additional todo items might make it, we’ll see.

Versioning

At one point, we wanted udlfb to have its own project cycles and release versioning to help clarify things here while udlfb evolved in the early days. Got pushback on doing this from the kernel maintainers. So versioning of udlfb is purely by kernel version – “this bug is in udlfb in kernel 2.6.34rc1” or whatever. There’ll also be a newer changes that haven’t been submitted to the kernel (e.g. at http://git.plugable.com/). And it’s probably best to just version that per commit/checkin. “This bug shows up in commit 234b4e22…”. This is nice in a way – just check the stuff in somewhere let the world know what you’re doing – the only “release process” you need to coordinate with is getting the patches into the kernel itself. Or feel free also to send patches here, we’ll try to help them through the process.

Todo

• Add code to read pixel resolution limits from the device’s USB descriptors, and adhere to them. Avoids blank screen when monitors caps exceeds that of the adapter
• Add pseudo-32bpp mode to help the case of using Xinerama to extend desktop across PCIe/USB adapters. Not planning true 24/32-bpp mode yet because of complexity and perf tradeoffs
• Disable defio by default, unfortunately, because of several bugs without obvious solutions
  • rendering problems with pages (lines) that no longer get updated – writes to those are no longer triggering deferred processing
  • When running 2 USB adapters, dirty pages for one instance seem to affect the other, and vice versa (udlfb has no common state, so appears to be in defio or mmu handling)
  • cases where we hit a kernel oops in the deferred io handler when it tries to touch the pages it’s been asked to handle.
• Move perf metrics from sysfs to debugfs and add ABI doc for what remains, per GregKH
• Fix two ignored return values that Greg’s build environment caught
• Get a safe method from DisplayLink to detect future chips that might not be compatible with current ones, and bail out of probe

There’s lot of other stuff that could be done – and any patches are very welcome. One big open question is whether fbdev has legs, or whether this effort should be converted over to KMS/DRM/DRI.

• Upgraded the DisplayLink DL-160 to the newer DL-165
  • Previous maximum resolution was 1680×1050, now 1920×1080
• Moved from two 4-port NEC USB hubs internally to a single FE 2.1 7 port USB hub
  • When using as a terminal, previously could daisy-chain 2 docks, now up to 4. All devices attached to the dock show on the same hub
• Upgraded ASIX AX88772 ethernet chip to newer AX88772A
  • Auto-MDX support (automatically detects straight or cross-over cabling)

We’ve also shrunk the paper package size for less waste, and a have smaller connector for the (otherwise same) AC adapter.

The size and look of the docking station itself hasn’t changed, and all the same adapters, cables, and other hardware are included.

To the laptop docking station user on Windows or Mac, the changes won’t be immediately obvious, as the same drivers support both versions of hardware.

On Linux, both old and new chips have the same in-kernel support. In the terminal case, the USB configuration is now simpler (all devices are off the same USB hub), and that means a change in the udev rules for devices plugged into usb ports (keyboard and mouse are one hub less deep). Look for a future post on that.

So, with the new version, here’s the Windows Update experience you’ll see — without using any driver disks first, just plugging into a fresh Windows 7 machine with its own network connection up, letting it find and download drivers automatically.

Win7 first connect experience. Mouse and composite keyboard also attached

If you need to distinguish the versions from the outside (e.g. so you can make sure to give a newer one to someone who wants 1920×1080 resolution), the model number on the bottom of the older units all start with 0920J1.

Enjoy the upgrades on the new UD-160-A docking stations, and as always make use of our public problem reporting and support at http://getsatisfaction.com/plugable any time.

Style wars (e.g. “tabs vs. spaces”) are a never-ending source of tension on projects, so I actually appreciate automation like checkpatch.pl to just lay down the law, and be done with it.

But .. having to sift through endless warnings when you run checkpatch.pl late in the development process is frustrating. And there’s no way most occasional kernel patchers will remember all the rules (especially if you strongly disagree with some of them — which I do). It’s much better if your editor can just warn you when you step off the golden path of enlightenment. I use emacs, so I looked around for solutions, but they were only incomplete, or not real-time (e.g. checkpatch.pl has an –emacs option to run in the compile window of emacs).

So here’s something a little less incomplete that I’ve added to my .emacs file to catch the majority of checkpatch.pl errors in real-time (by highlighting the offending code in red). Works only on recent emacs versions. Hopefully it’ll be useful to others pounding away on their patches.

;; *** BEGIN highlight checkpatch.pl warnings and errors ***
(add-hook 'c-mode-common-hook
    (lambda ()
      ;; this sets defaults to match many checkpatch.pl guidelines
      (c-set-style "linux")))
;; but doesn't warn us about violations these regexp catch common ones
(custom-set-faces
    '(my-warning-face ((((class color)) (:background "red"))) t))
(add-hook 'font-lock-mode-hook
    (function
        (lambda ()
            (setq font-lock-keywords
                (append font-lock-keywords
		    '(("^.\\{81\\}" (0 'my-warning-face t)))
                    '(("\\/\\/.*" (0 'my-warning-face t)))
                    '((";[_A-Za-z0-9]+" (0 'my-warning-face t)))
                    '((",[_A-Za-z0-9]+" (0 'my-warning-face t)))
                    '(("return[[:blank:]]*(.+);" (0 'my-warning-face t)))
                    '(("([_A-Za-z0-9]+[\\*]+)" (0 'my-warning-face t)))
                    '(("[[:blank:]]+\\)"(0 'my-warning-face t)))
		    '(("^[[:blank:]]+{[[:blank:]]*$" (0 'my-warning-face t)))
		    '(("[_A-Za-z0-9]+\\*[[:blank:]]" (0 'my-warning-face t)))
		)))))
;; exercise to reader - move regexps into c hook
;; *** END highlight checkpatch.pl warnings and errors ***

Any enhancements or corrections are welcome.

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.

* 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)

A “no” in the above table means the client application will fail if that’s the only API option supported by the kernel framebuffer driver.

udlfb supports all four, with some limitations (e.g. defio is required to support mmap without damage reports).

The custom displaylink X server is the only client today which supports the last option, which is the most performant option on indirect displays (like USB displays) – and hopefully will become a standard interface as it’s useful in many cases.

Unfortunately for the DisplayLink udlfb framebuffer, each API has different constraints it places on the driver. Those constraints aren’t easily met all at once for a driver rendering to USB. AFAICT, it looks like the driver actually needs to figure out what kind of client it’s dealing with, and assume that client will stick to that sub-set of the API. That seems to be a safe assumption for the major fbdev apps today, but betting on something like this is always ugly.

Any misconceptions?

Hal Glenn from 2G Engineering has created an information display (on energy security and alternative methods of energy generation) with 9 USB touch screens, all running off a single Mac Mini running Ubuntu 9.10. And all using the available open source DisplayLink drivers and scripts and info at displaylink.org.

Doing this without USB displays would

• Require a big desktop box to support several PCIe graphics cards
• Would have triple the cords – Hal’s setup runs a single USB cable to each display. With VGA, you’d still need the USB cable (for touch function), but then would also need VGA and power to each!
• Would consume much more power – which would be kind of embarrassing for an energy security display, wouldn’t it?

Hal’s setup builds on and extends some of the USB terminal scripts demoed during this talk at Linux Plumbers Conference 2009.

There are several reasons why this demo is easiest on Linux, one of which is by default, DisplayLink devices are limited to 6 displays on Windows and Mac. The Linux drivers have no limit, so you can connect as many displays as you like — keeping in mind you’re sharing a 480Mbs bus (that itself has a 127 device limit). But it is enough for the apps Hal is running on those nine 800×480 touchscreens.

It will be interesting to see how many screens people get up to for various applications.

Add the following line to the bottom of the /lib/udev/rules.d/50-usbseat.rules file created per the previous instructions.

KERNEL=="control*", SUBSYSTEM=="sound", SUBSYSTEMS=="usb", PROGRAM="/bin/cat /sys/%p/../../../../../devnum", SYMLINK+="usbseat/%c/sound"

Then create a new /etc/X11/Xsession.d/50usbseat file which will be run at Xsession create time, with the following contents

oldIFS=$IFS
IFS=:
set $DISPLAY
IFS=.
set $2
SEAT_ID=$1
LN=`ls -al /dev/usbseat/$SEAT_ID/sound`
IFS=C
set $LN
CARD_ID=$2
export ALSA_CARD=$2
export ALSA_PCM_CARD=$2
IFS=$oldIFS

Each of the users who might need access to the USB devices needs to be added to the ‘audio’ group. On Ubuntu 9.04, this can be done with these commands to backup and then modify the groups (replace MY_USERNAME, of course) …

sudo cp /etc/group /etc/group_backup
sudo chmod a-wx /etc/group_backup
sudo adduser MY_USERNAME audio

See Ubuntu Sound TroubleShooting for details on that step.

Now, as you connect UD-160-A terminals, a new X instance and GDM login will pop up as before, but also each of them will have /dev/usbseat/%SEAT_ID%/sound linking to their sound device, and the ALSA_CARD environment variable for all processes off of that X session, set to the matching sound card ID. For apps which support ALSA/Pulse (like most browsers, flash, etc.), audio will now come out the correct terminal — all in a completely plug-and-play fashion.

If you’re wondering what the strange IFS stuff is in the above script, it’s bash’s built-in Internal Field Separator variable, which is an easy way to split strings without having to launch a separate sed or awk process.

Note, as before, these instructions are specific to and tested on an older version of Ubuntu: 9.04, and may need to be ported to other distros until the distros themselves integrate these scripts.

Thanks to Alexander Todorov’s earlier work on multiseat sound support, which demonstrated how to match the USB audio devices in udev, and which ALSA_ environment variables to set. Alexander reported some problems reliably matching the audio devices, but with these scripts (with limited testing so far), things are working as expected.

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)

The usb_skeleton.c sample driver appears to run afoul of this problem, resulting in a warn_on during bulk transfer completion, if done the way the sample recommends. Because completion routines can be called with irqs disabled, usb_buffer_free on dma-ready buffers can’t be called from them — which pushed the udlfb implementation to diverge from the skeleton model and pre-allocate a small set of urbs, and free only on driver disconnect.

Calls to usb_bulk_msg (simple synchronous bulk out) appeared to be silently failing for largish transfers (generally 16-32K). Nasty to track down, since no errors are returned. Caused removal all use of usb_bulk_msg from udlfb, except for transactions that are known to be small.

In the absence of a working X setup, and until the draw-during-probe issue is resolved, another great way to confirm your DL devices are working properly is with the fbi (“linux framebuffer imageviewer”) utility.

sudo apt-get install fbi

Run the above to install fbi (on Ubuntu/Debian).

fbi -d /dev/fb0 -a *.jpg

And this to show a full-screen slideshow with fbi — replacing “/dev/fb0” with one of your DisplayLink devices. You can “ls /sys/class/graphics/” to see all your framebuffer devices, and look within those directories for details on them. Of course, run the fbi utility from a directory with some jpgs (or other images) to display. pg-up/pg-down to move between photos.

You must run the fbi program from a console (fbi limitation). So hit Ctrl-Alt-F1 or something first, login from that text console, and run from there.

This wouldn’t work with older versions of udlfb or displaylink-mod (without defio support), and it makes a nice new test case. Now, short instructions for getting mplayer working for fbdev video would be welcome …

[update April 6, 2010: support for fbdev had been merged into the main udlfb codeline, including for 2.6.34, but has since been removed because of kernel faults that stand unsolved. If/when these problems can be found and fixed, fbdev support can get back into the mainline. Until then, the branch mentioned below is an ok way to try and test]

You can now get a version of udlfb with improved performance and support for any fbdev client.

Of the three DisplayLink Linux framebuffer driver lines, udlfb and displaylink-mod (written by Roberto DeIoris) have had the best performance by a significant margin. They’ve relied on Roberto’s custom X server, with some custom IOCTLs, to make use of precise X damage information. All the directions on the http://displaylink.org/ wiki have pointed to these drivers so far.

Unfortunately, these drivers won’t work with standard frambuffer clients that use a mmap’d framebuffer, because they’ll simply never refresh any area of the screen without damage notification. So drivers like the existing xf86-video-fbdev won’t work.

By contrast, Jaya Kumar’s defio-based DisplayLink codeline does work with xf86-video-fbdev or any standard fbdev client, but hasn’t been competitive performance-wise.

So the goal has been to merge the best aspects of both codelines — and get them merged into the kernel. That work isn’t completely done, but it’s at a working milesone. We now have a single kernel framebuffer driver that can support either roberto’s custom X driver (“displaylink”), or the standard fbdev X driver (“fbdev”), just by switching the “driver” line in the “server” section of xorg.conf. This makes for easier performance testing and workaround testing for X server specific problems.

And where previously, the fbdev driver was much slower than the displaylink custom (90% slower on some tests), it’s now within a few percentage points of difference – often not enough to notice.

There’s lots of room to optimize further yet, but this opens the possibility of not needing a custom X server at all for displaylink hardware, which would simplify the linux distribution rollout strategy.

You can grab this code at:

git clone http://git.plugable.com/webdav/udlfb
git checkout origin/defio

Then “make; sudo make install; sudo depmod -a” as usual. If you’re switching from displaylink-mod, get rid of that from the kernel modules directory first, or both udlfb and it may try to load.

Please post experience reports here or on the libdlo list. As patches have been developed for udlfb, there’s not been enough validation from the user community that the patches work and are valuable — and that would help the Linux kernel maintainers make their decisions about whether to accept patches.

Perf data is imperfect, but here’s a benchmark run of this code running the custom displaylink X server (making use of damage information)

bernie@bernie-aspireone:~/git/misc-udlfb$ ./udlfb-perf.sh fb0 gtkperf -a
GtkPerf 0.40 - Starting testing: Mon Dec 21 14:24:13 2009

GtkEntry - time:  0.00
GtkComboBox - time:  3.00
GtkComboBoxEntry - time:  1.89
GtkSpinButton - time:  0.42
GtkProgressBar - time:  0.60
GtkToggleButton - time:  0.44
GtkCheckButton - time:  0.42
GtkRadioButton - time:  0.75
GtkTextView - Add text - time:  2.09
GtkTextView - Scroll - time:  0.83
GtkDrawingArea - Lines - time:  1.66
GtkDrawingArea - Circles - time:  3.09
GtkDrawingArea - Text - time:  2.89
GtkDrawingArea - Pixbufs - time:  0.27
 ---
Total time: 18.37

Quitting..

model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
cpu MHz         : 1600.000
cpu MHz         : 1333.000
MemTotal:        2052144 kB
Framebuffer Mode: 1920,1080

Rendered bytes:  155896744 (total pixels * Bpp)
Identical bytes: 96231480 (skipped via shadow buffer check)
sent bytes:      29614624 (compressed usb data, including overhead)
K CPU cycles:    1251295 (transpired, may include context switches)

% pixels found to be unchanged: 61.00 %
Compression of changed pixels : 50.00 %
Total CPU cycles spent per input pixel: 8
Total CPU cycles spent per output pixel: 42
USB Mbps: 11.29 (theoretical USB 2.0 peak 480)

And here’s a benchmark run of the same, just switched to run the standard fbdev X server (making use of only page faults)

bernie@bernie-aspireone:~/git/misc-udlfb$ ./udlfb-perf.sh fb0 gtkperf -a
GtkPerf 0.40 - Starting testing: Mon Dec 21 12:45:20 2009

GtkEntry - time:  0.00
GtkComboBox - time:  3.16
GtkComboBoxEntry - time:  1.80
GtkSpinButton - time:  0.41
GtkProgressBar - time:  0.60
GtkToggleButton - time:  0.44
GtkCheckButton - time:  0.41
GtkRadioButton - time:  0.76
GtkTextView - Add text - time:  2.03
GtkTextView - Scroll - time:  0.82
GtkDrawingArea - Lines - time:  1.87
GtkDrawingArea - Circles - time:  3.36
GtkDrawingArea - Text - time:  2.84
GtkDrawingArea - Pixbufs - time:  0.22
 ---
Total time: 18.73

Quitting..

model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
cpu MHz         : 1333.000
cpu MHz         : 1600.000
MemTotal:        2052144 kB
Framebuffer Mode: 1920,1080

Rendered bytes:  288165888 (total pixels * Bpp)
Identical bytes: 227263860 (skipped via shadow buffer check)
sent bytes:      39281496 (compressed usb data, including overhead)
K CPU cycles:    1685041 (transpired, may include context switches)

% pixels found to be unchanged: 78.00 %
Compression of changed pixels : 35.00 %
Total CPU cycles spent per input pixel: 5
Total CPU cycles spent per output pixel: 42
USB Mbps: 14.98 (theoretical USB 2.0 peak 480)

The “Compression of changed pixels” is lower on fbdev, because the unchanged pixel detection is less accurate for the page fault method (for now, but that will get fixed ..), and so there’s a lot of re-rendering of desktop pixels — and my desktop background is a complex, gradient heavy image that doesn’t compress well.

The main performance gains vs. the original defio implementation are:

• Added RLE compression on the defio path
• Added shadow/backbuffer to scan for unchanged pixels on the defio path
• Moved to asynchronous urb dispatch for defio and damage codepaths (4 pre-alloc’d 64K urbs). This also has a significant performance benefit for the custom/damage path
• Changed defio path to no longer send an urb per line, but rather fill every urb completely, across lines and dirty pages. Big gain for defio.

So, to enable people to generate that better data, a few lightweight and very low-level benchmarks have been added to udlfb in this patch, which can be grabbed with:

git clone http://git.plugable.com/webdav/udlfb
git checkout origin/sysfs-metrics

What has been added is a set of metrics which are exposed through sysfs. After building branch of the driver with “sudo make install; sudo depmod -a” and a reboot, you’ll find these new files on your system:

ls /sys/class/graphics/fb0/metrics_*
/sys/class/graphics/fb0/metrics_apis_used
/sys/class/graphics/fb0/metrics_bytes_identical
/sys/class/graphics/fb0/metrics_bytes_rendered
/sys/class/graphics/fb0/metrics_bytes_sent
/sys/class/graphics/fb0/metrics_cpu_kcycles_used
/sys/class/graphics/fb0/metrics_reset

If you read any of these files, a request will go down to the udlfb driver, and it will return back the matching metric. One file is write-only: metrics_reset. Writing anything to it will set all the others back to zero.

Sysfs is a really nice mechanism — we can now create some more elaborate test scenarios easily from user mode, and get fairly precise data back from kernel mode.

If you have a working setup of X on top of udlfb (I use this method) — or anything that renders to the framebuffer device — you can now get some much better data about what’s happening in udlfb.

As an example, a script called udlfb-perf.sh has been created to run tests and pretty print a simple report. Here’s the output from a test run on my Acer Aspire laptop running Ubuntu 9.04, using gtkperf as scenario to benchmark.

./udlfb-perf.sh fb0 gtkperf -a
GtkPerf 0.40 - Starting testing: Thu Dec  3 15:16:12 2009

GtkEntry - time:  0.00
GtkComboBox - time:  3.17
GtkComboBoxEntry - time:  1.93
GtkSpinButton - time:  0.40
GtkProgressBar - time:  0.60
GtkToggleButton - time:  0.45
GtkCheckButton - time:  0.41
GtkRadioButton - time:  0.74
GtkTextView - Add text - time:  1.99
GtkTextView - Scroll - time:  0.86
GtkDrawingArea - Lines - time:  1.89
GtkDrawingArea - Circles - time:  3.13
GtkDrawingArea - Text - time:  3.05
GtkDrawingArea - Pixbufs - time:  0.56
 --- 
Total time: 19.18

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:  187064790 (total pixels * Bpp)
Identical bytes: 112816894 (skipped via shadow buffer check)
sent bytes:      35556944 (compressed usb data, including overhead)
K CPU cycles:    4316313 (transpired, may include context switches)

% pixels found to be unchanged: 60.00 %
Compression of changed pixels : 52.00 %
CPU cycles spent per pixel: 23
USB Mbps: 13.56 (theoretical USB 2.0 peak 480)

To run this, you’ll need the udlfb-perf.sh script (shown below, and also in git here)

And you’ll need gtkperf:

sudo apt-get install gtkperf

Run udlfb-perf on your DisplayLink display, passing it the appropriate framebuffer device (e.g. ./udlfb-perf.sh fb0 gtkperf -a)

#!/bin/bash
# (C) 2009 Bernie Thompson https://plugable.com/
# License http://www.opensource.org/licenses/mit-license.html

if [ $# -eq 0 ]
then
    echo
    echo "Usage: $0 fbX [test to benchmark] [test parameters ....]"
    echo "[fbX] must be device visible in /sys/class/graphics directory"
    echo "and should be the DisplayLink device X is currently using"
    echo
    echo "Example: ./udlfb-perf.sh fb0 gtkperf -a"
    echo
    exit 1
fi

dev=$1
prog=$2
shift 2

echo 1 > /sys/class/graphics/$dev/metrics_reset

start=$(date +%s)
$prog $@
end=$(date +%s)

rendered=`cat /sys/class/graphics/$dev/metrics_bytes_rendered`
sent=`cat /sys/class/graphics/$dev/metrics_bytes_sent`
identical=`cat /sys/class/graphics/$dev/metrics_bytes_identical`
cycles=`cat /sys/class/graphics/$dev/metrics_cpu_kcycles_used`
mode=`cat /sys/class/graphics/$dev/virtual_size`

bus_compress=`/usr/bin/bc <
It'd be interesting to see results from other systems and/or some suggested benchmarks other than gtkperf (especially a repeatable video playback test).  Please feel free to comment with any of that.
]]>
					
					https://plugable.com/2009/12/03/displaylink-linux-performance-metrics/feed/
			0
		
		
		302	
		
		
		https://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/
					https://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/#comments
		
		
		Tue, 17 Nov 2009 00:55:17 +0000
				
		
		
		
		
		
		
		http://plugable.com/?p=268

					
										Soon, we’ll be able to plug inexpensive zero-state USB docks/terminals into new Linux systems, and a new graphical login will pop up in a completely plug and play fashion. Many users can then simultaneously share any single Linux PC.  This is great for education, libraries, internet cafes, etc — anywhere where you have clusters of client machines with light 3D/video app demands, and want the simplicity and savings of just one server machine with many terminals connected.

[Update August 8, 2010 – Further work on this has moved to the Google Summer of Code 2010 project for USB Multiseat]
Until this is in the distros, we have to assemble a few pieces ourselves to get everything installed for this scenario.  Some major components (GDM/ConsoleKit) are changing the way this kind of thing will be done, so for now the instructions here are designed only for distributions with GDM 2.20 or earlier (Ubuntu < 9.10;  Fedora < F12; Debian < 5.0; etc). The instructions have been tested most extensively on Ubuntu 9.04. 

gdm –version
 will show what version you have on your current system. Any tweaks to make things work with your specific distro are definitely welcome in the comments.
The first step is hardware.  You need a USB hub with a DisplayLink USB device and free USB ports for keyboard and mouse.  You can get this in one package in the form of devices like the Plugable DC-125, or buy independent USB devices like the UGA-125 combined with any USB hub.  USB Audio and other devices can be made to work also, but these instructions just cover basic display, keyboard, and mouse.
With that, you’re ready to start configuring your Linux setup  …
1. DisplayLink framebuffer driver
udlfb is in the staging tree of Linux kernels 2.6.32 and later.  We’ll install the latest version here.  First, make sure you have git installed with “sudo apt-get install git-core”, and create a directory which will host all the source code you download with git (e.g. ~/git/).  
sudo apt-get install module-assistant
sudo module-assistant prepare
git clone http://git.plugable.com/webdav/udlfb/
cd udlfb
make
sudo make install
sudo depmod -a

Now, when you plug in a DisplayLink device, you should see a “green screen” as the driver successfully loads and sets the graphics mode to match your monitor.  
2. DisplayLink X server
This will get the X server installed, ready for use by later scripts.
sudo apt-get install pkg-config xorg-dev
cd ~git
git clone http://git.plugable.com/webdav/xf-video-udlfb/
cd xf-video-udlfb
./configure
make
sudo make install

We now need to create or modify a few scripts and configuration files.  You’ll need to use sudo to edit files in these system directories.  You can cut/paste the text below, or download the files with “git clone http://git.plugable.com/webdav/misc-udlfb/” and copy each to the right location, and fix up ownership and permissions on the files.
3. udev script
Create a file called /lib/udev/rules.d/50-usbseat.rules owned by user root, with the following contents.  
# set all DisplayLink devices to configuration 1
# see http://libdlo.freedesktop.org/wiki/DeviceQuirks for more info
ATTR{idVendor}=="17e9", ATTR{bConfigurationValue}=="2", RUN="/bin/echo 1 > /sys%p/bConfigurationValue"

# aliases for display, kbd, mouse attached to specific hubs

KERNEL=="fb*",SUBSYSTEMS=="usb",PROGRAM="/bin/cat /sys/%p/../../../devnum",SYMLINK+="usbseat/%c/display",RUN+="usbseat.sh %c"
KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceProtocol}=="02", PROGRAM="/bin/cat /sys/%p/../../../../../devnum",SYMLINK+="usbseat/%c/mouse",RUN+="usbseat.sh %c"
KERNEL=="event*", SUBSYSTEM=="input", ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceProtocol}=="01",PROGRAM="/bin/cat /sys/%p/../../../../../devnum",SYMLINK+="usbseat/%c/keyboard",RUN+="usbseat.sh %c"
KERNEL=="control*", SUBSYSTEM=="sound", SUBSYSTEMS=="usb", PROGRAM="/bin/cat /sys/%p/../../../../../devnum", SYMLINK+="usbseat/%c/sound"

# Handle when keyboard and mouse are one more hub downstream. Relying on pnp order to have already set up mouse, keyboard on upstream hub if we're daisy-chaining
KERNEL=="event*", SUBSYSTEM=="input", ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceProtocol}=="01",PROGRAM="/bin/cat /sys/%p/../../../../../../devnum",SYMLINK+="usbseat/%c/keyboard",RUN+="usbseat.sh %c"
KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceProtocol}=="02", PROGRAM="/bin/cat /sys/%p/../../../../../../devnum",SYMLINK+="usbseat/%c/mouse",RUN+="usbseat.sh %c"

The udev subsystem will run this script automatically each time a USB device is attached. 
4. usbseat.sh script
Create a file /lib/udev/usbseat.sh owned by user root with the following contents. Make sure to “sudo chmod a+x” to make the file executable.
#!/bin/bash
# takes the "seat number" as parameter $1
# the seat number is the kernel device id of the hub the seat's devices are sitting off of
# called once for every usb device that MIGHT be part of a seat, when they arrive or remove 

if [[ !(-n `/bin/pidof gdm`) ]]; then
    exit 0
fi

seat_running=`/usr/bin/gdmdynamic -l | /bin/sed -n -e "/:$1,/p"`

# $ACTION environment variable is set by udev subsystem
case "$ACTION" in
	'remove')
		if [[ -n "{$seat_running}" ]]; then
			/usr/bin/gdmdynamic -v -d $1
		fi
		;;
	*)
                # A device which might be part of a seat has been added

		# if we already have a running seat for this #, exit
		if [[ -n "${seat_running}" ]]; then
			exit 0
		fi

		if [[ -e /dev/usbseat/$1/keyboard && -e /dev/usbseat/$1/mouse && -e /dev/usbseat/$1/display ]]; then

			# We have a newly complete seat. Start it.
			TMPFILE=`/bin/mktemp` || exit 1
			/bin/sed "s/%ID_SEAT%/$1/g" < /lib/udev/usbseat-xf86.conf.sed > $TMPFILE
			/usr/bin/gdmdynamic -v -t 2 -s 1 -a "$1=/usr/X11R6/bin/X -br :$1 -audit 0 -nolisten tcp vt07 -config $TMPFILE"
			/usr/bin/gdmdynamic -v -r $1
		fi
		;;
esac

exit 0

5. X config file
Create file /lib/udev/usbseat-xf86.conf.sed with contents

Section "ServerFlags"
	Option	"AutoEnableDevices"	"false"
	Option	"AutoAddDevices"	"false"
	Option  "DefaultLayout"		"seat"
	Option	"DontZoom"		"true"
	Option	"DontZap"		"true"
	Option	"AllowMouseOpenFail"	"yes"
EndSection

Section "Module"
	Load "ddc"
EndSection

Section "Files"                                                                                                              
    ModulePath      "/usr/lib/xorg/modules"
    ModulePath      "/usr/local/lib/xorg/modules"
EndSection

Section "Device"
	Identifier "dl"
	driver	   "displaylink"
	Option "fbdev"	"/dev/usbseat/%ID_SEAT%/display"
EndSection

Section "InputDevice"
	Identifier "keyboard"
	Driver	"evdev"
	Option	"CoreKeyboard"
	Option	"Device"	"/dev/usbseat/%ID_SEAT%/keyboard"
	Option	"XkbModel"	"evdev"
	Option	"XkbLayout"	"us"
EndSection

Section "InputDevice"
	Identifier "mouse"
	Driver	"mouse"
	Option	"CorePointer"
	Option	"Protocol" "ImPS/2"
	Option	"Device"	"/dev/usbseat/%ID_SEAT%/mouse"
        Option  "Buttons" "5"
	Option	"ZAxisMapping" "4 5"
EndSection

Section "Monitor"
	Identifier "monitor"
EndSection

Section "Screen"
	Identifier "screen"
	Device "dl"
	Monitor "monitor"
EndSection

Section "ServerLayout"
	Identifier "seat"
	Screen	0 "screen" 0 0 
	InputDevice "keyboard" "CoreKeyboard"
	InputDevice "mouse" "CorePointer"
EndSection


6. fbcon workaround
[update: this step is no longer needed with the latest udlfb from git or in kernels 2.6.37+]
fbcon is a standard Linux kernel module, which aggressively assumes it can open any framebuffer device and take it over for use as a text terminal.  Unfortunately, that’s not what we want if we’re going to be using that framebuffer to run its own X server.  So we need to add a file /etc/modprobe.d/fbcon.conf to disable fbcon and leave our framebuffers free for other uses.
blacklist font
blacklist tileblit
blacklist bitblit
blacklist fbcon

This file will not take effect until you run
sudo update-initramfs -u

Now, when you reboot and run “lsmod” you should not see fbcon in the loaded modules.  And in /sys/class/graphics you should see fb0, instead of fbcon.
7. xrandr workaround
[update: this workaround is not needed when running xf86-video-fbdev or with recent displaylink X servers with this patch]
The DisplayLink X server currently has limited RANDR support, but later versions of GDM assume better.  So for the time being, a workaround is required to get GDM applications (including gdmlogin) to display properly within the actual screen area — otherwise they tend to think the screen has a strange rotation, and display themselves completely off it.
Add these lines into /etc/gdm/Init/Default, right after the definition of gdmwhich()
XRANDR=`gdmwhich xrandr`
if [ "x$XRANDR" != "x" ]; then
  $XRANDR -o 0
fi

8. /etc/rc.local script
Add the following lines to your /etc/rc.local script to check for attached usb terminals that were attached (at boot), and udev found them before GDM was running.
oldIFS=$IFS
IFS=/
for seat in /dev/usbseat/*; do
	set $seat
	/lib/udev/usbseat.sh $4
done
IFS=$oldIFS

9. /etc/init.d/gdm patch
In recent versions of X, the system largely assumes that you’ll only run one X server, and it will own all devices.  So to support multiseat with multiple X servers easily, we need to have two configurations: normal (using only your primary graphics), and multiseat (where your primary graphics isn’t used).  We do this by detecting whether you have a USB terminal attached and configured, and if so coming up with a different gdm configuration.
Add these lines to your /etc/init.d/gdm script, just after the section to “Allow cdd to override the config” (around line 35).
# Allow usbseat to override the config
if [ -f /etc/gdm/gdm-usbseat.conf ]; then
	for usbseat in /dev/usbseat/*; do
		seatid=${usbseat##*/}
		if [ -e "/dev/usbseat/$seatid/keyboard" -a -e "/dev/usbseat/$seatid/mouse" -a -e "/dev/usbseat/$seatid/display" ]; then
			CONFIG_FILE="--config=/etc/gdm/gdm-usbseat.conf"
		fi
	done
fi

10. Create /etc/gdm/gdm-usbseat.conf
This is the alternative gdm.conf that will be used when a USB terminal is present at boot:
[daemon]
DynamicXServers=true
FlexibleXServers=0
Greeter=/usr/lib/gdm/gdmgreeter

[security]

[xdmcp]

[gui]

[greeter]

[chooser]

[debug]

[servers]
0=inactive

Now, when you boot with USB terminal(s) attached, graphical logins will come up on all of those, while your primary display will remain a text console.

See my video from Linux Plumbers 2009 for more thoughts and background on USB multiseat.
Unsolved Problems
Beyond reworking for the new GDM/ConsoleKit versions, and getting all this just “built in” to the distributions, there are at least several major problems yet:
input duplication
[Update Feb 19, 2010 – fixed by removing “-sharevts -novtswitch” from the X start line and substituting a specific vt “vt07”.  Listing above now has problem resolved]
Input to any of the terminals will be duplicated to your primary console.  This has a bunch of very nasty effects, including often duplicating your login to both your session and the console, and possibly causing strange effects like ctrl-c within any terminal will often cause that whole X session to close.  This seems to be http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525736, which at the bottom reports a workaround involving faketty, which unfortunately didn’t work for me. You can also see a short discussion of this bug at https://fedorahosted.org/pipermail/multiseat/2009-April/date.html  There ought to be a simple solution here — any comments on that welcome.
mouse scroll wheel doesn’t work
[Update Feb 19, 2010 – fixed by changing Protocol from “auto” to “ImPS/2” in the xorg.conf]
This is a problem with some other ways of doing multiseat: https://fedorahosted.org/pipermail/multiseat/2009-February/000004.html Again, probably a small tweak might resolve this.
unplug terminal doesn’t tear down (or reconnect)

Currently, when you physically disconnect a terminal, everything remains running.  By default, each user can only be logged in once, which means that you must do gdmdynamic -l to find the zombie instance and sudo gdmdynamic -d $seat to kill it.  But the behavior users would really like to see is disconnecting the terminal leaves all apps running, but logging in from that terminal (or any other) reconnects and just transparently starts where the user left off.
Comments on other distros (e.g. yum vs. apt-get), better solutions, and other problems are very much appreciated.
]]>
					
					https://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/feed/
			58
		
		
		268	
		
		
		https://plugable.com/2009/11/11/udlfb-0-4-0/
					https://plugable.com/2009/11/11/udlfb-0-4-0/#comments
		
		
		Wed, 11 Nov 2009 19:54:20 +0000
				
		
		
		
		
		
		
		
		
		
		
		http://plugable.com/?p=250

					
										[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.
]]>
					
					https://plugable.com/2009/11/11/udlfb-0-4-0/feed/
			1
		
		
		250	
		
		
		https://plugable.com/2009/11/02/displaylink-kernel-framebuffer-performance/
					https://plugable.com/2009/11/02/displaylink-kernel-framebuffer-performance/#comments
		
		
		Mon, 02 Nov 2009 23:46:02 +0000
				
		
		http://plugable.com/?p=230

					
										There are three codelines of Linux DisplayLink kernel frambuffer drivers currently in use:


udlfb (Roberto De Ioris), which is in the Linux kernel staging tree of 2.6.31 and later, and is enabled by default in some recent distros (Ubuntu 9.10). Capable of working with all DisplayLink devices.
displaylink-mod (Roberto De Ioris), which adds dynamic mode support and a few other minor changes
displaylinkfb (Jaya Kumar), which tries out some innovative approaches (defio page-fault change detection), uses existing fbdev x servers without modification, but is much slower (80% slower on example test) than udlfb and displaylink-mod, which both use X damage information and RL/RAW compression
udl (Marcus Glocker) for FreeBSD (not Linux) text/graphics console driver interface, which makes use of damage and ports Huffman-style compression from Florian Echtler’s libtubecable library. This support is currently ahead of what’s on Linux.

You can get more information about these drivers at http://libdlo.freedesktop.org/wiki/HowTo
In general, most of the demos and videos posted here use displaylink-mod. Some performance improvement patches are available at http://git.plugable.com/, but they are a relatively small improvement.  
So any conclusions of of the performance work so far?

 Graphics benchmarks on Linux are in rough shape.  Most practical approach so far has been simplistically using a combination of glxgears and a few select tests from x11perf.  Good video playback tests needed.
 Jaya’s displaylinkfb driver tries some interesting concepts, but the lack of damage information from X means it runs much slower (up to 80% slower) than the alternatives for now.
The original RL compression in udlfb by Henrik Bjerregaard Pedersen is surprisingly effective, even though it only uses one of RLE or RAW for each 255 pixel segment. It’s relatively CPU-efficient with simple inner loops, and decently USB-efficient in practice.
The alternating RL/RAW algorithm in the master branch at http://git.plugable.com/ does slightly better, but it varies per test and is not dramatic.
The shadow/back buffer that udlfb and displaylink-mod keep do provide a significant gain on maybe one out of every 4 tests or so, but X’s damage information is quite accurate — so saving that allocation and the ongoing reads/writes to that extra memory by forgoing the back buffer is definitely viable and should at least be a module option.  The ‘noback’ branch at http://git.plugable.com/ has this removed (despite what one comment checkin says), for anyone who wants to try it. 

Perhaps the best and quickest path forward to getting support more widely distributed is

Bringing udlfb up to snuff, since there are just a few functional changes in the displaylink-mod branch, and udlfb already is going through the staging->mainline confidence building process
For the matching X server, it would be great to have kernel driver that works with both the standard http://cgit.freedesktop.org/xorg/driver/xf86-video-fbdev/  at some level of performance, or with the custom displaylink xserver at some (better) level of performance.  Then move things (like damage support, which is key to performance) from the displaylink server to the fbdev server in a standardized way over time.
Then there’s a bunch of other more involved work to come on configuration and coexistence with multiple graphics controllers.  Rough plans are visible in the fog here, but they involve other projects and people.

]]>
					
					https://plugable.com/2009/11/02/displaylink-kernel-framebuffer-performance/feed/
			1
		
		
		230	
		
		
		https://plugable.com/2009/10/27/plug-and-play-multiseat-talk-given-at-linux-plumbers-conference-2009/
					https://plugable.com/2009/10/27/plug-and-play-multiseat-talk-given-at-linux-plumbers-conference-2009/#respond
		
		
		Tue, 27 Oct 2009 09:49:15 +0000
				
		
		
		
		http://plugable.com/?p=223

					
										The video of the talk mentioned in this previous post, is now online (recently moved from the Linux Foundation site, to youtube in 4 parts).


Covering:

The potential of USB multiseat
Some background and earlier work
Live demo of USB multiseat with three Plugable devices
Walkthrough of the multiseat scripts for Ubuntu 9.04 (available here)

The same device used in the demos is available for purchase here:


]]>
					
					https://plugable.com/2009/10/27/plug-and-play-multiseat-talk-given-at-linux-plumbers-conference-2009/feed/
			0
		
		
		223	
		
		
		https://plugable.com/2009/10/13/using-the-plugable-dock/
					https://plugable.com/2009/10/13/using-the-plugable-dock/#comments
		
		
		Tue, 13 Oct 2009 21:38:39 +0000
				
		
		
		
		
		
		
		
		http://plugable.com/?p=166

					
										

Click on the picture for more detail.  This is a picture of my work desk today and how I’m using the Plugable dock myself.
 (yes — I cleaned off a few books and papers — it’s usually much messier!)
My $330 Acer Aspire One Atom 1.6Ghz netbook is on the left — I like having a very thin, light, and cheap development platform that I can throw in a bag to go to a coffee shop, etc.  But I can’t stand working on the small 10″ screen all day, so that large screen to the right (21.5″) is a necessity.  And using the netbook trackpad is right out — I definitely need a full sized mouse.  The keyboard on the Acer isn’t that bad, but I like having the slightly larger keys and distance from the screen that the USB keyboard gives me.
So what’s connected to the dock there in the middle?  Up the left hand side, from the bottom, are:

Power for the dock
USB from the dock to the netbook (that’s the same USB cable plugged into the left side of the netbook)
DVI cable to the monitor (being driven by the DisplayLink chip in the dock)
network connection (I’m using 100Mbs wired ethernet)
USB cable to a printer under the table
USB flash drive

On the right hand side of the dock, the two cables are the USB keyboard and mouse.  And on the right side of the netbook are power for the netbook, and a USB cable going down to another device (a SheevaPlug) nearby.
So every time I take my highly portable netbook anywhere — without the dock, I’d have 8(!) cables to unplug/replug every time, including a big, fat DVI->VGA cable to screw into the side of my netbook.  Instead, I have 2 or 3 cables, and get connected to a ton of devices — including the large screen, which absolutely transforms this cheap netbook into something far more functional.
Also, I’m constantly switching between Windows and Linux, and all I need to do is reboot, and all the devices here can work in both environments. In this pic, I’m running Linux.  Note that on Windows, there are production drivers that “just work” (especially if you have Microsoft’s Windows Update enabled), While Linux requires some configuration yet, and has limitations — I’m only using the one large screen (the netbook screen is a text terminal), and I’m not using some things like the audio ports there yet.
I’ve also got a Macbook on the shelf to the left – plug it in, and again all the devices work, including that extra large display.  The simple ubiquity of USB is extremely compelling with devices like this that have been designed to use components with drivers across all the major platforms.
I love this setup – it’s far better with the dock than without it.  Over the next few weeks, as Windows 7 launches, etc., look for more posts here on how to use the dock in these different environments.  For example, Windows 7’s improved Windows Update and driver install are a big step forward that have to be seen to be appreciated.
And by the way, in the picture on the large screen – you can see firefox on Linux, showing the Plugable website. and a smaller window, which is a terminal connected over that other USB wire, to a SheevaPlug which is getting an install of the latest version of Debian.  That’s another interesting possibility.  More on that later …
]]>
					
					https://plugable.com/2009/10/13/using-the-plugable-dock/feed/
			5
		
		
		166	
		
		
		https://plugable.com/2009/10/08/emerging-roadmap-for-linux-multiseat/
					https://plugable.com/2009/10/08/emerging-roadmap-for-linux-multiseat/#respond
		
		
		Thu, 08 Oct 2009 20:00:24 +0000
				
		
		
		
		http://plugable.com/?p=152

					
										The most common use of the Plugable Docking Station today is to enable a Windows/Mac laptop to plug a single USB cable and gain connectivity to an additional monitor, speakers, network cable, and any other 4 USB devices.

But the same hardware can be also used on Linux to extend the computer in a different way – provide an second (or 3rd, 4th …) USB terminal to let several people share that Linux PC. With this $99 device and a spare monitor, keyboard, and mouse, you get an extra PC.



Here we have 4 UD-160-A terminals connected to a single netbook, using existing open source drivers and instructions.
But this area of Linux is in flux, and some of the underlying mechanisms used by that demo (particularly gdmdynamic) are being deprecated.
So what’s the way forward for plug and play multiseat on Linux? This touches many components, so the discussion is happening in several places, but the recent discussions on the ConsoleKit mailing list is probably the best summary.
When this support is integrated widely into the various Linux distros,  you’ll be able to plug in a device like the UD-160-A and have it automatically pop up a login (from the user perspective, apparently power on whole additional computer).
And that’s when this flexible, multi-use device gets even more interesting …
]]>
					
					https://plugable.com/2009/10/08/emerging-roadmap-for-linux-multiseat/feed/
			0
		
		
		152	
		
		
		https://plugable.com/2009/09/22/plug-and-play-multiseat-presentation/
					https://plugable.com/2009/09/22/plug-and-play-multiseat-presentation/#respond
		
		
		Wed, 23 Sep 2009 06:04:07 +0000
				
		
		
		
		
		http://plugable.com/?p=34

					
										In getting more background from this talk, it was great to review the videos on ndiyo.org and displaylink.org with all the history and background on the concept of low-cost multiseat.  Didn’t want too much history in slides, but it will come up verbally, and it’s a rich and interesting history.

The one comment the presentation generated was “what happened to all the other people on earth?” 
Plug and Play Multiseat – Sides for Linux Plumbers Conference BoF Sept 23, 2009.
Hopefully the outcome of the conference will be more awareness and energy directed towards making this stuff “just work”.
]]>
					
					https://plugable.com/2009/09/22/plug-and-play-multiseat-presentation/feed/
			0
		
		
		34