IoTivity 1.3.1 has been released, and with it comes some important new changes. First, you can rebuild packages from sources, with or without my hotfixes patches, as explained recently in this blog post. For ARM users (of ARTIK7), the fastest option is to download precompiled packages as .RPM for fedora-24 from my personal repository, or check ongoing works for other OS. Copy and paste this snippet to install latest IoTivity from my personal repo:
rm -fv "/etc/yum.repos.d/$repo.repo"
wget -O- $url | sudo tee /etc/yum.repos.d/$repo.repo
grep $repo /etc/yum.repos.d/$repo.repo
dnf clean expire-cache
dnf repository-packages "$repo" check-update
dnf repository-packages "$repo" list --showduplicates # list all published versions
dnf repository-packages "$repo" upgrade # if previously installed
dnf repository-packages "$repo" install iotivity-test iotivity-devel # remaining ones
I also want to thank JFrog for proposing bintray service to free and open source software developers. Standalone Apps In a previous blog post, I explained how to run examples that are shipped with the release candidate. You can also try with other existing examples (rpm -ql iotivity-test), but some don’t work properly. In those cases, try the 1.3-rel branch, and if you’re still having problems please report a bug. At this point, you should know […]
The Enlightenment Foundation Libraries have long supported the ability to do output rotation when running under X11 utilizing the XRandR (resize and rotate) extension. This functionality is exposed to the user by way of the Ecore_X library which provides API function calls that can be used to rotate a given output. Wayland While this functionality has been inside EFL for a long time, the ability to rotate an output while running under the Enlightenment Wayland Compositor has not been possible. This is due, in part, to the fact that the Wayland protocol does not provide any form of RandR extension. Normally this would have proved a challenge when implementing output rotation inside the Enlightnement Wayland compositor, however EFL already has the ability to do this. Software-Based Rotation EFL’s Ecore_Evas library, which is used as the base of the Enlightenment Compositor canvas, has the ability to perform software-based rotation. This means […]
Quite some time ago I received a report of a nasty Wayland bug: under certain circumstances a Wayland event was being delivered with an incorrect file descriptor. The reporter dug deeper and determined the root cause of this; it wasn’t good. When a client deletes a Wayland object, there might still be protocol events coming from the compositor destined for it (as a contrived example, I delete my keyboard object because I’m done processing keys for the day, but the user is still typing…). Once the compositor receives the delete request it knows it can’t send any more events, but due to the asynchronous nature of Wayland, there could still be some unprocessed events in the buffer destined for the recently deleted object. The Zombie Scourge This is handled by making the deleted object into a zombie, rather, THE zombie, as there is a singleton zombie object in the client […]
One of the most heinous visual artifacts modern displays are capable of is tearing, on the desktop, there are two major potential sources of this: A compositor redraw during screen refresh – this leads to global artifacts such as application windows breaking up while being repositioned. Applications redrawing while the compositor is reading their content – the contents of a single window will be displayed in an indeterminate state. Under X, application redraws are tricky to do without tearing because content can be updated at any chosen time with no clear feedback as to when the compositor will read it. EFL uses some clever tricks to this end (check out the state of the art X redraw timing for yourself), but it’s difficult to get right in all cases. For a lot of people this just works, or they’re not sensitive to the issue when it doesn’t. Wayland Does Application […]
The USB over IP kernel driver allows a server system to export its USB devices to a client system over an IP network via USB over IP protocol. Exportable USB devices include physical devices and software entities that are created on the server using the USB gadget sub-system. This article will cover a major bug related to USB over IP in the Linux kernel that was recently uncovered; it created some significant security issues but was resolved with help from the kernel community. The Basics of the USB Over IP Protocol There are two USB over IP server kernel modules: usbip-host (stub driver): A stub USB device driver that can be bound to physical USB devices to export them over the network. usbip-vudc: A virtual USB Device Controller that exports a USB device created with the USB Gadget Subsystem. There is one USB over IP client kernel module: usbip-vhci: A […]
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:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
The kernel’s COPYING file produces two practical effects: User-space applications can use non-GPL […]
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 […]