Libinput support added to Touchpad KCM

libinput is a library to handle input devices in Wayland compositors and to provide a generic X.Org input driver. It provides device detection, device handling, input device event processing and abstraction so minimize the amount of custom input code compositors need to provide the common set of functionality that users expect.

libinput is expected to replace input drivers such as synpatics in the future, and there’s already a drive to move input stack in Fedora 22 to libinput as can be seen in the discussion here. Most of the software would transparently work, except – as quickly noted in that discussion – the KDE touchpad configuration. Tochpad KCM exposes almost every knob present in the synaptics driver. In contrast, libinput exposes very few options to configure – such as tap-to-click and keeps most of the other options enabled by default – such as disable touchpad while typing. This is more sensible and efficient to do – when using synaptics driver, disabling touchpad while typing was accomplished by the synclient daemon.

As an aftermath of the discussion in Fedora, libinput maintainer Peter Hutter contacted KDE developers, including yours truly who is guilty of porting the kcm-touchpad to KDE Frameworks 5. As I know nothing about input stack or touchpads in general (phew), Peter was kind enough to step up, clone the kcm-touchpad and add support for libinput in addition to (existing) synaptics driver. All I had to do then, is to port it again to Frameworks 5.

Tochpad KCM running on libinput

Tochpad KCM running on libinput

As of last week, the review request to do that has been reviewed by Martin Gräßlin and David Edmundson and merged into the master branch – in the meantime I have obtained KDE developer commit access. In other words, Touchpad KCM now supports both libinput and synaptics drivers! If both are installed, libinput is preferred and exposes only the relevant options. As the KCM user interface exposes a lot of options, most of them remain disabled. Ideally, it should be re-designed – for example the GNOME mouse/touchpad configuration (including GNOME Tweak tool) exposes very few options. Alexander Mezin, kcm-touchpad maintainer has mentioned plan to rewrite it, I hope he will be able to find some time.

The updated kcm-tochpad packages for Fedora 20, 21 and Rawhide (what to become F22) are available for testing in the copr in Fedora repositories. For some caveats such as edge scrolling available only on single-touch touchpads, see the discussion and associated bug here. There’s still some issue with edge scrolling setting, I’m investigating it.

KDE Frameworks 5 based apps available in copr

I have built RPM packages of some KDE applications frameworks branch, such as Konsole, Dolphin which are available in my copr. It is based on the Plasma-5.2 beta copr from Dan Vratil, you’d need to enable it first to pull dependencies. Packages are available for Fedora 20 and 21, i386 and x86_64 architectures.


Paratype PT Serif and PT Mono fonts are now available in Fedora

Paratype has a set of nice Latin/pan-Cyrillic typefaces including sans-serif, serif and monospace fonts. The sans-serif typeface, PT Sans, released in 2010 has been part of Fedora for a long time and it is the default font for Cyrillic/Russian. It is a nice font for display in desktop, documents and web.

In 2011, PT Serif and PT Mono were added to the collection. They both are nice looking and very good quality fonts. All the fonts are also made available under OFL (Open Font License) and all it needed was someone to package them for Fedora. Something in my todo list for a long time, couple of weeks ago I have leveraged the spec file of paratype-pt-sans-fonts and packaged the serif and monospaced fonts. Paratype distributes the source tar balls separately for each set and Fedora mandates to create individual packages in such cases. Thanks to the review and comments from Fedora Fonts-SIG, especially Parag Nemade, two new font packages – paratype-pt-serif-fonts and paratype-pt-mono-fonts are now in Fedora repositories.

Obligatory screenshot of both fonts:


Malayalam opentype specification – part 1

This post is a promised followup from last November documenting intricacies of opentype specification for Indic languages, specifically for Malayalam. There is an initiative to document similar details in the IndicFontbook, this series might make its way into it. A Malayalam unicode font supporting traditional orthography is required to correctly display most of the examples described in this article, some can be obtained from here.

Malayalam has a complex script, which in general means the shape and position of glyphs are determined in relation with other surrounding glyphs, for example a single glyph can be formed out of a combination of independent glyphs in a specific sequence forming a conjunct. Take an example: ക + ്‌ ‌+ ത + ്‌ + ര => ക്ത്ര in traditional orthography. Note that in almost all the cases glyph shaping and positioning change such as this example is due to the involvement of Virama diacritic ” ്‌ “. The important rules on glyph forming are:

  1. When Virama is used to combine two Consonants, it usually forms a Conjunct, such as ക + ്‌ ‌+ ത => ക്ത. This is known as C₁ conjoining as a half form of first consonant is joined with second consonant.
  2. The notable exceptions to point 1 are when the followed Consonants are either of യ, ര, ല, വ. In those cases, they form the ‘Mark’ shapes of യ, ര, ല, വ =>  ്യ, ്ര,  ്ല,  ്വ. This is known as C₂ conjoining as a modified form of second consonant is attached to the first consonant.
  3. When Virama is used to combine a Consonant with Vowel, the Vowel forms a Vowel Mark => such as ാ, ി, ീ.

Opentype organizes these glyph forming and shaping logic by a sequence of ‘Lookup tables (or rules)’ to be defined in the font. The first part gives an overview of the relevant lookup rules used for glyph processing by shaping engine such as Harfbuzz or Uniscribe.

Only those opentype features applicable for Malayalam are discussed. The features (or lookups) are applied in the following order:

  1. akhn (Akhand – used for conjuncts like ക്ക, ക്ഷ, ല്ക്ക, യ്യ, വ്വ, ല്ല etc)
  2. pref (Pre-base form – used for pre base form of Ra –  ്‌ + ര =   ്ര)
  3. blwf (Below base form – used for below base form of La – virama+La – ്‌ + ല =  ്ല)
  4. half (Half form – Not used in mlm2 spec by Rachana and Meera, but used in mlym spec and might be useful later. For now, ignore)
  5. pstf (Post base form – used for post base forms of Ya and Va – ്‌ +യ =  ്യ, ്‌ + വ = ്വ. Note that  യ്യ & വ്വ are under akhn rule)
  6. pres (Pre-base substitution – mostly used for ligatures involving pref Ra – like ക്ര, പ്ര, ക്ത്ര, ഗ്ദ്ധ്ര  etc)
  7. blws (Below base substitution – used for ligatures involving blwf La – like ക്ല, പ്ല, ത്സ്ല etc. Note that  ല്ല is under akhn rule)
  8. psts (Post base substitution – used for ligatures involving post base Matras – like കു, ക്കൂ, മൃ etc)
  9. abvm (Above base Mark  positioning – used for dot Reph – ൎ)

Last 3 forms (pres, blws, psts) are presentation forms, they have lower priority in the glyph formation. They usually form the large number of secondary glyphs. The final one (abvm) is not a GSUB (glyph substitution lookup) but a GPOS (glyph position lookup) – this is used to position dotreph correctly above the glyphs.

  • akhn: Use this for conjuncts (കൂട്ടക്ഷരങ്ങള്‍) like ക്ക, ട്ട, ണ്ണ, ക്ഷ, യ്യ, വ്വ, ല്ല, മ്പ. This rule has the highest priority, so akhn glyphs won’t be broken by the shaping engine.
  • pref: Used only for pre-base form of Ra ര –  ്ര
  • blwf: Used only for below base form of La ല –  ്ല
  • pstf: Used for the post base forms of Ya, Va യ, വ – ്യ, ്വ
  • pres: One of the presentation forms, mostly used for ligatures/glyphs with pref Ra ര – like ക്ര, പ്ര, ക്ത്ര, ഗ്ദ്ധ്ര etc. This could also used together with the ‘half’ forms in certain situations, but that is for later.
  • blws: Used for ligatures/glyphs with blwf La ല – like ക്ല, പ്ല, ത്സ്ല etc.
  • psts: Used by a large number of ligatures/glyphs due to the post base Matras (ു,ൂ,ൃ etc) – like  കു, ക്കൂ, മൃ etc. Other Matras (ാ,ി,ീ,േ,ൈ,ൈ,ൊ,ോ,ൌ,ൗ) are implicitly handled by the shaping engine based on their Unicode properties (pre-base, post-base etc) as they don’t form a different glyph together with a consonant – there is no need to define lookup rules for those matras in the font.

I will discuss these lookup rules and how they fit in the glyph shaping sequence with detailed examples in next episodes.

(P.S: WordPress tells me I started this blog 7 years ago on this day. How time flies.)

KDE Touchpad configuration ported to Frameworks 5

Fedora 20 with KDE SC 4.14 has been very stable, and after a while it gets…boring – especially when Plasma 5 is already released and you see screenshots everywhere. If you cannot hold the urge and feel sufficiently adventurous, Dan Vratil has built the Fedora 20 and 21 rpms here. If you install i386 versions, beware that baloo-widgets cannot be installed due to unmet dependencies. So, once you install dvratil’s copr repo, just do:

dnf copr enable dvratil/kde-frameworks dvratil/kde-frameworks-unstable dvratil/plasma5
dnf remove kde\* && dnf install kf5\* plasma5\* --exclude=kf5-baloo-widgets\*

I had to manually edit /usr/share/xsessions/plasma.desktop to change "/usr//usr/bin" to "/usr/bin” so that “Plasma 5″ appears in gdm list. After logging in, the desktop runs smooth, but you notice the lack of many applications because they are not yet fully ported to KF5/Plasma5.

KDE Plasma 5 desktop

KDE Plasma 5 desktop

Once I had the Qt5/KF5/Plasma5 based workstation fully operational, I could also develop, build and test KF5 based applications. Most of the KDE apps are ported or being ported to KF5 under 'frameworks' git branch. As the OpenSuSe team already have started building KF5 based apps in an unstable repository, I could leverage the spec files to build rpms.

The first itch I scratched was unavailability of touchpad configuration kcm. Not being able to enable touch-to-tap, vertical and horizontal scrolling is no fun. Looking at the git repo for kcm-touchpad showed that it is not yet ported to KF5. Checked out the git repo and started porting. There are quite some references, blogposts and tools available online to guide and ease the porting effort. As it is a kcm that is being ported, the first place to go is Frameworks Porting Notes. The subtopic of ECM (extended cmake modules) source incompatible changes is also handy updating CMakeLists.txt files. The next thing is reference to Martin Graesslin’s post on porting kcontrol module. And the final tool that is quite useful to port API changes is the kde-dev-scripts. Run the source files through relevant script – like "find -iname "*.cpp" -o -iname "*.h" -o -iname "*.ui" | xargs ~/Programs/Projects/kde-dev-scripts/kf5/<>". When you hit an API change that cannot be automatically converted by the script, check frameworks at Then port away, setup a build directory, compile, note the build failure, fix the build – repeat.

Alexander Mezin and Hrvoje Senjan reviewed the patches and after 6 revisions the patch is committed in kcm-touchpad frameworks branch.

KCM Touchpad on KF5

KCM Touchpad on KF5

RPMs for Fedora 20 and 21 (i386, x86_64) are built and available in my copr repo. It contains builds of kmix and konsole as well. More to build and I’ll make them available in the same repo once build completed. You are welcome to try at your own risk :-)

SMC mentoring for GSoC 2014 too

Swathanthra Malayalam Computing is a free software collective engaged in language computing, development, localization, standardization and popularization of various Free and Open Source Softwares in Malayalam language. SMC developers have contributed to various Indian language computing efforts including fonts, spell checkers, hyphenation patterns (used by TeX, Libreoffice, Firefox), input methods etc. Last year, SMC was selected as a mentor for Google Summer of Code program and we successfully mentored 3 student projects – a web application to store and process bibliography data of books with i8n support, port SILPA into Flask application and restructure into standalone modules and Automated Shaping&Rendering testing, primarily for HarfBuzz.

Together with Santhosh, I have mentored the Automated Shaping&Rendering testing framework which we use to test Malayalam font changes against HarfBuzz. It can also be used to test Uniscribe shaping engine if compiled in Windows, or used against HarfBuzz with Uniscribe backend.

SMC is selected as an organization to mentor for GSoC again this year. If you are a student who wants to work on interesting problems, look at our project ideas. One of the problems I am particularly interested and to mentor is adding Indic shaping support to ConTeXt. Apart from the listed ideas, you can propose other ideas as well. Read the FAQ, you can reach us by mailing list or via IRC #smc-project on