Category: Development

  • 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 […]

    Read More
  • November 3, 2017 - Mike Blumenkrantz

    New Features in Enlightenment 22

    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 […]

    Read More
  • 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 […]

    Read More
  • August 2, 2017 - Bryce Harrington

    Better Attachment Handling with Mutt

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

    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: […]

    Read More
  • July 28, 2017 - Shuah Khan

    Kselftest for Linux 4.13 to Include TAP13

    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:

    After: […]

    Read More
  • July 18, 2017 - Bryce Harrington

    Introduction to GPG Encryption and git-crypt

    While Open Source prides itself on open transparency, there are certain things that must be kept secret like team credentials or personal information.  GNU’s OpenPGP (GPG) encryption tool set coupled with git-crypt can be invaluable for sharing such information privately with colleagues. For people unfamiliar with GPG it can seem a bit intimidating to start with, but it needn’t be! This article is a step-by-step introduction to getting set up with your own GPG key. Install GPG Since GPG has become pretty ubiquitous it should be straightforward to install via the usual method for your operating system. debian/ubuntu:

    OSX (using ports):

    etc. Create Your Own GPG Key Easy enough! The following command will ask for the info needed to make the key. Pick RSA with a key length of 4096 bits, and be very careful to set a unique GPG password that you’re not using anywhere else (but pick one you can remember!):

    […]

    Read More
  • July 13, 2017 - Thibault Saunier

    GStreamer to Gain the First RTSP 2.0 Implementation!

    Real Time Stream Protocol 2.0 The RTSP 2.0 was proposed in December 2016 to replace the 1.0 version of the standard; this new version is not backward compatible with the previous one. RTSP 1.0 is almost 20 years old, and it’s done a good job at defining a standard protocol for real time media streaming signaling, but it has not evolved much since then and had some issues that were worth fixing. The new version of this standard aims to resolve inconsistencies, clean up the RFC, add missing definitions, and restructure the document to reach better interoperability between implementers. RTSP 2.0 also comes with a bunch of new features (such as pipelined setup request, to avoid round trip time on initialization) and removes some features that were considered not useful enough (such as the RECORD command). GStreamer’s RSTP 2.0 Implementation At Samsung, we decided it was the right time to […]

    Read More
  • The gst-validate utility allows for the detection of known issues in GStreamer pipelines, and it’s part of the developer tools the GStreamer community offers through the gst-devtols modules. In this guide, I will demonstrate how to create playback scenarios to test a pipeline’s reaction to a new set of controlling actions. There are a couple of common and not-so-common scenarios that are already included with the GStreamer validate suite. This set allows for the identification of known error conditions on a running pipeline subjected to the actions the provided scenarios express. Now, what if you want to inspect the reaction of your pipeline to a new set of actions? Then, you need a new scenario that describes it. What’s in a Scenario? Scenarios are built from serialized actions on a .scenario file. These actions and their parameters are expressed using a GstStructure-based text format, and includes the following core actions: […]

    Read More
  • As you might already know, many open source projects are moving away from autotools as a build system and are embracing Meson. GStreamer was one of the first projects to initiate this move as the community pushed for it to happen. Meson has many advantages over autotools, but one I would like to talk about in this post is the notion of subprojects, which Meson introduces. Basically, thanks to this it’s easy to build several projects as if it was one; GStreamer has many components that were formerly independent in the build system, meaning that if you wanted to build the latest version of, say, gst-plugins-bad, you also needed to build GStreamer core and GStreamer base one way or another. Previously, we had some scripts to help with this process, but it was still necessary to clone and build everything separately and handle interdependency between things manually. Today, things are different when using […]

    Read More
  • Wayland: there have been many blog posts, articles, and news items about the new Linux display protocol. There have been developers working to extend the protocol for new and extremely helpful use cases, but new frontiers continue to be explored: putting a multiseat Wayland compositor into a toolkit widget. Due to Wayland’s philosophy of “build your own compositor,” there is no de-facto implementation of a Wayland display server that is analogous to Xorg for X11. Wayland implementations are written using the libwayland server API, and this is flexible enough to be used even in the case of a widget. Overall, the only noteworthy difference between putting a compositor in a widget and a normal nested compositor is that the output size is set to the size of the widget instead of the size of the window. With this in mind, a compositor widget can be manipulated just like any other […]

    Read More
1 2 3 16