19 Aug 2018

feedPlanet KDE

KStars v2.9.8 released

KStars 2.9.8 is released for Windows, MacOS, and Linux. It is a hotfix release that contains bug fixes and stability improvements over the last release.

This marks the last release of the 2.x series, the next KStars release shall be v3.0.0

+ Eric Dejouhanet fixed several issues in the Ekos scheduler to enable running duplicate jobs.
+ Pino Toscano fixed many problematic i18n strings that accumulated over the years.
+ Csaba Kertesz improved KStars Lite android build process and fixed touch support.
+ Andy Galasso fixed several issues with Ekos PHD2 support.
+ Wolfgang Reissenberger fixed logging out in capture module.
+ Yuri Chornoivan fixed minor EBN issues.
+ Using Max RMS value as the threshold to abort the guider instead of maximum pulse length.

19 Aug 2018 11:16am GMT

KDE Itinerary - How did we get here?

At Akademy I've presented the current state of KDE Itinerary. Due to popular demand and since 25 minutes aren't a whole lot of time I'll try to write a few posts on this subject here too, beginning with how this all started.

When travelling regularly you probably have come across or are using the digital travel assistant features found on Android or iOS, or dedicated services for this like TripIt. Getting a unified itinerary rather than digging through ad-infested HTML emails for your departure gate, having a single place to look for your boarding pass rather than two dozen vendor apps and getting up to date information about changes to your trip are all very useful and convenient.

Most of this is available "for free", that is you pay with your data rather than your money. In the extreme case (Google), you have those providers reading your entire email in order to extract your travel information. But even if you restrict this to just your travel-related communication there's a lot of potentially sensitive information involved here:

While I'd like to have all the nice digital travel assistant features, I'm not willing to pay with that much personal information for it. On they way home from the Randa meeting last year and unable to read my boarding time in a proprietary Apple Wallet pass file this lead to a little exploration into possible free software alternatives in this field. That got slightly out of hand, and a few month later we have some working components in the KDE Application releases already.

It turns out that the challenge in these systems is actually not so much code, but data. In particular there are three general categories of data to look at:

While not perfect, that's good enough to get started :) The next post will detail how far we got by now.

19 Aug 2018 10:00am GMT

feedPlanet GNOME

Umang Jain: GNOME Asia 2018, Taipei

I am very pleased to attend to GNOME Asia(again!) that took place at National Taiwan University of Science and Technology, Taipei this year. Its always great to see GNOME folks around, hanging out and have a social side of things. GNOME Asia was co-hosted with OpenSUSE Asia summit and COSCUP.

Markdowm Image

Co-hosting with openSUSE and COSCUP surely had benefits as there was inter-community interaction. The keynote space was shared with GNOME and openSUSE board members to address the free software local community and the participants. Overall, it has been a good conference; both in terms of talks and having a social gathering. Tech talks that I found quite interesting:

Apart from that, I attended a few talks around community and getting involved with open source like "Introduction to GSoC" by Ana María Martínez. There was a very intriguing talk was about designing GNOME Shoes in Inkspace where Iwan S. Tahari takes through the whole process of making shoes from scratch (I will mention the link here once videos are out. It's a must watch!!).

Markdowm Image

We had a GNOME BoF to address couple of issues around conferences: Mostly around standardization of conference organization, budget, effect of local team presence at potential conference venues etc.

We all hung out in the evening for dinner & drinks. I stayed back in Taipei for one extra day for visiting the Endless office and meeting the kernel/hardware enablement team. Fortunately, I also met Daniel Drake and Jonathan Blandford who were in Taipei at the same time. I had my first day of working from the company's office(I work remotely from India) :)

Markdowm Image

Endless office in Taipei

I really had a beautiful time in Taipei. It's a great city to be in. We all bid good-byes until we meet again. I can't wait to visit Taipei again. Also want to thank GNOME Foundation to assist with the travel.

Markdowm Image


Markdowm Image

19 Aug 2018 5:30am GMT

feedPlanet KDE

This week in Usability & Productivity, part 32

I'm back from Akademy, and I can't wait to share some of the cool stuff that happened there over the past week. I'm going to post the video of my talk as soon as it's up. But first, I know what you're all really waiting for: this week's Usability & Productivity update. Though we were all quite busy, somehow everyone managed to accomplish an enormous amount of work, too!

In particular there has been a momentous amount of improvement to Kate and the code that underpins it: the Syntax Highlighting and KTextEditor frameworks. These frameworks are used to provide text editor views to the Kate, KWrite, KDevelop, and Kile apps, so any improvements to them are felt very widely within the universe of KDE apps. I want to recognize the efforts of Christoph Cullmann, Dominik Haumann, Kåre Sårs, and Sven Brauch for their stunning amount of work. While I was working on this post Tuesday night, there was a time when I was literally (not figuratively, I mean literally literally) unable to document the improvements as fast as they would show up in my email inbox. These guys deserve the community's respect for the stunning quantity of work they performed in an astonishingly small amount of time. Let's give 'em all a round of applause.

But that's not all! Take a look at the full list, which includes many, many more nice improvements:

New Features


UI Polish & Improvement

Next week, your name could be in this list! Just check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters.

If my efforts to perform, guide, and document this work seem useful and you'd like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

19 Aug 2018 3:41am GMT

18 Aug 2018

feedPlanet GNOME

Jussi Pakkanen: Linker symbol lookup order does not work the way you think

A common problem in linking problems has to do with circular dependencies. Suppose you have a program that looks like this:

Here program calls into function one, which is in library A. That calls into function two, which is in library B. Finally that calls into function three, which is back in library A again.

Let's assume that we use the following linker line to build the final executable:

gcc -o program prog.o liba.a libb.a

Because linkers were originally designed in the 70s, they are optimized for minimal resource usage. In this particular case the linker will first process the object file and then library A. It will detect that function one is used so it will take that function's implementation and then throw the rest of library A away. It will then process library B, take function two in the final program and note that function three is also needed. Because library A was thrown away the linker can not find three and errors out. The fix to this is to specify A twice on the command line.

This is how everyone has been told things work and if you search the Internet you will find many pages explaining this and how to set it up linker command lines correctly.

But is this what actually happens?

Let's start with Visual Studio

Suppose you were to do this in Visual Studio. What do you think would happen? There are four different possiblities:
  1. Linking fails with missing symbol three.
  2. Linking succeeds and program works.
  3. Either 1. or 2. happens, but there is not enough information to tell which.
  4. Linking succeeds but the final executable does not run.
The correct answer is 2. Visual Studio's linker is smart, keeps all specified libraries open and uses them to resolve symbols. This means that you don't have to add any library on the command line twice.

Onwards to macOS

Here we have the same question as above but using macOS's default LLD linker. The choices are also the same as above.

The correct answer is also 2. LLD keeps symbols around just like Visual Studio.

What about Linux?

What happens if you do the same thing on Linux using the default GNU linker? The choices are again the same as above.

Most people would probably guess that the correct answer here is 1. But it's not. What actually happens is 3. That is, the linking can either succeed or fail depending on external circumstances.

The difference here is whether functions one and three are defined in the same source file (and thus end up in the same object file) or not. If they are in the same source file, then linking will succeed and if they are in separate files, then it fails. This would indicate that the internal implementation of GNU ld does not work at the symbol level but instead just copies object files out from the AR archive wholesale if any of their symbols are used.

What does this mean?

For example it means that if you build your targets with unity builds, their entire symbol resolution logic changes. This is probably quite rare but can be extremely confusing when it happens. You might also have a fully working build, which breaks if you move a function from one file to another. This is a thing that really should not happen but when it does things get very confusing.

The bigger issue here is that symbol resolution works differently on different platforms. Normally this should not be an issue because symbol names must be unique (or they must be weak symbols but let's not go there) or the behaviour is undefined. It does, however, place a big burden on cross platform projects and build systems because you need to have very complex logic in place if you wish to deduplicate linker flags. This is a fairly common occurrance even if you don't have circular dependencies. For example when building GStreamer with Meson some time ago the undeduplicated linker line contained hundreds duplicated library entries (it still does but not nearly as many).

The best possible solution would be if GNU ld started behaving the same way as VS linker and LLD. That way all major platforms would behave the same and things would get a lot simpler. In the mean time one should be able to simulate this with linker grouping flags:
  1. Go through all linker arguments and split them to libraries that use link_whole and those that don't. Throw away any existing linker grouping.
  2. Deduplicate and put the former at the beginning of the link line with the requisite link_full arguments.
  3. Deduplicate all entries in the list of libraries that don't get linked fully.
  4. Put the result of 3 on the command line in a single linker group.
This should work and would match fairly accurately what VS and LLD already do, so at least all cross platform projects should work out of the box already.

What about other platforms?

The code is here, feel free to try it out yourself.

18 Aug 2018 6:12pm GMT

Jens Georg: Reminder: Shotwell Facebook publishing no longer working

As announced earlier, since August 1st, 2018 Shotwell cannot publish to Facebook any more. The API that Shotwell used for that was removed and it is currently not clear to me how developers that do not use Android, iOS or Facebook's web SDKs should provide similar functionality.

18 Aug 2018 4:37pm GMT

16 Aug 2018


Peter Hutterer: libinput's "new" trackpoint acceleration method

This is mostly a request for testing, because I've received zero feedback on the patches that I merged a month ago and libinput 1.12 is due to be out. No comments so far on the RC1 and RC2 either, so... well, maybe this gets a bit broader attention so we can address some things before the release. One can hope.

Required reading for this article: Observations on trackpoint input data and X server pointer acceleration analysis - part 5.

As the blog posts linked above explain, the trackpoint input data is difficult and largely arbitrary between different devices. The previous pointer acceleration libinput had relied on a fixed reporting rate which isn't true at low speeds, so the new acceleration method switches back to velocity-based acceleration. i.e. we convert the input deltas to a speed, then apply the acceleration curve on that. It's not speed, it's pressure, but it doesn't really matter unless you're a stickler for technicalities.

Because basically every trackpoint has different random data ranges not linked to anything easily measurable, libinput's device quirks now support a magic multiplier to scale the trackpoint range into something resembling a sane range. This is basically what we did before with the systemd POINTINGSTICK_CONST_ACCEL property except that we're handling this in libinput now (which is where acceleration is handled, so it kinda makes sense to move it here). There is no good conversion from the previous trackpoint range property to the new multiplier because the range didn't really have any relation to the physical input users expected.

So what does this mean for you? Test the libinput RCs or, better, libinput from master (because it's stable anyway), or from the Fedora COPR and check if the trackpoint works. If not, check the Trackpoint Configuration page and follow the instructions there.

16 Aug 2018 4:47am GMT

13 Aug 2018


Rodrigo Siqueira: GSoC Final Report

GSoC Final Report

Nothing lasts forever, and this also applies for GSoC projects. In this report, I tried to summarize my experience in the DRI community and my contributions.

Recap the project idea

First, it is important to remember the main subject of my GSoC Project:

The Kernel Mode-Setting (KMS) is a mechanism that enables a process to command the kernel to set a mode (screen resolution, color depth, and rate) which is in a range of values supported by graphics cards and the display screen. Creating a Virtual KMS (VKMS) has benefits. First, it could be used for testing; second, it can be valuable for running X or Wayland on a headless machine enabling the use of GPU. This module is similar to VGEM, and in some ways to VIRTIO. At the moment that VKMS gets mature enough, it will be used to run i-g-t test cases and to automate userspace testing.

I heard about VKMS in the DRM TODO list and decided to apply for GSoC with this project. A very talented developer from Saudi Arabia named Haneen Mohammed had the same idea but applied to the Outreachy program. We worked together with the desire to push as hard as we can the Virtual KMS.

Overcome the steep learning curve

In my opinion, the main reason for the steep learning curve came from the lack of background experience in how the graphics stack works. For example, when I took operating system classes, I studied many things related to schedulers, memory and disk management, and so forth; on the other hand, I had a 10000-foot view of graphics systems. After long hours of studying and coding, I started to understand better how things work. It is incredible all the progress and advances that the DRI developers brought on the last few years! I wish that the new versions of the Operating system books have a whole chapter for this subject.

I still have problems to understand all the mechanisms available in the DRM; however, now I feel confident on how to read the code/documentation and get into the details of the DRM subsystem. I have plans to compile all the knowledge acquired during the project in a series of blog posts.


During my work in the GSoC, I send my patches to the DRI mailing list and constantly got feedback to improve my work; as a result, I rework most of my patches. The natural and reliable way to track the contribution is by using "git log -author="Rodrigo Siqueira" in one of the repositories below:

In summary, follows the main patches that I got accepted:

We received two contributions from external people; I reviewed both patches:

I am using IGT to test VKMS, for this reason, I decided to send some contributions to them. I sent a series of patches for fixing GCC warning:

I also sent a patchset with the goal of adding support for forcing a specific module to be used by IGT tests:

As a miscellaneous contribution, I created a series of scripts to automate the workflow of Linux Kernel development. This small project was based on a series of scripts provided by my mentor, and I hope it can be useful for newcomers. Follows the project link:

  1. Kworkflow

Work in Progress

I am glad to say that I accomplished all the tasks initially proposed and I did much more. Now I am working to make VKMS work without vblank. This still a work in progress but I am confident that I can finish it soon. Finally, it is important to highlight that my GSoC participation will finish at the end of August because I traveled for two weeks to join the debconf2018.

Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning - Winston Churchill

GSoC gave me one thing that I was pursuing for a long time: a subsystem in the Linux Kernel that I can be focused for years. I am delighted that I found a place to be focused, and I will keep working on VKMS until It is finished.

Finally, the Brazilian government opened a call for encouraging free software development, and I decided to apply the VKMS project. Last week, I received the great news that I was selected in the first phase and now I am waiting for the final results. If everything ends well for me, I will receive funding to work for 5 months in the VKMS and DRM subsystem.

My huge thanks to…

I received support from many people in the dri-devel channel and mailing list. I want to thanks everybody for all the support and patience.

I want to thanks Daniel Vetter for all the feedback and assistance in the VKMS work. I also want to thanks Gustavo Padovan for all the support that he provided to me (which include some calls with great explanations about the DRM). Finally, I want to thanks Haneen for all the help and great work.


  1. Use new return type vm_fault_t
  2. Fix the error handling in vkms_init()
  3. Add support to force specific module load

13 Aug 2018 3:00am GMT

09 Aug 2018


Peter Hutterer: How the 60-evdev.hwdb works

libinput made a design decision early on to use physical reference points wherever possible. So your virtual buttons are X mm high/across, the pointer movement is calculated in mm, etc. Unfortunately this exposed us to a large range of devices that don't bother to provide that information or just give us the wrong information to begin with. Patching the kernel for every device is not feasible so in 2015 the 60-evdev.hwdb was born and it has seen steady updates since. Plenty a libinput bug was fixed by just correcting the device's axis ranges or resolution. To take the magic out of the 60-evdev.hwdb, here's a blog post for your perusal, appreciation or, failing that, shaking a fist at. Note that the below is caller-agnostic, it doesn't matter what userspace stack you use to process your input events.

There are four parts that come together to fix devices: a kernel ioctl and a trifecta of udev rules hwdb entries and a udev builtin.

The kernel's EVIOCSABS ioctl

It all starts with the kernel's struct input_absinfo.

struct input_absinfo {
__s32 value;
__s32 minimum;
__s32 maximum;
__s32 fuzz;
__s32 flat;
__s32 resolution;

The three values that matter right now: minimum, maximum and resolution. The "value" is just the most recent value on this axis, ignore fuzz/flat for now. The min/max values simply specify the range of values the device will give you, the resolution how many values per mm you get. Simple example: an x axis given at min 0, max 1000 at a resolution of 10 means your devices is 100mm wide. There is no requirement for min to be 0, btw, and there's no clipping in the kernel so you may get values outside min/max. Anyway, your average touchpad looks like this in evemu-record:

# Event type 3 (EV_ABS)
# Event code 0 (ABS_X)
# Value 2572
# Min 1024
# Max 5112
# Fuzz 0
# Flat 0
# Resolution 41
# Event code 1 (ABS_Y)
# Value 4697
# Min 2024
# Max 4832
# Fuzz 0
# Flat 0
# Resolution 37

This is the information returned by the EVIOCGABS ioctl (EVdev IOCtl Get ABS). It is usually run once on device init by any process handling evdev device nodes.

Because plenty of devices don't announce the correct ranges or resolution, the kernel provides the EVIOCSABS ioctl (EVdev IOCtl Set ABS). This allows overwriting the in-kernel struct with new values for min/max/fuzz/flat/resolution, processes that query the device later will get the updated ranges.

udev rules, hwdb and builtins

The kernel has no notification mechanism for updated axis ranges so the ioctl must be applied before any process opens the device. This effectively means it must be applied by a udev rule. udev rules are a bit limited in what they can do, so if we need to call an ioctl, we need to run a program. And while udev rules can do matching, the hwdb is easier to edit and maintain. So the pieces we have is: a hwdb that knows when to change (and the values), a udev program to apply the values and a udev rule to tie those two together.

In our case the rule is 60-evdev.rules. It checks the 60-evdev.hwdb for matching entries [1], then invokes the udev-builtin-keyboard if any matching entries are found. That builtin parses the udev properties assigned by the hwdb and converts them into EVIOCSABS ioctl calls. These three pieces need to agree on each other's formats - the udev rule and hwdb agree on the matches and the hwdb and the builtin agree on the property names and value format.

By itself, the hwdb itself has no specific format beyond this:


But since we want to match for specific use-cases, our udev rule assembles several specific match lines. Have a look at 60-evdev.rules again, the last rule in there assembles a string in the form of "evdev:name:the device name:content of /sys/class/dmi/id/modalias". So your hwdb entry could look like this:

evdev:name:My Touchpad Name:dmi:*svnDellInc*

If the name matches and you're on a Dell system, the device gets the EVDEV_ABS_00 property assigned. The "evdev:" prefix in the match line is merely to distinguish from other match rules to avoid false positives. It can be anything, libinput unsurprisingly used "libinput:" for its properties.

The last part now is understanding what EVDEV_ABS_00 means. It's a fixed string with the axis number as hex number - 0x00 is ABS_X. And the values afterwards are simply min, max, resolution, fuzz, flat, in that order. So the above example would set min/max to 0:1 and resolution to 3 (not very useful, I admit).

Trailing bits can be skipped altogether and bits that don't need overriding can be skipped as well provided the colons are in place. So the common use-case of overriding a touchpad's x/y resolution looks like this:

evdev:name:My Touchpad Name:dmi:*svnDellInc*

0x00 and 0x01 are ABS_X and ABS_Y, so we're setting those to 30 units/mm and 20 units/mm, respectively. And if the device is multitouch capable we also need to set ABS_MT_POSITION_X and ABS_MT_POSITION_Y to the same resolution values. The min/max ranges for all axes are left as-is.

The most confusing part is usually: the hwdb uses a binary database that needs updating whenever the hwdb entries change. A call to systemd-hwdb update does that job.

So with all the pieces in place, let's see what happens when the kernel tells udev about the device:

Once you understand how the various bits fit together it should be quite easy to understand what happens. Then the remainder is just adding hwdb entries where necessary but the touchpad-edge-detector tool is useful for figuring those out.

[1] Not technically correct, the udev rule merely calls the hwdb builtin which searches through all hwdb entries. It doesn't matter which file the entries are in.

09 Aug 2018 2:17am GMT