At one time, the BSDs and Linux shared a fair amount of graphics code, in the form of direct rendering manager (DRM) drivers. There was a common core that could be used by both Linux and various BSD flavors, along with operating-system-specific parts, all housed in the same tree. That changed in 2008, when the DRM tree moved into the Linux kernel tree; that move was done to rationalize DRM development, but had the side effect of cutting the BSDs adrift to some extent. Representatives from three of the BSDs came to the X.Org Developers Conference (XDC) to talk about where things stand with DRM drivers for their flavor.

FreeBSD

First up was Jean-Sébastien Pédron, who described the state of the FreeBSD graphics stack. After the DRM drivers moved into the Linux kernel, kernel mode setting (KMS) became mandatory, which added more changes to the drivers. In addition, over time newer hardware was only supported by the Linux drivers—at least for Intel and, later, AMD. NVIDIA provides a binary driver for FreeBSD, but Intel and AMD do not target any of the BSDs with their open-source drivers. FreeBSD did not participate in the development of those drivers since they are essentially Linux-only.

In 2012, the Intel i915 KMS driver from the 3.2 (or, possibly, 3.4) Linux kernel was imported into FreeBSD. As part of that, the developers made a copy of the old DRM code into a new drm2 directory in the FreeBSD kernel tree. Features that were required to support the i915 hardware were added to the DRM device-independent code. The use of Linux-specific APIs and data structures was converted to use FreeBSD equivalents. That driver was available in FreeBSD 9.1.

Similarly, the AMD Radeon KMS driver from Linux 3.8 was imported into FreeBSD's tree, along with the Translation Table Maps (TTM) memory-management layer for DRM. Pédron, who did the port, made some additions to the DRM device-independent code and changed Linux-isms to their FreeBSD counterparts. That was released as part of FreeBSD 9.3.

Those two drivers suffered from a number of problems, the biggest of which was the "gratuitous changes all over the place", he said. The use of FreeBSD APIs and data structures, variable renaming, and an incomplete implementation of DRM all make it difficult to import new code from the Linux drivers.

Recently, he has been working on updating the i915 code. That work is close to completion. He has also synchronized the device-independent DRM code with the version in Linux 3.8. In the longer term, he plans to use a Linux API wrapper to make it easier to bring changes over from Linux, but he will need to convince the other FreeBSD developers in order to do so. He would also like to get rid of the code duplication by merging the drm and drm2 source trees.

That was the major problem with graphics in the FreeBSD kernel, Pédron said, but there is a second problem: it lives in the ports tree that is used to package third party applications for the distribution. The ports tree is a repository of makefiles and patches that can be built and installed with a single make command, though there are higher-level tools available as well. One of the great features of the ports tree is that all of the packages can be installed for any version of FreeBSD that is still being supported, he said. So older FreeBSD versions still have access to recent versions of applications. But there is a downside to that: the package needs to be able to handle missing features in earlier releases.

The differences in the driver support for FreeBSD releases has led to problems in the ports tree. New X server and Mesa versions require certain i915 and Radeon driver versions, but the ports tree is not set up to handle those kinds of dependencies. A hack was made using a build-time flag in the tree, WITH_NEW_XORG , to build the more recent versions of the graphics stack.

That hack caused a number of problems; it was a "nightmare" to maintain and test, and was confusing for users. That led to fewer updates in the graphics stack to try to reduce the complexity. It also caused unrelated packages (the X server and Mesa) to be upgraded in lockstep, which should have been unnecessary. It was, in short, a "fiasco", he said.

Recently, a problem cropped up with version 1.12 of the cairo graphics library and the older Intel driver that would crash the X server. That, it appears, was the straw that broke the camel's back; the older graphics stack has been dropped from FreeBSD. It took a lot of work to convince the developers to do so, however.

The FreeBSD graphics team is small, with just two kernel and two ports developers, not all of whom are fully dedicated to graphics work. There is a lack of X11 expertise and of understanding of the graphics stack, Pédron said. Users are scared of graphics updates, as are the developers. Those updates tend to be "large and tricky", jumping over multiple versions, rather than smaller, incremental changes. Another problem is that many FreeBSD developers do not use the graphics stack for their development systems; they often use Mac OS X instead.

There has been little effort to work with the X community, but Pédron and others are trying to change that. There is an effort to participate more on the mailing lists, for example. His XDC talk is another attempt to reach out to the community. The wiki page on the graphics stack is the best place for those interested to see where things stand. A quarterly report of progress and plans for FreeBSD graphics will also be published.

In the future, there are plans to sync the FreeBSD drivers with those in a more recent Linux kernel (3.10 perhaps). As time allows, he would like to work on adding DMA-buf support as well as working on udev and an alternative to systemd-logind to be able to run X as a non-root user. Wayland is in the plans as well. He finished by noting that the FreeBSD graphics developers wanted to work more closely with X.Org in the future, which was an idea that seemed to be well-received by those in attendance.

DragonFly BSD

Up next was François Tigeot from the DragonFly BSD project. He has worked on the project since 2011. DragonFly was forked from FreeBSD in 2003 and aims to be "high performance and scalable".

The first "tentative" effort at porting the Linux DRM/KMS drivers to DragonFly was a Google Summer of Code (GSoC) project in 2010. The project was not well managed, but the student eventually got something to work using a Linux compatibility layer. Tigeot was never able to reproduce the results and suspects it only worked on the student's hardware.

So, in 2012, he started working on porting the i915 driver from FreeBSD, which shares some kernel APIs with DragonFly. By the end of 2012 it was mostly ported, but it took until mid-2013 to actually get it working. It required some cache management changes to the DragonFly kernel. After that, he switched to porting the Radeon driver and TTM layer, which was mostly ported by October 2013. By July 2014 the Radeon driver was working reliably, he said.

FreeBSD dropped the ball, though, Tigeot said, and there were no significant updates to the i915 driver after 2012. The latest supported hardware was Ivy Bridge. He started rebasing on the Linux i915 driver in September 2013 with a goal of providing Haswell support for DragonFly.

He chose the Linux 3.8.13 i915 driver as the basis for his work. 3.8 has the first known working Haswell support in Linux, but there were other reasons to choose that version. The Radeon port was based on 3.8, as was OpenBSD's Intel driver. Since OpenBSD has the best DRM implementation of the BSD family, using the same version made sense, he said.

There are a number of problems with the FreeBSD i915 driver, including having two DRM directories (as Pédron mentioned) with most of the code duplicated between them. In addition, the FreeBSD developers rewrote the entire driver to conform to FreeBSD's coding style, which resulted in lots of white space differences. Functions were renamed and moved around, file names were changed, and so on. He cleaned a lot of that up, reducing the diff size from 50K lines of code to 22K.

Much like the GSoC student's approach, Tigeot chose to use a Linux compatibility layer. Many of the linux/*.h header files were taken from the FreeBSD InfiniBand stack, which also has a Linux compatibility layer. Some APIs were taken from OpenBSD and others were implemented specifically for DragonFly.

Graphics drivers are a complex and fast-moving target, so it makes more sense to just use the Linux APIs. In a way, he said, he was porting DragonFly to the DRM drivers, rather than porting the drivers to the OS. There is not enough developer time to do otherwise. The major exception is for locking primitives, which are best converted to the DragonFly equivalents.

There were a number of trouble spots, including the Graphics Execution Manager (GEM) layer, which is quite different in the FreeBSD driver vs. Linux. By August of this year, he had the driver working reliably on Haswell hardware.

On the user-space side, DragonFly switched to using the FreeBSD ports tree (with an adaption layer) in 2013. It is "much better" than the previous package management system and brings more up-to-date code with it (e.g. X server 1.12). Unfortunately, the FreeBSD ports tree is beginning to lag a bit. It took years to go from cairo 1.10 to 1.12, for example.

The current state is that the i915 driver is mostly in sync with the Linux 3.8.13 version, except for the GEM code. It is "functionally equivalent to Linux on most paths", Tigeot said. In addition, the Radeon DRM driver is mostly in sync with Linux 3.8 and TTM with Linux 3.9. The generic DRM code is "a mess", with a few parts up to 3.8.13 and other parts much older (< 2.6.26).

Future plans are to bring the generic DRM code up to Linux 3.8, then to start upgrading both DRM and drivers to more recent versions. With TTM working properly, Nouveau could be ported to DragonFly fairly easily as well. Either restoring text mode or adding a graphical TTY layer is another task that needs some work; currently exiting the X server goes to a blank screen or frozen image. In answer to a question from the audience, Tigeot said that he did not have any benchmarks of the drivers, but that the performance was not a problem for day-to-day use.

OpenBSD

The final *BSD representative was Matthieu Herrb, who gave a presentation about the status of the OpenBSD graphics stack. OpenBSD split off from NetBSD (which was the only major BSD variant not represented at XDC) in 1996. One of its claims to fame is its support for many different architectures including some that are not particularly mainstream any more (VAX and Sequent, for example).

OpenBSD already supports bitmap consoles, which makes it easier for it to adopt KMS, he said. Another difference for the project is that it includes X as part of the base system, rather than in its ports tree, which means that it is more closely integrated with the kernel and the rest of the system. Like the other BSD variants, OpenBSD has a ports tree for third party software like GNOME, KDE, Firefox, LibreOffice, and so on.

Herrb last gave a status report at FOSDEM in early 2013, so this talk was an update since then. Most of the user-space components are more recent versions than those used by the other BSDs (e.g. Mesa 10.2.7, X server 1.16.1, etc.), though the DRM/KMS drivers for Intel and Radeon are also based on the Linux 3.8 versions. One downside to importing Linux code is that it won't be reviewed by OpenBSD kernel developers because they won't read code that does not conform to the BSD coding style.

The OpenBSD graphics stack (aka Xenocara) has more features than other systems, he said, including support for graphics on non-x86 architectures. The wscons console driver is integrated with KMS. It has hotplug support for input devices, though there is no keyboard support in the wscons X driver (xf86-input-ws). The X server runs with privilege separation, so the main server does not run with privileges and there is no aperture driver for KMS. OpenBSD uses the CWM window manager, which only uses BSD-licensed libraries; that requirement rules out most other window managers.

There are a number of "missing parts". OpenBSD is planning to switch away from GCC for building the base system, but that has not yet happened, so there is no LLVM package available. That means there is no support for Gallium software rendering. Even when the base system gets LLVM, it will be an older version, while Mesa uses the most recent, so there may need to be two versions supported.

Thread local storage (TLS) is not supported in the GLX driver and there are some issues with futexes and shared-memory fences (xshmfence) that need to be resolved. There is no support for multi-touch, yet, nor any Nouveau support. The latter should be easier since TTM support was added for the Radeon driver.

All of those things are on the radar for future work, as is updating to later versions of the Linux drivers, which "should not be too hard", Herrb said. Moving the input drivers to be more similar to the Linux evdev model is also planned at some point.

He noted a few difficulties, including that some of the KMS drivers are GPL-licensed. There is also a perception in the BSD community that Linux is slowly drifting away from the traditional Unix model with projects like systemd and Wayland. That scares some BSD users, he said. Lastly, there is a lack of developer time to work on these projects.

The latter seems to be a common concern among the three presenters. Graphics is a complex area that requires a lot of developer time to keep up with new hardware support, but the BSDs are fairly small projects—and there are at least four of them. The tone in the room suggested that the X developers are willing to help, to the extent they can, but that there are a number of political, social, licensing, and technical hurdles that only the BSD projects themselves can surmount.

[ I would like to thank the X.Org Foundation for travel assistance to Bordeaux for XDC. ]

Comments (29 posted)

The open-source development model is easily adaptable for a variety of use cases and needs, from servers used by Fortune 500 companies to laptops used by people in the developing world. Inspired by this adaptability, one project, WikiHouse, uses collaborative open-source development to change the way people build and design housing.

In the project's own words, "WikiHouse is an open source construction set. The aim is to allow anyone to design, download, and 'print' CNC-milled houses and components, which can be assembled with minimal formal skill or training". "CNC-milled" here refers to the use of Computer Numerical Control mills; that is, machines which can cut materials based on programmed instructions. The project recently built WikiHouse 4.0, constructing it in a few days outside The Building Centre in central London for the 2014 London Design Festival.

WikiHouse was founded by Alastair Parvin in 2011. He is a graduate of architecture studies from the University of Sheffield and was disillusioned with the status quo of architecture: in its design principles and its overall economic state. In a 2013 speech at TED, he noted that the majority of buildings in England were made by only a few companies. Because architects are largely concerned with profitability and treat citizens largely as consumers, they tend to favor building huge condominiums or cookie-cutter suburbs. According to Parvin, this approach to housing doesn't work for everyone; indeed, the cost of living in those types of buildings is high. Meanwhile, around the developing world, one can find badly-built shantytowns constructed by local residents out of necessity.

As Parvin sees it, the best team in the world to tackle this issue is ordinary citizens acting locally. Instead of having a professional class decide how houses should be built, with all the social and political baggage attached to it (e.g. how we expect people to live with and relate to each other), the technology is now available for individuals to build their own homes. And they have the means to build them on their terms and on their budget. This is all thanks to plywood, CNC mills, and an open-source development model. All that's needed is to ensure that the construction complies with local laws and restrictions, such as zoning.

WikiHouse, which is a non-profit, offers a variety of open-licensed resources. On its library page, one can find a large number of housing components that can be made by a CNC machine. These designs are all dedicated to the public domain under Creative Commons Zero Public Domain Dedication.

The project currently relies on the proprietary SketchUp software for interacting with CNC mills, although the project uses its own open-source plugin to do so. Although there has been discussion in the past on moving away from SketchUp, there was no response from the project to an email asking if a reliance on proprietary software was considered a "bug".

The design library showcases contributions by several individuals. These models include joints, stand-alone sections of houses, ladders, and a few prototype buildings, including a shed, a pavilion, and houses. WikiHouse chapters in Brazil and New Zealand continue to work on designs and construction. A recent blog post by the New Zealand chapter describes a recent collaboration with local citizens to design a "self-reliant backyard micro-house".

Although I had no CNC machine to test out the project's designs, recent press about the project reveals how much it has already accomplished. WikiHouse 4.0, built in September, was "the world's first low-energy, two storey house that anyone can download, adapt, 'print' and assemble for themselves in a few days, with no construction skills and for under £50k." The YouTube time-lapse video of the construction of WikiHouse 4.0 shows the interesting implications of this project. One could imagine affordable CNC-milled houses being built in the West; further optimizations and cost-reductions could make them a practical option in poorer countries.

The project relies on local interest in its target communities, though WikiHouse aims to reach globally. At his TED talk last year, Parvin showed a map reflecting WikiHouse chapters around the world. There are chapters in England, Brazil, Haiti, South Korea, and New Zealand. Since that talk, other chapters have sprung up, including one in the Netherlands and another in Portugal. Those interested in starting a chapter with a formal affiliation to WikiHouse can do so as long as they consent to a fairly liberal trademark agreement. The agreement stipulates, among other things, that chapters will dedicate their designs to the public domain, and that they "will not use WikiHouse to mass produce houses whose primary function is as a speculative real-estate asset, rather than as a place to live".

WikiHouse has active Twitter accounts and a Facebook page for communicating with the general public. For designers and developers, there a is GitHub repo, as well as three Google Groups: one for discussion of the project itself, another for discussion of open hardware for housing construction, and the third for discussion of open source software for construction.

With WikiHouse 4.0 successfully completed, chapters springing up around the world, and a charismatic founder continuing to give public presentations about transforming the way we build houses, WikiHouse seems to have a bright future ahead of it. While the next house you live in might not be made by a CNC mill, it may be an increasingly popular option in the years to come, and an increasing necessity in the developing world.

Comments (5 posted)

Rob Landley recently released version 0.5 of Toybox, his minimalist Linux command-line utility tool. Toybox is frequently described as a "BusyBox replacement," and its history places it in the middle of a number of ongoing, often contentious debates—from GPL-versus-BSD license arguments to disputes between Linux kernel developers and the Free Software Foundation (FSF). Despite such controversies, the project has continued to soldier on, with this new release implementing multiple new commands and other improvements.

New toys

Toybox, like BusyBox and other similar efforts, is an attempt to reimplement the core functionality of basic command-line Unix programs in a single executable. Filesystem and file-management tools like grep , tar , and mount are the most common examples, but the included tools frequently incorporate user-space process management, network utilities, and text manipulation as well. Not every option of the original programs may be implemented; the goal is to provide those functions necessary for general-purpose maintenance and administrative tasks (especially those features expected by utility scripts) in a compact form suitable for embedded systems.

Landley started Toybox in 2006 under the GPLv2 license, but development tapered off. He relaunched the project in late 2011 under a two-clause BSD license, with the stated goal of making Toybox a replacement for Android's Toolbox multi-function utility. A steady series of releases has continued over the subsequent years, with Toybox adding support for more and more basic CLI tools. In mid-2013, Toybox releases started separating commands into two categories: fully supported and pending. Users could configure support for pending commands at build time if they wished to get a taste of up-and-coming (if perhaps less stable) new features.

The 0.5 release includes 150 supported commands, with another 59 in the pending category. New in this release are factor , find , install , and mount ; in addition, the blockdev , inotifyd , and lspci commands graduated from pending to supported status. Quite a few additions were also made to the pending category, including several more-or-less standard programs like fsck , plus some more unusual offerings like mix , which adjusts sound volume through the Open Sound System (OSS) API.

There are also some changes in the build system incorporated in the new release. Builds now automatically take advantage of multi-processor systems, and there is broader support for the option to build commands as standalone binary executables. Not every supported command can be built standalone, however: chown , egrep , fgrep , fstype , halt , mv , nc , poweroff , unix2dos , and whoami are known not to work.

It is also interesting to measure Toybox's status against the utilities it seeks to replace. While BusyBox primarily focuses on implementing the GNU utilities, Toybox actively tracks its progress against several different command collections: the POSIX 2008 specification, the Linux Standard Base, and (as mentioned earlier) Android's Toolbox. There are still quite a few to-do list entries under the Toolbox category (around 30 at the moment), but that number can be misleading if taken out of context. Toolbox, after all, also implements a large number of features also addressed in POSIX and other collections.

Still, it does seem like those looking for a drop-in Toolbox replacement will have a bit more waiting ahead of them. One of the stated goals of the project is to reimplement Toolbox's functionality, but in a manner that avoids duplication of effort and integrates better with the other utilities.

As one would expect, the new release also incorporates a number of important bugfixes and improves on the included test suite.

Getting busy

Naturally, though, regardless of the program's feature set, for quite a few people the principal distinction of Toybox remains its license. Prior to starting Toybox, Landley was the BusyBox maintainer; he departed in 2006 with a public expression of his frustration with (among other things) the fact that BusyBox was frequently the focus of GPL enforcement actions—particularly in the embedded-product space. Landley was a plaintiff in several of the early actions, though, which may have contributed to others' negative reaction to the news that he no longer supported more recent enforcement actions.

Toybox's initial license was the GPLv2—which, of course, would likely have had the same effect in attracting enforcement actions as BusyBox if used in an embedded product. But the 2011 relaunch changed the equation; if Toybox was able to serve as a BSD-licensed drop-in replacement for BusyBox, then a manufacturer might adopt it in hopes of avoiding a GPL enforcement action. In 2012, Sony developer Tim Bird proposed just that, calling for the creation of a permissively licensed BusyBox replacement on the eLinux wiki, with Toybox as the recommended starting point.

Bird's proposal drew harsh criticism from (among others) Matthew Garrett, who called for kernel developers interested in GPL enforcement of the kernel itself to get in touch with the Software Freedom Conservancy (SFC) and offer their assistance. In the ensuing discussion, Garrett clarified this position somewhat. His argument was that BusyBox infringement suits were primarily used as an means to obtaining full GPL compliance from projects that were also violating the Linux kernel's licensing.

Thus, he said, a BusyBox replacement was of interest primarily to embedded device makers who do not wish to comply with the GPL's requirements on kernel code. These manufacturers' additions to BusyBox were minimal at best, but by skirting GPL compliance on the kernel, they were keeping important hardware-enablement information from the community.

And, indeed, it was precisely this chain of recurring events that bothered Landley so much as BusyBox maintainer. In his view, the SFC, FSF, and others who used BusyBox compliance as a means to enforce GPL compliance of non-BusyBox code were overstepping their authority.

A brief read-through of the comments on Garrett's blog post or of the discussion thread on our own news item will probably make it clear that neither side of this debate finds much common ground with the other, and is not likely to change positions any time soon. Thus, for the foreseeable future, Toybox and BusyBox seem likely to exist as competitors in the marketplace.

Landley's goal of replacing Android's Toolbox is a difficult one to handicap, but there are certainly other embedded Linux projects keen on adopting Toybox. As recently as October 1, for example, Intel's Xavier Roche expressed "deep interest" in using Toybox in Tizen. Notably, Roche's message did not cite the licensing difference as the reason for his interest in Toybox—but it is clearly a selling point in many quarters.

Comments (1 posted)