Plugable

Google Summer of Code – USB Multiseat

Posted on 06. Apr, 2010 by Bernie Thompson in udlfb

Plugable is offering mentoring and donated hardware for USB graphics projects that are funded as part of Google Summer of Code 2010. Plugable is working through X.Org as a sponsoring organization.

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 http://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.

xorg-server 1.8.0 released

Posted on 02. Apr, 2010 by Bernie Thompson in udlfb

xorg-server 1.8.0 has been released.

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.

Update on DisplayLink Linux support (udlfb in 2.6.34)

Posted on 14. Mar, 2010 by Bernie Thompson in udlfb

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.