Category Archives: Planet Freedesktop

One Fedora 17 Box up to 16 USB Multiseat Terminals

Fedora 17, as shipped, supports only 7 or 8 plug-and-play USB terminals per machine. The cause is the kernel evdev driver’s limit of 32 input devices.

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
# 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!

Dconf configuration: GNOME 3 Fallback Mode

The Linux GNOME 3 UI assumes you have a beefy 3D GPU and capable driver, which can cause problems when that isn’t the case.

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:


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:


show-desktop-icons = true

# This one is useful more for automatic USB multiseat
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:


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 USB 2.0 Multiseat Zero Client for Windows Multipoint Server and Fedora Linux (DisplayLink D... Product Details

New Distros and Linux Automatic USB Multiseat Support

OpenSUSE and ArchLinux appear to be making good progress on integrating the latest version of systemd, which is a central element of Linux’s new Automatic USB multiseat support — letting you turn one machine into many with plug and play USB terminals.

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 Multiseat Zero Client for Windows Multipoint Server and Fedora Linux (VGA up... Product Details

DisplayLink USB Devices on Linux Kernel 3.4.0

Linux kernel 3.4.0 is the first to include a new driver for DisplayLink-based USB 2.0 devices, called “udl”. udl is a port of the udlfb driver to Linux’s DRM architecture. David Airlie is doing this work, and the potential is very exciting. Eventually, this architecture will lead to a host of advantages, including GPU-accelerated 3D rendering to USB graphics adapters.

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 Multiseat Zero Client for Windows Multipoint Server and Fedora Linux (VGA up... Product Details

Fedora 17′s Secret Turbo Boost Button

Fedora 17′s out-of-the-box plug and play USB multiseat is awesome for sharing one system with many users — but there’s a way to dramatically boost performance and scalability, by changing the Fedora defaults.


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 Multiseat Zero Client for Windows Multipoint Server and Fedora Linux (VGA up... Product Details

Howto: DisplayLink USB Single Monitor on Linux

Unfortunately, Linux doesn’t support multiple graphics adapters the way Windows does, which means you can’t just plug in USB graphics adapters and expect them to extend your desktop (the good news is there is progress on this support).

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

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"

Section "Monitor" 
  Identifier "monitor" 

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

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

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


Plugable’s New 10-Port USB 2.0 Hub

A lot of USB hubs end up looking like a porcupine on your desk – wires going in all directions.

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

[amtap amazon:asin=B00483WRZ6]

Howto: ASIX 88178 USB Ethernet Adapter on Ubuntu 10.10 Linux

[update Dec 2011: Linux kernel 3.2 rc3 and later "just work" (with config USB_NET_AX8817X), so the following steps are not needed.]

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+


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

mkdir asix
cd asix
tar xvjf *
sudo apt-get install module-assistant
sudo module-assistant prepare
sudo modprobe -r asix
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 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.

Plugable Open Source Hardware Samples Program

From time to time Plugable has extra test hardware around our labs. Rather than have it gather dust, we’d like to send it out to the open source community to help foster driver development.

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 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.

DisplayLink Linux kernel driver (udlfb) updates slated for 2.6.37

The latest set of patches for udlfb, the Linux kernel framebuffer driver for DisplayLink chips, has been submitted and looks on track for kernel 2.6.37. This will catch the kernel up to everything on

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.

[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


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.