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

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?

Ten years ago we were at the end of the “computer on every desk and in every home” era. The iPhone had begun moving computing off the desk and into the pocket. The most important application was the web browser for content, but operating systems still mattered for running applications.

Ten years later, we’re simply reaching the conclusions of some of those trends–the web browser is where nearly all applications live. An explosion of devices and user interface types running over invisible operating systems have emerged to make those applications accessible in different ways, more transparently integrated with our lives.

We’ve learned to live with the risks and benefits of keeping our data in the cloud, so any display anywhere–with touchscreen, keyboard/mouse, or voice for input–is our own personal computer.

The average family has a display in our kitchen. Continuous voice recognition is again a challenge for the next decade, but discrete voice recognition is ubiquitous. An idle mention of “weather” in a kitchen conversation triggers the display on the wall to show the forecast for coming days.

The phone in our pocket is also a primary computing device. We dock it at our desk to gain a large display, keyboard, mouse, speakers, etc. But all that is stateless. When we unplug and go, we have everything — again, most of which is in the cloud anyway.

A picture is worth a thousand words, and we have access to a lot of pictures.

Displays are everywhere, especially in our urban settings, perhaps overwhelmingly so. Whether signage for a particular store, a billboard, or a public terminal, they’re showing active, context-aware content.

At work, multiple displays are the norm for information workers. Any remaining conference rooms without multiple displays, multiple web cams, and smart integration between them are frustratingly crippled.

And all these displays and terminals are being driven by far fewer “computers”–often just one per house or room, or increasingly one off in a server farm. Perhaps the greatest innovation of the past decade has been a subtle one–we spend less time keeping our computers working, as we have fewer of them. We’ve pushed more of the complexity to fixed-function devices, online services, and computers that are remotely maintained.

Even as our computers have become even more essential to driving our great strides in genetics, materials, collaborative creativity, etc., computing has begun to disappear into the background of our consciousness. More ubiquitous, but explicitly on the mind less often.

And still, the more things change the more they stay the same. The singularity is always a few decades away, and so it is again for the decade ahead.

Wow, weird. What is this?  My birthday isn’t this month – must be work related.

Here I am just in the earliest stages of getting things going with Plugable, having just finished at DisplayLink last month – and still feeling guilty about all I chose to leave behind.

The return address is San Diego.   Yesterday, I had some first calls with my ODM contacts about getting devices produced – boy, if this is them, they are crazy and eager.  Doubt it.

I carry it to the kitchen, and Laurie and I huddle around it, making guesses as we open it.  It’s packed in ice for overnight delivery.  No hint yet who it’s from.

And in the middle is a wonderful chocolate cake, with a card.

Good luck in the future, Bernie
With very best wishes from
your friends in Cambridge

Wow.  That’s so cool.  Kind, generous, and surprising.  And very touching to have anyone spend the time to do that.

Karma is real, not in a mystical way, but practically.  This is a surprisingly big world, and yet also a surprisingly small one. We will meet again.  And people notice how others are treated.

So to my friends in Cambridge – you’re wonderful!  So long, and thanks for all the cake¹ (and may the hyperspacial express route not cross your path).

Please don’t be shy to call or email anytime.

Cheers,
Bernie