Preparing more udlfb patches for linux-next
Posted on 12. Feb, 2010 by Bernie Thompson in UGA-2K-A
There are limits on how much a small device company can and should do in contributing to open source driver support. But with a historical connection to DisplayLink and more products coming with the technology included, contributing what we can to the generic DisplayLink driver on Linux makes some sense.
Also note this driver is just a foundation on which other stuff (like X) sits, so it doesn’t mean Linux is easy for real end users yet. But it’s getting closer.
Here’s the announce that went to the list today:
The next patch series for udlfb is “nearly ready” for submission, hopefully will be coming in the next few days.
Testing and any problem reports would be helpful. The code that will be submitted is at http://git.plugable.com/gitphp/index.php?p=udlfb&a=summary
There are many dozens of checkins in git as inter-related problems have been explored and the code incrementally improved. Before submitting, I’ll be reconstituting them into a smaller number of more analyzable email patches: make everything checkpatch.pl clean, reorganize things to match final layout, then per-feature patches. We’ll see how that goes.
Major features:
* Support for standard fbdev clients (via defio)
* Improved performance (about 20% average improvement over a variety of “benchmarks” like x11perf, gtkperf, glxgears)
* Asynchronous urb dispatch and no mutexes held for extended periods during render
* Slightly lower CPU consumption, less touching memory, slightly higher average compression
* Better handling of switching from X to fbcon VTs and back
* Driver should unload cleanly from either bottom-up (USB removal) or top-down (shutdown). Problem reports welcome.
* Performance metrics reported through sysfs (read /sys/class/graphics/fbX/*metrics*)
* EDID reported through sysfs (read /sys/class/graphics/graphics/fbX/edid)
* Can compile as module with or without defio or sys_ dependencies
* Lots of cleanup – tested on 64-bit, closer to endian clean, checkpatch.pl clean
What it does not have:
* The defio rendering problems (e.g. with xf86-video-fbdev X server) are still unsolved
* Still 16bpp only. Pseudo-truecolor 32->16 is on the wishlist.
* No DL 1×5 SKU detection yet (you’ll get a blank screen if your monitor’s res exceeds the adapter)
Linux kernel framebuffer rendering APIs
Posted on 30. Jan, 2010 by Bernie Thompson in udlfb
The Linux framebuffer interface has at least four different sets of APIs for rendering to the screen. Here they are mapped against the some important fbdev client “applications”.
| Description | Linux console | fbdev X server | mplayer, fbi, some others | ||
|---|---|---|---|---|---|
| fb_write and fb_read | passes a buffer to copy to/from user | no | no | no | |
| image_blit, fillrect, copyarea | blit passes buffer to copy | yes | no | no | |
| mmap | assuming writes go directly to device | no | yes | yes | |
| mmap | with extra ioctl to report damage | no | no | no |
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?
9 USB displays illuminate energy security
Posted on 26. Jan, 2010 by Bernie Thompson in udlfb
Here’s a great application for USB displays.
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.
Recent Comments