The Italian city of Florence is home to the Uffizi Gallery, one of the most famous art museums in the world, with a particular emphasis on Renaissance art, including my favorite event in all of art history: the discovery of perspective. Today we’re so surrounded by artwork that uses perspective that we hardly notice it. In fact, it’s the *non-*perspective art that looks weird to us today, but prior to the 1400’s it simply didn’t exist. Drawing and painting differ from other art forms like sculpture, architecture, or theater, in that they represent life and the world via a flat two-dimensional surface. With sculpture, artists essentially make a 3D copy of a physical object measured in three dimensions; with a drawing or painting, you’re challenged with flattening reality down to just two. Indeed, the earliest artists resorted to just showing front or profile views of their subject. Sometimes depth is […]

A while back, I landed a change to update Cairo’s GL backend to support OpenGL ES version 3.0. In this blog post I’ll describe what this is, what makes it important, and what future steps can be taken. What is Cairo? Cairo is a drawing library that provides high quality 2D rendering of vector graphics. It’s claim to fame is a focus on making what you see on the screen identical to what gets printed on the printer. It’s raison d’être is to create SVG and PDF files with fancy graphics and nicely anti-aliased text. Cairo provides a stable, well-tested, well-documented API for applications to build against; historically, the list of applications and products using Cairo is impressively long. Rendering performance is also important to Cairo, which it addresses by making provisions for ‘rendering backends.’ The backends tap into platform-specific underlying 2D graphics systems as output targets; the win32 backend […]

The licensing text in the Linux kernel source files is inconsistent in verbiage and format. Typically, in each of its ~100k files there is a license text that describes which license applies to each specific file. While all licenses are GPLv2 compatible, properly identifying the licenses that are applicable to a specific file is very hard. To address this problem, a group of developers recently embarked on a mission to use SPDX® to research and map these inconsistencies in the licensing text. As a result of this 10 month long effort, the Linux 4.14 release includes changes to make the licensing text consistent across the kernel source files and modules. Linux Kernel License As stated on its COPYING file, the Linux kernel’s default license is GPLv2, with an exception that grants additional rights to the kernel users:

There are several options to build IoTivity for ARM targets or any non x86 hardware, but first you have to decide which operating system you want to use. In this article, I won’t compare OS or devices; instead, I’ll give a couple of hints that apply to ARTIK 5, 7, and 10 devices (not the ARTIK 0 family, which run TizenRT). These steps can also be applied to other single board computers like the Raspberry PI. Build for Tizen with GBS The first and easiest way to build IoTivity is for Tizen, using GBS. This process was explained in a previous article on this blog: An Introduction to Tizen Development on ARTIK For your knowledge, GBS was inspired by Debian’s git-build-package and uses an ARM toolchain that runs in a chrooted ARM environment using QEMU. Both ARTIK boards and the Raspberry Pi are used as Tizen reference platforms. Build for […]

When debugging kernel problems that aren’t obvious, it’s necessary to understand the history of changes to the source files. For example, a race condition that results in a lockdep warning might have tentacles into multiple code paths. This requires us to examine and understand not only the changes made, but also why they were made. Individual patch commit logs are the best source of the information on why a change was made. So how do we find this information? My goto tool set for such endeavors has been a combination of git gui and git log. Recently I started using cregit. I will go over these options in this blog. git log Running git log on a source file will show all the commits for that file, then you can find the corresponding code change by generating the patch. Using git log can be tedious, but useful for targeted commit […]

The E22 development cycle has been underway for over a year, and it has included over 1,500 patches to address nearly 200 tickets on our issue tracker. With this has come a number of new features and improvements. Greatly Improved Wayland Support The majority of development for this cycle has gone towards improving Wayland support. This covers, but is not limited to: adding support for xdg-shell v6, pointer constraints, and relative pointer motion protocols. These additions improve XWayland support and increase stability across all components running under Wayland. Continued Improvements to New Gadget Infrastructure As previous posts have indicated, a lot of work is being done in this area. The goal is to create a more robust infrastructure with a simpler and more intuitive EFL-based API, moving away from the legacy “gadcon” interface, which has its own API and currently only functions due to mountains of gadget-specific workarounds that make […]

In the upcoming Linux 4.14-rc3 release, work continues to develop the Kselftest TAP13 framework API and convert tests to TAP13. The new tests include Kselftest common RUN_TESTS in lib.mk that have been enhanced to print TAP13 to cover test shell scripts that won’t be able to use the Kselftest TAP13 API; this also covers test programs that aren’t converted yet. Several fixes have been made to existing tests to prevent failure in unsupported cases as part of an ongoing work based on feedback from Kselftest stable release users that don’t want the tests to fail due to unmet dependencies, such as config options being disabled. Additionally, a new watchdog test has been added and much needed cleanups to the existing watchdog tests have been made by Eugeniu Rosca. A New Kselftest Use-Case A notable change in this release is new support for the “make O=dir kselftest” use-case. Several developers rely on this […]

The new gadget API and infrastructure for Enlightenment continue to undergo heavy development. In addition to improving and extending the base gadget UI, work has recently begun on creating a gadget provider with the new API to provide sandboxing and allow gadgets to be written as regular applications that don’t have or require access to compositor internals. The primary enabler of the new sandboxing system is the efl-wl compositor widget. This allows the compositor to launch applications in isolation, and also provides the ability to add protocol extensions for only that specific instance of the compositor widget. Using these features, it becomes possible to add gadget-specific protocols and utilities on the compositor side that are passed through transparently to the client gadget application. Currently, there is one base protocol in use: the e-gadget protocol, which looks like this:

The Mutt email client is famed for its extensive configuration options, but since it’s text-based, certain things are more challenging to do when compared to its graphical brethren. Viewing attachments is one such annoyance; fortunately, as with most things, Mutt is extensively configurable! By default, Mutt does fine with most plain text documents, and depending on your installation may also handle HTML documents in some fashion. Attachments that Mutt doesn’t recognize can of course be downloaded and viewed manually, but we can do better. To tell Mutt that it should handle a new attachment type, or its “MIME type”, we associate it with Mutt’s “auto_view” parameter. For example, add this to your ~/.muttrc (and restart Mutt):

1

2

3

4

5

6

7

auto_view application/zip

auto_view text/x-patch

auto_view text/x-diff

auto_view application/pgp-signature

auto_view application/pgp

auto_view text/html

auto_view text/calendar

Note: if you plan to add a number of file types, you may wish to put these in their own config file (e.g. ~/.mutt/auto-views), and include a line in ~/.muttrc like the following: […]

Linux 4.13-rc1 was released on July 15th 2017 and it includes enhancements to the Kselftest framework to support The Test Anything Protocol v13 (TAP13). TAP13 defines a human friendly output format for tests. Kselftest is run in test rings and is widely used for Linux kernel stable release regression testing. It’s important to make it easier to identify run-to-run differences; TAP13 adaption makes it easier to understand the test results, and helps pin point differences between one run to another run of the test suite. Credit goes to Tim Bird for recommending TAP13 as a suitable format, and to Greg KH for kick starting the work with help from Paul Elder and Alice Ferrazzi. The first phase of the TAP13 conversion is included in Linux 4.13. Future releases will include updates to rest of the tests. The following shows membarrier test results before and after TAP 13 conversion: Before:

Links

Samsung OSG

Samsung Electronics realizes that open source software is a key component of many of our products. The Open Source Group was formed in 2013 to help guide the company in effective consumption, collaboration and creation of open source, provide a method to advocate for Samsung in external open source communities, and develop consistent strategy and governance policies for the enterprise.