X.Org Server 1.8 Release Candidate 2

Posted on 22. Mar, 2010 by in UGA-2K-A

X.Org has announced RC2 of the 1.8 server release for Linux and other *nix operating systems. 1.8 contains several new features and configuration capabilities that will form the foundation of future USB multiseat work. In effect, USB multiseat has been waiting for this work to stabilize and get into the distros (of which Fedora 13 will be one of the first).

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

DisplayLink Snow Leopard 64-bit Support in Beta

Posted on 22. Mar, 2010 by in UGA-2K-A

DisplayLink has just released an updated beta OS X driver with Snow Leopard 64-bit support.

Previously, Snow Leopard users had to be careful to stick with a 32-bit kernel to use DisplayLink devices. This driver removes that limitation.

The beta drivers are available from DisplayLink here: http://displaylink.org/forum/showthread.php?t=268

These drivers work on all of Plugable’s laptop docking and graphics adapter products (UD-160-A and UGA-2K-A). Note that this driver is still in beta, and has limitations which are noted below in DisplayLink’s release notes.

DisplayLink Mac OS X Software Release: External Release Note

Version: 1.6b1 (23745)
Date: 18th March 2010

Improvements over the DisplayLink Mac OS X Software 1.5 release

* Snow Leopard (64 Bit) Support

More information on how to use this software can be found in the Mac OS X User Guide found on the DisplayLink website (http://www.displaylink.com/mac)

Supported Operating Systems

The DisplayLink software can be installed on any Intel-based desktop
or laptop Apple Mac computer running client versions of Mac OS X Snow Leopard 10.6.2 (32 and 64 bit versions), Mac OS X Leopard 10.5.8 and Mac OS X Tiger 10.4.11.

Note that at the time of writing these were the latest available versions of Mac OS X tested against.

Supported Mac platforms

This software supports all Intel-based Macs. It does not support Power-PC based Macs.

Known Issues

This is a DisplayLink driver release that supports 2D acceleration on Mac OS X platforms. This software has some limitations:

* No 3D (OpenGL) acceleration – some features of Mac OS X applications that require hardware OpenGL
acceleration, such as Keynote presentations and iPhoto slideshows, will not function properly.

* Colour calibration does not work with DisplayLink enabled displays on Mac OS X versions prior to 10.6.2

Note: Applications that require Quartz OpenGL hardware acceleration support will likely exhibit problems with this version of DisplayLink software. Some problems can be avoided by making sure the DisplayLink display is not set to be the main display (the display with the menu bar) If an application refuses to launch when a DisplayLink display is present, try to disconnect all the DisplayLink displays, then launch it and then reconnect the displays.

Update on DisplayLink Linux support (udlfb in 2.6.34)

Posted on 14. Mar, 2010 by in UGA-2K-A

[Update Jan 2011: Udlfb was promoted from the staging tree to the main kernel (in drivers/video/udlfb.c) in 2.6.38. See documentation in the kernel tree at Documentation/fb/udlfb.txt]

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.

Page 10 of 16« First...89101112...Last »