Endurance Technology Contributions
Posted on 28. May, 2010 by Bernie Thompson in udlfb
Endurance Technology, a software consulting company in the UK who has done previous work on DisplayLink devices, has contributed back a branch of work done on the Fall 2009-era DisplayLink kernel framebuffer (udlfb) and X driver (xf86-video-displaylink).
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.
SparkFun: Corporate Hero
Posted on 26. Mar, 2010 by Bernie Thompson in Other
If there’s a corporate recipe for Plugable Technologies, it’s taking a blend of Linksys, Belkin, Kensington, and mixing in a heavy dose of a secret ingredient: SparkFun.
SparkFun is a true corporate hero – bootstrapping from zero, innovating fundamentally, serving customers fanatically, thinking differently, building locally, selling internationally, staying lean, and growing and succeeding organically.
Nathan Seidle is the founder and CEO of SparkFun, and he’s giving a talk at MIT in a few days. Hopefully some video will make it online for those of us not in Boston. But you can get a flavor of it from Nathan’s recent visit to Vancouver, BC, which is in our backyard.
If you’re interested in starting a business with $0 of investment capital, building a profitable company around open-source technology, designing electronics for manufacturability, or getting your favorite part sold on SparkFun, come join the discussion!
This talk will describe how SparkFun grew from a one man operation, run out of an electrical engineering student’s undergraduate dorm room, into one of the largest companies in Colorado, and along the way enabled engineers, designers, students and hobbyists to build new kinds of electronics. The talk will walk through pitfalls and triumphs, and discuss the creative, technical, and social philosophies underlying the company.
Nathan Seidle is CEO of SparkFun Inc. in Boulder, Colorado, a company he founded in 2003 as an undergraduate student in electrical engineering. The company, which has grown to over 80 employees, provides tools, hardware, and other resources for artists, engineers, prototypers, and hobbyists to “play with cool electronic gadgetry”. He is an accomplished engineer, innovator, and bootstrapping entrepreneur.
Details at SparkFun Visit and Talk at MIT
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?
Recent Comments