Last week I had a chance to attend the Randa meetings 2017, my plan was to work on the Plasma Mobile during the sprint, improve the state of current images. A few things changed over the course of the week:

New shiny wallpaper and packages

Starting from 8 Sept, we started using the packages from KDE Neon buildsystem instead of building them on the Plasma Mobile CI, this provides few benefits,

• No need to separately build the common things like Qt5, KDE Frameworks, Plasma
• Always up-to-date packages, no need to manually re-trigger builds for common things

We also upgraded to newer version of Qt, Qt 5.9 from the older version of Qt 5.7.1, this aligns our stack with whatever KDE Neon dev unstable edition is using.

Rootfs for non-nexus Qualcomm devices

Non-nexus Qualcomm devices use a modified version of the hwcomposer.h which is not ABI compatible with the generic version of the android API headers, so for them the libhybris and kwin need to be separately built. Previously our CI infrastructure didn’t support this workflow, however now we are able to create the rootfs for such devices. Below is an image of Plasma Mobile running on Xiomi Mi device.

Marble maps

At Randa, we had a chance to test the newer version of the Marble maps, which has much more improved performance when zooming out-in. We were able to happily search locate Randa in the Marble maps.

QML based mobile friendly “konsole”

Previously we were using Konsole from the KDE Applications as a terminal emulator, however Konsole user interface was not mobile-friendly, and it was not possible to e.g, tab complete the command, go through history, etc. At Randa Emmanuel Lepage Vallee pointed us to qmltermwidget, which powers the terminal application in Ubuntu Touch and Cool-retro-term application. Marco Martin was able to write a simple QML application around qmltermwidget which can replace Konsole in Plasma Mobile.

Kirigami based koko

During GSoC 2017 lot of work has been put to port the normal QtQuick based image viewer application Koko to kirigami2, you can follow the work of Student developer Atul Sharma on his blog. At the Randa Sprint, we were able to test this work on Plasma Mobile and it shows great improvements compared to the older version.

Improved window switching experience

Due to a bug in the Plasma Mobile shell, shell windows such as task switcher and shell itself were also appearing in the task switcher, as a result of that user was able to close the shell window which ultimately ends up crashing the plasmashell. We were able to fix this bug in the plasma-workspace and plasma-phone-components so that Plasma Mobile shell windows would not appear in the task switcher.

Kube(!!!)

Yes, that is Kube in the first picture, we were able to run the Kube on the Plasma Mobile, it works in theory on Plasma Mobile, however the user interface is not mobile-friendly and needs various fixes to be usable on mobile. We will work with the Kube team to fix the issues and then test them on Plasma Mobile in the future.

Conclusion

That is all for now, I would like to thank the all the donors who donated for the Randa Meetings 2017, and made it possible for me to travel to Randa, Switzerland.

If you liked the work done on Plasma Mobile during the Randa Sprint, please support us on Randa 2017 fundraiser to make events like Randa possible in the future.

If you want to develop for Plasma Mobile, but you don’t have a Mobile device, it is useful to emulate a Plasma Mobile on your desktop or laptop. Earlier this was not documented and has been asked multiple times on how to achieve this.

This blog post is intended to help install a Plasma Mobile on the qemu-x86.

• First of all create a qemu-image of 10GB size.

qemu-img create -f raw neon-unstable.img 10G

• Download the KDE Neon Dev edition (git unstable) ISO. Link
• Start the qemu system with the downloaded the KDE Neon ISO.

qemu-system-x86_64 -cdrom /path/to/neon-devedition-gitunstable-current.iso -boot menu=on -drive file=/path/to/created/neon-unstable.img,format=raw -vga virtio -display sdl,gl=on -m 2G -enable-kvm

• This will boot the KDE Neon system with Plasma Desktop. You will need to use Calameras to install the Plasma on the virtual machine.

• Once installed, shutdown the virtual machine and restart the machine without ISO attached.

qemu-system-x86_64 -boot menu=on -drive file=/path/to/created/neon-unstable.img,format=raw -vga virtio -display sdl,gl=on -m 2G -enable-kvm

• In the virtual machine, open konsole and add the repository for Plasma Mobile.

curl http://neon.plasma-mobile.org:8080/Pangea%20CI.gpg.key | sudo apt-key add -
sudo add-apt-repository http://neon.plasma-mobile.org:8080

• Install the updates

sudo apt update && sudo apt upgrade

• Install the Plasma Phone shell and configuration for Plasma Phone.

apt install plasma-phone-components plasma-phone-settings

• Logout from the Desktop Session and select the Plasma Mobile (Wayland) session.

• This steps will start Plasma Mobile session.

Please note that this steps are experimental at the moment, I am working on providing pre-built ISO images which will not require the KDE Neon developer edition ISO.

Last week we asked the Free Software community what they wanted to do to help us move forward with Plasma Mobile. These were the results from the poll on Twitter:

And this was what the poll on Google+ looked like:

As you can see, the results were similar with least 44% poll participants wanting to test Plasma Mobile on their device, and/or as a virtual machine, or on real machine. Testing this on virtual machine was quite a hack earlier as explained in a previous blog post. We had no dedicated ISO image for Plasma Mobile, to test the Plasma Mobile one had to install KDE Neon developer edition and then run a few commands to convert it to a Plasma Mobile installation.

But, this week, by popular demand, we are providing an x86_64 based ISO images you can download from Plasma Mobile images server.

How to test

You can download the latest ISO and boot in either Virtual Machine or boot it on real machine.

QEMU/KVM

VirtualBox

On actual device

Things to try

• Add a widget to the desktop

• Download and install an app from Discover Software Center

• Read comics in Peruse

• Test Kaidan, the XMPP client

Disclaimer

This software is Alpha! Use it at your own risk. This software is not recommended for use in production and many core functionalities will probably not work. This version is intended for testing some features and for preview only. Plasma Mobile is not yet at a level where it can substitute the operating system currently running on your mobile phone, but with your help, we will get there.

How to send us feedback

You can reach us on plasma-mobile@kde.org mailing list, or #plasma IRC channel on Freenode, or #plasmamobile:matrix.org matrix room, or on Plasma Mobile telegram group.

Thank you for helping us test Plasma Mobile.

2nd part of this series will focus on testing Plasma Mobile on actual mobile devices instead of virtual machine or PC/laptop

The first part of this series focused on testing Plasma Mobile on virtual machine and/or on a PC/laptop. In this second part we will focus on testing Plasma Mobile on actual mobile devices.

Currently there are two possible ways of testing Plasma Mobile on an actual mobile device,

• Using postmarketOS
• Installing Halium and a KDE neon-based rootfs

I will explain both methods briefly in this blog post. Note that some of these steps may involve getting device-specific sources and building them manually, This may require a intermediate knowledge of how to unlock the bootloader, flashing and restoring devices and basic knowledge about various UNIX/Linux commands.

Using postmarketOS

postmarketOS is touch-optimized, pre-configured Alpine Linux-based distribution which offers Plasma Mobile as one choice of several available user interfaces.

There is a list of the devices that can run postmarketOS, and you can find instructions on installing postmarketOS on your device at their wiki page.

When you follow the instructions to install postmarketOS, remember to select “plasma-mobile” as the user interface when asked:

Available user interfaces (5):
* none: No graphical environment
* hildon: (X11) Lightweight GTK+2 UI (optimized for single-touch touchscreens)
* luna: (Wayland) webOS UI, ported from the LuneOS project (Not working yet)
* plasma-mobile: (Wayland) Mobile variant of KDE Plasma, optimized for touchscreen
* weston: (Wayland) Reference compositor (demo, not a phone interface)
* xfce4: (X11) Lightweight GTK+2 desktop (stylus recommended)
User interface [weston]: plasma-mobile

An important thing to note about postmarketOS is that it also offers Plasma Mobile on devices running mainline kernel, for example on the Sony Xperia Z2 tablet, Google Nexus 7 (2013), and LG Nexus 5 (partially). More information about Plasma Mobile on postmarketOS project can be found at the Plasma Mobile wiki entry.

Video below shows Plasma Mobile running on the Sony Xperia Z2 Tablet, which is running on mainline kernel instead of the pre-installed older kernel version.

However note that the postmarketOS project is still at very early stages of development and is not suitable for most end users yet.

Installing Halium and a KDE neon-based rootfs

Halium provides the minimal android layer that allows a non-Android graphical environment to interact with the underlying Android kernel and access the hardware. The Plasma Mobile team provides a Neon-based rootfs which can be used along with the Halium builds. Currently Halium has been ported to multiple devices, however, binary builds are not provided because most of them include binary blobs which we cannot redistribute them legally. Instead we provide a link to the source manifest and you can use that to build your own images. Documentation on how to build and install Halium is available at the Halium website.

Plasma Mobile on Nexus 5 and Nexus 5X is using the Halium based images, binary images for those are distributed at Plasma Mobile image server as a reference for other porters and developers for easy testing. You can install on those devices using the flashtool available on Github.

Plasma Mobile reference images are based on halium, which uses the propietary binary blobs to make use of phone hardware. This requires the libhybris which allows us to use bionic based binary blobs in the traditional libc based environment. Halium based devices also use very old vendor-provided kernel trees, these vendor trees generally range from version 3.4 to 3.18, most of the kernel versions listed here are already marked as EOL on kernel.org.

Greg KH addressed this issue in a 3.18.48 kernel announcement email rant:

> Oh, if you are _stuck_ on 3.18 (/me eyes his new phone), well, I might
> have a plan for you, that first involves you yelling very loudly at your
> hardware vendor and refusing to buy from them again unless they cut this
> crap out. After you properly vent to them, drop me an email and let's
> see what we can come up with, you aren't in this sinking ship alone, and
> it's obvious your vendor isn't going to help out...

It’s however very clear that yelling at device vendor hasn’t really helped and we’re still seeing the new devices arriving on the market shipping Linux kernel version 3.18. There are some very new phones in market which use Kernel version 4.4, however these devices are so expensive that it is generally not feasible for many people to buy them.

So, how do we solve this issue? Projects like postmarketOS tries to solve this issue by using only open source components provided by vendors and avoiding binary blobs, but generally this doesn’t really result in usable system as it will not allow us to use Hardware Acceleration and other hardware features. Another solution is to use the mainline kernel, which is actively maintained and developed by the Linux Kernel community.

Little while after I started working on Plasma Mobile I stumbled upon the Android running on Nexus 7 with mainline kernel and wondered what it would take to get Plasma Mobile running on the device which runs the mainline kernel and a fully free software stack. In the process, I learned about how to mainline and asked the folks in ##linux-msm and #freedreno channels for help. Thanks to @bamse, @agross, @robclark I managed to add initial support for Nexus 5 board in the mainline kernel. This was merged into Linux kernel version 4.9. However this didn’t really support useful features other then serial console over headphone jack, power and volume buttons. After adding initial support for hammerhead in mainline kernel I was not able to continue the work due to time constraints.

Similar to hammerhead, community member opendata, a contributor to postmarketOS project, very recently managed to run Plasma Mobile on the Sony Xperia Z2 tablet. While the device came with a Linux kernel version 3.4 from the provider, @bamse managed to port 4.X Linux kernel version to that device. Recently I learned that community member flto has continued the work I started a while ago, and has been more successful in hardware support then I initially was.

This week I decided to provide a pre-built Plasma Mobile image which can work with the mainline kernel. Current Plasma Mobile images are based on KDE Neon, which uses Ubuntu 16.04 Xenial as an underlying base. Unfortunately the version of Mesa in Ubuntu’s repos were too old. Thankfully, community member JBBgameich has been maintaining the apt repository for Debian buster which included packages for Plasma Mobile. After some work to create a rootfs I successfully managed to boot a Plasma Mobile image on the Nexus 5 running a mainline kernel with mesa and freedreno graphics driver.

Using the same image as me, opendata was also able to run Plasma Mobile on the Sony Xperia Z2 tablet. Below is snapshot of the Kinfocenter application showing the system information.

Currently these images are mainly experimental and super-unstable, they aren’t really ready for production at all. However it proves that Plasma Mobile is capable of running on devices which support the mainline Linux kernel and fully free software stack. This will ultimately be useful for all the new projects working on free and open mobiles, such as Sony’s Xperia open devices, Purism’s Librem 5, since Plasma Mobile is committed to providing fully free and open source software for every device.

Despite the usual warnings that it may eat your kittens, if you want to try it on your device which is supported by mainline kernel, please contact us on Matrix at #plasmamobile:matrix.org or over email at plasma-mobile@kde.org

Thanks to KDE Plasma team, @JBBgameich, @opendata, @flto, @bamse, @robclark, @agross, postmarketOS community, Debian Qt/KDE team for making this possible

QtCon starts on this Sept 1st and I will be traveling to Berlin on this Tuesday. This is second Akademy I am attending after Akademy 2014 in Czech Republic. During QtCon I am giving presentation titled Plasma Mobile: what we achieved in year in room A04 on 2nd September. And also I am going to moderate a Student Presentations where students taking part in various mentoring programs in KDE, like GSoC, GCI, SoK, or OPW.

Also I am taking part in various BoFs starting from Sept 5, like Plasma BoF, KDE SoC, and KDE Neon BoF.

Looking forward to productive QtCon! See you in Berlin! :-)

Currently Plasma Mobile is supported by very small number of devices, for example Nexus 5, and One plus one. These devices uses Android 5.0 or CM12 as their base. Current libhybris upstream doesn’t have support for the devices running Android 6.0 (Marshmallow), however there are two different forks of libhybris which are proposed to be merged into upstream libhybris and supports the Android 6.0,

• https://github.com/libhybris/libhybris/pull/327
• https://github.com/libhybris/libhybris/pull/328

This allows one to use Android 6.0 based binaries on normal Linux userspace and supports both armhf and aarch64 with some changes. I decided to try this on recent Nexus 5X device for which only Android 6.0 and higher version’s binary blobs are available. With some changes in KWin, for example : support for HWcomposer 1.4 and 1.5 and some changes in build infrastructure, it was possible to have Plasma working on Nexus 5X.

Image showing test_hwcomposer running from libhybris:

Image showing Plasma Mobile running on Nexus 5X:

As of now, just graphics and input are supported on Nexus 5X, however I’ve plan to work on Network, calling and other functionalities in upcoming weeks, which is required to have usable system. However this is good step in direction of having support for more devices, as this will open the possibilities of supporting newer devices, I will be happy to help if someone wants to port/run Plasma Mobile on their device, feel free to contact me over email bshah@kde.org or in #plasma channel on Freenode.

If you like work done by KDE community like this and want to support our work, please consider donating to our Make the World a Better Place! - KDE End of Year 2016 Fundraising campaign.

Happy Holidays!

We are at almost end of 2016, unfortunately 2016 also took away great project with it, Cyanogenmod. However there is fork named LineageOS in pipeline. Given we switched our android base to CyanogenMod earlier, lots of people asked me how this will affect Plasma Mobile?

We used CyanogenMod source tree and kernel for generating minimal android system which is used in hammerhead port. All of them are available on github currently. However it is not clear that upto when it will be available and will receive updates given code review system (gerrit) for CyanogenMod is offline. At this point we have two options,

• Switch to LineageOS, given it is 1:1 fork of CyanogenMod currently it will not require much work.
• Switch to AOSP base, given we don’t really use the “extra” things provided by CM on top of AOSP.

While option 2 might sound big work, it in fact is not. For instance, in Nexus 5X (bullhead) port, underlying system is AOSP based instead of the CyanogenMod to simplify the things. Personally I had low priority task on phabricator for longterm to switch to AOSP base, but based on current situation this will need to be done with higher priority than earlier. :-(

That’s all for now, I hope this clarifies situation..

This post is public service announcement regarding the KDE Neon infrastructure.

Earlier we KDE neon developers decided that we should build the armhf and/or arm64 packages on Neon CI itself instead of the different Plasma Mobile specific Jenkins Instance. First step to make this happen was the adding ARM architecture in the KDE Neon package archive. We are using the Aptly for serving the packages.

Aptly however have a limitation that if you have started with publishing the empty repository, then you need to specify the complete architectures list initally and that list can’t be updated after publishing. See quote from Aptly docs,

Empty local repos could be published as well (as placeholder, for subsequent updates using aptly publish update command). When publishing empty local repos it is important to specify complete architectures list (using -architectures flag), as it can’t be changed after publishing.

Due to this limitation, only solution we had was to drop and republish the repositories with new architectures added. I started working on this at 15:43:14 IST yesterday, following were the steps taken:

• Suspended neon CI
• Stopping the aptly service on the racnoss.kde.org server
• Create a staging public repository and symlink it to older path
• Take a backup of the old aptly db at ~/aptly/db
• Restart the aptly service and run a script to drop and republish the public repositories

At this point, script failed with cryptic 404 error instantly however, upon inspection we realized that it was failing for old wily repos, which are unused since we are using the Ubuntu 16.04 xenial nowadays. Since we are not doing any builds of wily currently, script was modified to skip the published repositories of wily distribution. However next run of script failed with 404 API error again. Cause for this error turned out to be different, it was design flow in the aptly REST API which is exposed when the publish Prefix have / or _ in it. To quote from Aptly docs,

if publishing prefix contains slashes /, they should be replaced with underscores (_) and underscores should be replaced with double underscore (__).

At this point checking state of aptly revealed that out of 10 publishing end points we had just 3 publishing endpoints present, At this point we reverted to older db backup and fixed the script, this time execution of script was sucessful. However I wanted someone to verify that everything is in order before making the new published repositories public. So today after inspection of both old and new repositories I’ve made the change final and also KDE Neon Jenkins is now back in service, running builds.

For users

This change affects the KDE Neon archive. I’ve done my best to verify that everything is in order but still if you face any errors while doing apt update or apt upgrade, please let us know by commenting here or in #kde-neon IRC channel. I will keep backup of old aptly db and public repositories for 1 week and then will clean it if no complaints are received.

Edit: Update URL to Mobile CI and update the description of bug which we hit

Last month I had opportunity to visit the Almería, Spain for Akademy 2017. Akademy 2017 is KDE’s annual world summit. Akademy makes it possible to meet the felow KDE contributors, some of whom you only know with their IRC nicknames (Yes, I am not old enough to know every contributors yet :p). Here is few things I did at the Akademy 2017.

Plasma Mobile

On the 2nd day I presented a talk about Plasma Mobile, Slides for that talk is available here. This talk covers various topics,

• Achievements of Plasma Mobile project for year 2017
• Project Halium
• New devices

In addition to all the good things, I also discussed about the areas where Plasma Mobile project needs improvement and where community can help.

• Quality Assurance
• Testing
• Applications

There are several external factors which also matters for Plasma Mobile project,

• Kernel version are too old, hard to maintain security
• Lack of the open devices
• Devices requires closed sources BSP to function to full extent

I also talked about the postmarketOS project which aims for the 10 year life-cycle of the phones, postmarketOS is currently using the weston as their reference user interface, and have interest in using Plasma Mobile as the reference user interface.

I also talked about various programs which are working towards the open devices,

• Open devices program by Sony
• Effort to support the devices by mainline kernel
• Fairphone
• Purism’s Linux Phone(?)

Video recording for this talk is not available yet, but it will be available at files.kde.org soon.

We also had scheduled a Plasma Mobile BoF, where we discussed about the Plasma Mobile Vision, Strategy, Convergence and more planning with rest of the Plasma Team.

KDE Student Programs BoF

In addition to being maintainer of Plasma Mobile project I am also the part of KDE Student Programs Adminstration team, on Tuesday we organized a BoF session where students, mentors and admins from various programs such as GSoC, GCI, SoK, OPW took part and discussed how we are doing in this year’s programs, Good or bad? Where we needs to improve? Overall this was quite productive discussion.

KDE Neon BoF

I also participated in the KDE Neon BoF, in KDE Neon BoF I mainly discussed the addition of ARM architecture in the Neon CI and also took lessons about how OpenQA is used on the KDE Neon CI. I do plan to use the OpenQA eventually for Plasma Mobile images.

Conclusion

Overall this was very productive Akademy, where we discussed various topics which are typically hard to discuss over the communication media like E-mail or IRC. I would like to thank the KDE e.V. for covering my flight and accomodation cost to attend the Akademy. I will have another chance to attend another event next month : Randa Meetings 2017. This year’s randa meetings main topic is Make KDE more accessible.

However to make Randa Meetings possible KDE community needs your help, Please donate at Randa Meetings 2017 Fundraising Campaign.

Last week I had a chance to attend the Randa meetings 2017, my plan was to work on the Plasma Mobile during the sprint, improve the state of current images. A few things changed over the course of the week:

New shiny wallpaper and packages

Starting from 8 Sept, we started using the packages from KDE Neon buildsystem instead of building them on the Plasma Mobile CI, this provides few benefits,

• No need to separately build the common things like Qt5, KDE Frameworks, Plasma
• Always up-to-date packages, no need to manually re-trigger builds for common things

We also upgraded to newer version of Qt, Qt 5.9 from the older version of Qt 5.7.1, this aligns our stack with whatever KDE Neon dev unstable edition is using.

Rootfs for non-nexus Qualcomm devices

Non-nexus Qualcomm devices use a modified version of the hwcomposer.h which is not ABI compatible with the generic version of the android API headers, so for them the libhybris and kwin need to be separately built. Previously our CI infrastructure didn’t support this workflow, however now we are able to create the rootfs for such devices. Below is an image of Plasma Mobile running on Xiomi Mi device.

Marble maps

At Randa, we had a chance to test the newer version of the Marble maps, which has much more improved performance when zooming out-in. We were able to happily search locate Randa in the Marble maps.

QML based mobile friendly “konsole”

Previously we were using Konsole from the KDE Applications as a terminal emulator, however Konsole user interface was not mobile-friendly, and it was not possible to e.g, tab complete the command, go through history, etc. At Randa Emmanuel Lepage Vallee pointed us to qmltermwidget, which powers the terminal application in Ubuntu Touch and Cool-retro-term application. Marco Martin was able to write a simple QML application around qmltermwidget which can replace Konsole in Plasma Mobile.

Kirigami based koko

During GSoC 2017 lot of work has been put to port the normal QtQuick based image viewer application Koko to kirigami2, you can follow the work of Student developer Atul Sharma on his blog. At the Randa Sprint, we were able to test this work on Plasma Mobile and it shows great improvements compared to the older version.

Improved window switching experience

Due to a bug in the Plasma Mobile shell, shell windows such as task switcher and shell itself were also appearing in the task switcher, as a result of that user was able to close the shell window which ultimately ends up crashing the plasmashell. We were able to fix this bug in the plasma-workspace and plasma-phone-components so that Plasma Mobile shell windows would not appear in the task switcher.

Kube(!!!)

Yes, that is Kube in the first picture, we were able to run the Kube on the Plasma Mobile, it works in theory on Plasma Mobile, however the user interface is not mobile-friendly and needs various fixes to be usable on mobile. We will work with the Kube team to fix the issues and then test them on Plasma Mobile in the future.

Conclusion

That is all for now, I would like to thank the all the donors who donated for the Randa Meetings 2017, and made it possible for me to travel to Randa, Switzerland.

If you liked the work done on Plasma Mobile during the Randa Sprint, please support us on Randa 2017 fundraiser to make events like Randa possible in the future.

If you want to develop for Plasma Mobile, but you don’t have a Mobile device, it is useful to emulate a Plasma Mobile on your desktop or laptop. Earlier this was not documented and has been asked multiple times on how to achieve this.

This blog post is intended to help install a Plasma Mobile on the qemu-x86.

• First of all create a qemu-image of 10GB size.

qemu-img create -f raw neon-unstable.img 10G

• Download the KDE Neon Dev edition (git unstable) ISO. Link
• Start the qemu system with the downloaded the KDE Neon ISO.

qemu-system-x86_64 -cdrom /path/to/neon-devedition-gitunstable-current.iso -boot menu=on -drive file=/path/to/created/neon-unstable.img,format=raw -vga virtio -display sdl,gl=on -m 2G -enable-kvm

• This will boot the KDE Neon system with Plasma Desktop. You will need to use Calameras to install the Plasma on the virtual machine.

• Once installed, shutdown the virtual machine and restart the machine without ISO attached.

qemu-system-x86_64 -boot menu=on -drive file=/path/to/created/neon-unstable.img,format=raw -vga virtio -display sdl,gl=on -m 2G -enable-kvm

• In the virtual machine, open konsole and add the repository for Plasma Mobile.

curl http://neon.plasma-mobile.org:8080/Pangea%20CI.gpg.key | sudo apt-key add -
sudo add-apt-repository http://neon.plasma-mobile.org:8080

• Install the updates

sudo apt update && sudo apt upgrade

• Install the Plasma Phone shell and configuration for Plasma Phone.

apt install plasma-phone-components plasma-phone-settings

• Logout from the Desktop Session and select the Plasma Mobile (Wayland) session.

• This steps will start Plasma Mobile session.

Please note that this steps are experimental at the moment, I am working on providing pre-built ISO images which will not require the KDE Neon developer edition ISO.

Last week we asked the Free Software community what they wanted to do to help us move forward with Plasma Mobile. These were the results from the poll on Twitter:

And this was what the poll on Google+ looked like:

As you can see, the results were similar with least 44% poll participants wanting to test Plasma Mobile on their device, and/or as a virtual machine, or on real machine. Testing this on virtual machine was quite a hack earlier as explained in a previous blog post. We had no dedicated ISO image for Plasma Mobile, to test the Plasma Mobile one had to install KDE Neon developer edition and then run a few commands to convert it to a Plasma Mobile installation.

But, this week, by popular demand, we are providing an x86_64 based ISO images you can download from Plasma Mobile images server.

How to test

You can download the latest ISO and boot in either Virtual Machine or boot it on real machine.

QEMU/KVM

VirtualBox

On actual device

Things to try

• Add a widget to the desktop

• Download and install an app from Discover Software Center

• Read comics in Peruse

• Test Kaidan, the XMPP client

Disclaimer

This software is Alpha! Use it at your own risk. This software is not recommended for use in production and many core functionalities will probably not work. This version is intended for testing some features and for preview only. Plasma Mobile is not yet at a level where it can substitute the operating system currently running on your mobile phone, but with your help, we will get there.

How to send us feedback

You can reach us on plasma-mobile@kde.org mailing list, or #plasma IRC channel on Freenode, or #plasmamobile:matrix.org matrix room, or on Plasma Mobile telegram group.

Thank you for helping us test Plasma Mobile.

2nd part of this series will focus on testing Plasma Mobile on actual mobile devices instead of virtual machine or PC/laptop

The first part of this series focused on testing Plasma Mobile on virtual machine and/or on a PC/laptop. In this second part we will focus on testing Plasma Mobile on actual mobile devices.

Currently there are two possible ways of testing Plasma Mobile on an actual mobile device,

• Using postmarketOS
• Installing Halium and a KDE neon-based rootfs

I will explain both methods briefly in this blog post. Note that some of these steps may involve getting device-specific sources and building them manually, This may require a intermediate knowledge of how to unlock the bootloader, flashing and restoring devices and basic knowledge about various UNIX/Linux commands.

Using postmarketOS

postmarketOS is touch-optimized, pre-configured Alpine Linux-based distribution which offers Plasma Mobile as one choice of several available user interfaces.

There is a list of the devices that can run postmarketOS, and you can find instructions on installing postmarketOS on your device at their wiki page.

When you follow the instructions to install postmarketOS, remember to select “plasma-mobile” as the user interface when asked:

Available user interfaces (5):
* none: No graphical environment
* hildon: (X11) Lightweight GTK+2 UI (optimized for single-touch touchscreens)
* luna: (Wayland) webOS UI, ported from the LuneOS project (Not working yet)
* plasma-mobile: (Wayland) Mobile variant of KDE Plasma, optimized for touchscreen
* weston: (Wayland) Reference compositor (demo, not a phone interface)
* xfce4: (X11) Lightweight GTK+2 desktop (stylus recommended)
User interface [weston]: plasma-mobile

An important thing to note about postmarketOS is that it also offers Plasma Mobile on devices running mainline kernel, for example on the Sony Xperia Z2 tablet, Google Nexus 7 (2013), and LG Nexus 5 (partially). More information about Plasma Mobile on postmarketOS project can be found at the Plasma Mobile wiki entry.

Video below shows Plasma Mobile running on the Sony Xperia Z2 Tablet, which is running on mainline kernel instead of the pre-installed older kernel version.

However note that the postmarketOS project is still at very early stages of development and is not suitable for most end users yet.

Installing Halium and a KDE neon-based rootfs

Halium provides the minimal android layer that allows a non-Android graphical environment to interact with the underlying Android kernel and access the hardware. The Plasma Mobile team provides a Neon-based rootfs which can be used along with the Halium builds. Currently Halium has been ported to multiple devices, however, binary builds are not provided because most of them include binary blobs which we cannot redistribute them legally. Instead we provide a link to the source manifest and you can use that to build your own images. Documentation on how to build and install Halium is available at the Halium website.

Plasma Mobile on Nexus 5 and Nexus 5X is using the Halium based images, binary images for those are distributed at Plasma Mobile image server as a reference for other porters and developers for easy testing. You can install on those devices using the flashtool available on Github.

Plasma Mobile reference images are based on halium, which uses the propietary binary blobs to make use of phone hardware. This requires the libhybris which allows us to use bionic based binary blobs in the traditional libc based environment. Halium based devices also use very old vendor-provided kernel trees, these vendor trees generally range from version 3.4 to 3.18, most of the kernel versions listed here are already marked as EOL on kernel.org.

Greg KH addressed this issue in a 3.18.48 kernel announcement email rant:

> Oh, if you are _stuck_ on 3.18 (/me eyes his new phone), well, I might
> have a plan for you, that first involves you yelling very loudly at your
> hardware vendor and refusing to buy from them again unless they cut this
> crap out. After you properly vent to them, drop me an email and let's
> see what we can come up with, you aren't in this sinking ship alone, and
> it's obvious your vendor isn't going to help out...

It’s however very clear that yelling at device vendor hasn’t really helped and we’re still seeing the new devices arriving on the market shipping Linux kernel version 3.18. There are some very new phones in market which use Kernel version 4.4, however these devices are so expensive that it is generally not feasible for many people to buy them.

So, how do we solve this issue? Projects like postmarketOS tries to solve this issue by using only open source components provided by vendors and avoiding binary blobs, but generally this doesn’t really result in usable system as it will not allow us to use Hardware Acceleration and other hardware features. Another solution is to use the mainline kernel, which is actively maintained and developed by the Linux Kernel community.

Little while after I started working on Plasma Mobile I stumbled upon the Android running on Nexus 7 with mainline kernel and wondered what it would take to get Plasma Mobile running on the device which runs the mainline kernel and a fully free software stack. In the process, I learned about how to mainline and asked the folks in ##linux-msm and #freedreno channels for help. Thanks to @bamse, @agross, @robclark I managed to add initial support for Nexus 5 board in the mainline kernel. This was merged into Linux kernel version 4.9. However this didn’t really support useful features other then serial console over headphone jack, power and volume buttons. After adding initial support for hammerhead in mainline kernel I was not able to continue the work due to time constraints.

Similar to hammerhead, community member opendata, a contributor to postmarketOS project, very recently managed to run Plasma Mobile on the Sony Xperia Z2 tablet. While the device came with a Linux kernel version 3.4 from the provider, @bamse managed to port 4.X Linux kernel version to that device. Recently I learned that community member flto has continued the work I started a while ago, and has been more successful in hardware support then I initially was.

This week I decided to provide a pre-built Plasma Mobile image which can work with the mainline kernel. Current Plasma Mobile images are based on KDE Neon, which uses Ubuntu 16.04 Xenial as an underlying base. Unfortunately the version of Mesa in Ubuntu’s repos were too old. Thankfully, community member JBBgameich has been maintaining the apt repository for Debian buster which included packages for Plasma Mobile. After some work to create a rootfs I successfully managed to boot a Plasma Mobile image on the Nexus 5 running a mainline kernel with mesa and freedreno graphics driver.

Using the same image as me, opendata was also able to run Plasma Mobile on the Sony Xperia Z2 tablet. Below is snapshot of the Kinfocenter application showing the system information.

Currently these images are mainly experimental and super-unstable, they aren’t really ready for production at all. However it proves that Plasma Mobile is capable of running on devices which support the mainline Linux kernel and fully free software stack. This will ultimately be useful for all the new projects working on free and open mobiles, such as Sony’s Xperia open devices, Purism’s Librem 5, since Plasma Mobile is committed to providing fully free and open source software for every device.

Despite the usual warnings that it may eat your kittens, if you want to try it on your device which is supported by mainline kernel, please contact us on Matrix at #plasmamobile:matrix.org or over email at plasma-mobile@kde.org

Thanks to KDE Plasma team, @JBBgameich, @opendata, @flto, @bamse, @robclark, @agross, postmarketOS community, Debian Qt/KDE team for making this possible

Find your own way to help develop Plasma Mobile

The Plasma Mobile project was started by the KDE community with the goal of becoming a free, user-friendly, privacy-enabling and customizable platform for mobile devices. We are always on the look out for more contributors to help push Plasma Mobile forward. However contributions to Plasma Mobile has high entry barrier due to various reasons, among which are the lack of documentation and easily available open tasks for Plasma Mobile.

One of the goals KDE community has set itself is to streamline the onboarding of new contributors. With this goal in mind, we intend to solve the issue of the high entry barrier for contributors that affects the Plasma Mobile project and, along with KDE Promo team, we have set up various tasks:

• Grow the number of developers and community support for Plasma Mobile
• Grow Plasma Mobile: Collect data
• Grow Plasma Mobile: Goal: Onboarding of new contributors

While working on one of tasks to collect data we learned that users want an easy way to test Plasma Mobile and, to meet this requirement, we worked on the easily installable imageswhich can be tested on either a virtual machine or on real hardware. Check out the two parts series we wrote about that. You can find out how to do this in part 1 and part 2 of our blog post on the subject.

Like the rest of the KDE community, Plasma Mobile is using Phabricator to track and manage the task list. You can find the following tasks on Phabricator:

• Plasma Mobile project board, which includes all tasks.
• Plasma Mobile PM 1.0 milestone which includes the tasks needed to be done to get Plasma Mobile to a basic 1.0 state.
• Plasma Mobile PM 2.0 milestone which builds upon the functionality provided in the 1.0 milestone.

We realised that for new contributors these tasks can be hard to find and difficult to navigate through. To help with this we created another task to help potential contributors easily find the tasks they can work on. Thanks to Dimitris Kardarakos, we now have a web-page on plasma-mobile.org which provides a set of question-answer nodes and leaf nodes pointing to various phabricator tasks. This system is based on the code used by Mozilla to power similar website.

You can navigate through various tasks and TODO items from https://www.plasma-mobile.org/findyourway/.

In addition to make the tasks easy to reach, we have also worked on revamping the existing Phabricator tasks. See T6942, for example, that asks that someone create a calendar app for Plasma Mobile. An earlier version of this task didn’t contain much useful information on how such an application could be created. The task was edited to include more information on which libraries you can use, references, knowledge requirements and system requirements for developing and testing such an application.

We hope this will make it easier for you to get involved in the Plasma Mobile project. In order to make it easier for you develop and test applications, we are also working on the developer guide. I will announce it here when the guide is completed (spolier alert: easy to use docker images to test your applications). You can send questions by contacting us on Matrix at #plasmamobile:matrix.org or over IRC at irc://chat.freenode.net/#plasma or over email at plasma-mobile@kde.org. We will be happy to listen to your feedback.

Looking forward to your contributions!

In June month we gathered in Slimbook’s offices to work on Plasma. Along with Plasma developers, we were also joined by KDE Usability and Productivity team.

During the sprint I mostly worked to create up-to-date image for Plasma Mobile, as from last few weeks Plasma Mobile image was quite out-of-date and needed update.

Some of the bugfixes we did includes,

• Workaround for potentially broken Qt 5.12.3, using basic render loop instead of threaded.
• Fix for the regression in Window placement, sizing (Thanks to Aleix and David for help on this)
• Fixing WiFI settings on mobile

Apart from Plasma Mobile, I worked on general Plasma bugfixes as well,

• Behavior change in plasma-framework PluginLoader to fix behavior of X-KDE-ParentApp entries
• Fix for regression of the double locksceen in Plasma session

If you want to know overall progress made in the Plasma + Usability & Productivity sprint, then you can take a look at dot story for more detailed sprint report.

Thanks to Slimbook for hosting us and KDE e.V. for sponsoring my travel!

Also, I am going to Akademy 2019, and talking with Marco Martin about Plasma on embedded devices.

Akademy 2019 was hosted in the Milan, Italy. I had opportunity to attend the event and meet the other KDE developers, designers and users.

Talks

There were many interesting talks, including use of opensource in government, flying drones, virtual reality and several community related topics. Honestly it is impossible to list all the awesome talks I attended here, so go and check schedule for list of talks and slides. However I want to highlight the one talk which I gave,

Plasma on embedded devices

In Akademy 2018, I gave a talk about Plasma on mobile devices. Talk discussed why it is harder to run a Linux userland on the off-the-shelf mobile devices. This year I and Marco presented a slightly different topic, Plasma on embedded devices. Talk was about what solutions are offered by the KDE community for such embedded devices, and what efforts are being made.

Marco Martin also presented a new shell package, plasma-nano, which is a minimal shell you can extend to create a Plasma based user interfaces for embedded devices.

Birds of Feather sessions

Gitlab community & Workflow

Gitlab developers Alessio Caiazza, Jacopo Beschi and Ray Paik hosted a BoF session about the Gitlab workflow, and how to contribute to Gitlab. It was interesting BoF to attend. Seeing as KDE is working on adoption of the Gitlab for it’s code-hosting. It was quite useful session to attend.

Plasma Mobile

On Tuesday, We hosted a Plasma Mobile BoF, where we discussed topics ranging from general shell user-interface to the applications, topics which were discussed includes,

• File chooser implementation for Plasma Mobile: Currently it just shows the desktop based file dialog, which is not user friendly on mobile
• Start-up speed improvements for shell and applications
• Updating the information on Plasma Mobile website
• Documentation and developer experience, and how to improve it
• Various application specific issues
• Hosting a Plasma Mobile sprint in 2020
• Status of Packaging for Plasma Mobile in various distribution

Overall, it was quite productive BoF, even though we were constrained by the time!

Plasma on Devices

As a extension to our talk, Marco and I hosted a “Plasma on devices” BoF. Where we demostrated the Plasma Nano shell. Talked about the infrastructure we have currently in the Plasma, and also talked about how we can make this more interesting for hardware vendors.

KDE PIM

As Plasma Mobile is making various improvements, one of the requirement is the personal information management applications like Calender, Email, Contacts will be needed, I attended the KDE PIM BoF to discuss how best these two teams (Plasma Mobile and KDE PIM) can work together, you can find out more details abut this in Volker Krause blog. In general we discussed following topics,

• Moving of KCalendarCore and Kcontacts to KDE Frameworks
• Moving of the KDAV protocol library to KDE Frameworks
• Plugin Infrastructure in the KCalendarCore
• KAccounts integration in the KDEPIM

KDE India

Indian KDE-ers (is it even word? I made it up) met together to discuss the possible location and dates for next conf.kde.in, and how better we can improve the conf.kde.in organization procedure. There were several possible venues and dates were suggested by the attendees.

Sysadmin

Ben Cooksley hosted a KDE sysadmin BoF, where we discussed various topics related to our infrastructure, and scale of data/traffic we have to handle. We also agreed upon some internal todo items to work on in future.

Online Accounts Integration in KDE

As a follow-up to KDE PIM BoF, I and Daniel Vrátil hosted a Online Accounts integration BoF, where we discussed various topics,

• Current state of kaccounts infrastructure
• Possible API improvements for KAccounts
• Where we can make use of the KAccounts in KDE

Student Programs

We hosted a BoF session to talk about the KDE Student Programs, Google summer of Code, Season of KDE, and GCI. We also discussed the timeline and structure of Season of KDE program. Short note that I will be attending Google Summer of Code 2019 Mentor summit in Munich later this week.

Closing thoughts

Overall quite exciting event, I would like to thank KDE e.V. for sponsoring the accomodation and travel. It is quite awesome to meet community in-person and share ideas, and learn new things!

I am happy to announce the v0.1 release of the keysmith.

Keysmith is Two-factor code generator for Plasma Mobile and Desktop.

You can get first release from the

https://download.kde.org/stable/keysmith/0.1/

It has been gpg signed by my personal key with fingerprint

0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

Please note that this is a v 0.1 release and there are known issues with Keysmith. In particular the storage of secrets for tokens is not implemented securely yet. Only use this for testing purposes, do not use this with real account data just yet. This release is for you if:

• you are excited about an app for KDE for 2 factor authentication and want to get involved
• you are a packager who want to get a head’s start so you are well prepared for v1.0 when it finally lands

Again, please do not use this for real accounts yet: Keysmith is not secure at this point. But you can help! If you want to help out head over to https://invent.kde.org/kde/keysmith/issues/.

Last week I was in Bluesystems GmbH meeting in Germany, almost 7000 km away from home. While one would hope that this journey is smooth, of-course this was not case for my journey. I missed my phone in first segment of journey (which now is on route to my home as I write). In 4 hours of layover I tried to retrieve my phone but unfortunately it was already with Lost and Found team and getting that would require me going through immigration etc. Thankfuly I had a LG Nexus 5X which I generally use to test out Plasma Mobile builds, In hurry I flashed LineageOS on it and downloaded some basic applications I needed on it. In second lag of journey I spent time copying some of required documents and files to mobile device.

Fast-forward 2 days, my Nexus 5X decided that it is time to give up. After turning off screen, it won’t turn back on. I tried charging it for few hours but no luck. I did not need mobile while I was in meeting, since I was having meeting and stay at same place. I was able to communicate with my family and friends over telegram. But when I needed to travel back home, I realized while I can survive without mobile device, it won’t be largely fun.

Preparing PinePhone

While I had no android device with me, I had a PinePhone developer prototype¹, which can run Plasma Mobile among others! So I decided to see if I can make use of Plasma Mobile while traveling back? My use-case was in general very limited,

• Minor web browsing
• Hotel check-in
• Boarding train and flights
• Searching for public transport options
• Communication

I generally don’t use my SIM cards abroad due to high international roaming charges so I didn’t need working calls yet. So with absolute minimal requirement in mind I started setting up my pinephone.

Web browsing

Plasma Mobile have a Angelfish web browser, which is using QtWebengine and Kirigami user interface. Out of the box the QtWebengine doesn’t work with Mali400-MP2 being used in the PinePhone, however internally chromium manages the workarounds specific to graphics drivers. One such workaround is available already for the Mali400, however it is tested only with binary driver released by Allwinner, and not opensource Lima driver. So we needed to adjust the workaround to match opensource lima driver as well.

--- qtwebengine-everywhere-src-5.13.2/src/3rdparty/chromium/gpu/config/gpu_driver_bug_list.json 2019-08-09 21:46:06.000000000 +0800
+++ qtwebengine-everywhere-src-5.13.2.new/src/3rdparty/chromium/gpu/config/gpu_driver_bug_list.json     2019-12-03 23:49:02.230915250 +0800
@@ -908,8 +908,7 @@
       "id": 108,
       "cr_bugs": [449150],
       "description": "Mali-4xx does not support GL_RGB format",
-      "gl_vendor": "ARM.*",
-      "gl_renderer": ".*Mali-4.*",
+      "gl_renderer": ".*Mali-*4.*",
       "features": [
         "disable_gl_rgb_format"
       ]

This patch allows one to browse web using angelfish.

Hotel check-in and Boarding train/flights

I was staying in Frankfurt for one day since my flight was early morning next day. So I needed to check in the hotel and also board two trains to reach Frankfurt. While I had paper copy of the bookings with me, using them is boring! wink

I decided to use the itinerary application for checking in the hotel and traveling on trains. Itinerary allows you to import and manage various bookings and boarding passes. While I managed to import the booking for my hotel, I had trouble importing booking for train and my flight’s boarding passes. Investigation of the issue showed that itinerary was not built in neon with zxing-cpp dependency. zxing-cpp allows to scan and decode various types of barcodes and QR codes; Which are commonly used in Flight and Train boarding passes.

Adding zxing-cpp dependency in kitinerary package solved issue and I was able to import all my boarding passes. After importing them I was able to use them at most places without any problem².

Searching for public transport options

I needed to search for public transportation while in Frankfurt. I used ktrip application to find my way around the Frankfurt, in general it is quite easy to use,

1. Enter your start point and end point
2. Enter the time you want to depart at
3. Find connections!

While I can make use of the maps at train station and bus station as well, Being able to get this information directly from your mobile device was quite useful.

Communication

During travel I was able to connect with friends, family and colleagues using Telegram messanger, I was able to easily install it using Discover software center. Since I was on KDE Neon, which have it’s own Qt packages I decided to use the version from flathub. While telegram itself worked flowlessly, I had minor annoying issue that if someone sends animated sticker in chat, my Telegram application would crash opening that chat. I haven’t investigated issue further, but it could be bug in telegram or issue with graphics driver, it is hard to tell at moment. While I only wanted to use the Telegram, one can use Kaidan for XMPP and Spectral for Matrix chats as well.

Conclusion

Overall it was much smoother experience to use the Plasma Mobile as a daily driver. I realized that while it is definitely not ready for the average user, there are variouse areas where we can improve most and make a impact.

• Working calls: This is absolute must for using daily driver. I hope that we can solve audio routing issues on Pinephone soon.
• Power management: Currently in case of Plasma Mobile, operating system is not optimized for this at all. It is definitely a new horizon for us and we can do lot there.
• User interface responsiveness: I realized that there are lot of places where we can improve the general responsiveness of user interface and application
• More applications: While my usecase was quite limited in terms of what I wanted to do with my phone, I am sure people have very different usecases of their phone and that includes lot more applications then we have currently.

While this blog post is focused on my usage of software on Pine64 PinePhone, If you are looking for hardware review, you can take a look at post by Martijn Braam comparing the Librem 5 and PinePhone hardware. That provides much more detail on hardware of PinePhone.

If you are excited about Linux smartphones and want to help us progressing Plasma Mobile forward, you can reach us at #plasmamobile:kde.org matrix room.