Installing LineageOS in the Sony Xperia XZ2 Compact Dual (in GNU/Linux) 5/5: Appendixes

WARNING

I have no responsibility whatsoever if this guideline causes any harm to your device. The intention of these posts are solely as personal notes for myself. Follow them at your own risk.

WARNING

Through these steps I will unlock the phone’s bootloader, erasing all data. This includes the DRM keys stored in the Trim Area (TA) partition. I’ll attempt backing them up but, as of today, there is no way of restoring them to the previous state nor knowing if the actual backup is usable at all.

Without these DRM keys, several audio and video proprietary functionality provided by Sony won’t be available including some camera post-processing features, color gamut profiles, white balance, noise reduction, X-Reality Video Enhancement, DSEE HX, ClearAudio+, and Widevine L1 support for HD Netflix.

Appendixes

Previously, we downgraded Sony’s Stock firmware, backed up the Trim Area, installed LineageOS, and, finally, bring back Sony’s stock camera app.

The installation had some bumps, so here a list of the things I could comment about …

Installing TWRP

I wanted to install the TWRP recovery tool just because I have experience with it and like it better. I did and used it successfully in the first installation of the LineageOS that I did. However, the LineageOS installation also installed the Lineage Recovery so I lost TWRP and, funnily enough, the steps I followed to install TWRP won’t work any more. Hence, I’m stack with the Lineage Recovery and that’s why I explain how to directly install Lineage Recovery in the previous post.

For the curious, these are the steps I followed.

First, we need to download the Unofficial TWRP recovery and extract it in a folder. After this I rebooted the device in fastboot mode via software. This is important. Don’t do it using the hard keys.

Once in fastboot mode:

root$ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
[...]
root$ fastboot boot twrp-apollo.img

This will boot temporarily into TWRP. Now, we need to do the actual flash of TWRP. First, we need to copy the image:

root$ adb push twrp-apollo.img /tmp

And, from TWRP: Advanced menu -> Install recovery ramdisk -> Choose /tmp/twrp-apollo.img. After finishing installing TWRP, we can reboot into Recovery using the newly installed TWRP.

From there, you can also wipe the system and data and install LineageOS, Open GApps and Magisk. Interestingly, TWRP provides the possibility of pushing these files and installing without using adb sideload. This is interesting because it will make also easier to install a customized Open GApps package using the gapps-config file.

Notice that, more often than not, when booting into TWRP recovery the touchscreen wouldn’t work. This is a random behavior and rebooting again into Recovery may fix it in the next try.

Installing the Android System Webview from the Open GApps

As mentioned, I wanted to customize Open GApps to install the Android System Webview.

I did.

However, choosing this will only install a Google WebView Stub. What this means is that you won’t really have a WebView and, hence, when booting in the system, anything which makes use of a WebView will just crash (including registering into Google for using Google Play).

In other words, you need to install the real package but you won’t have an easy way of doing that. You will have to manually download the real APK from some 3rd party site and install it, for example, with adb install.

In the end I just reinstalled without it after reading that the WebView used by LineageOS is based in Chromium. So far so good.

Migration from my older phone

In order to move all my data from my Xiaomi Redmi 2 running LineageOS 14.1 I used the OAndBackupX application. It needs root rights but, fortunately, I had them in both systems and devices.

Some comments:

  • Make sure of using the exact same version of OAndBackupX in both devices.
  • The app suggests to use encryption when creating the backups. I didn’t use it since it was doing things more complicated.
  • I only did back ups of the user applications. First I also did back ups of the special cases (user accounts, for example) and after restoring, that caused me a headache with NextCloud and DavX⁵. Of course, jumping from 14.1 to 17.1 could cause these kind of troubles.

I initially used a SD Card to move the back ups. I wouldn’t recommend it now. If you have limited memory just create the back ups in steps and move them in batches using adb. With both devices plugged with USB cables and in developer mode:

root$ adb devices
List of devices attached
origin device
destination device

root$ adb -s origin root
restarting adbd as root
root$ adb -s destination root
restarting adbd as root
root$ # Create some backups in the origin device
root$ adb -s origin pull /storage/emulated/0/OABX .
[...]
root$ adb -s destination push OABX/* /storage/emulated/0/OABX/
[...]
root$ # Restore the backups in the destination device
root$ adb -s origin shell
origin:/ $ rm -rf /storage/emulated/0/OABX/*
origin:/ $ exit
root$ adb -s destination shell
destination:/ $ rm -rf /storage/emulated/0/OABX/*
destination:/ $ exit
root$ # Create some more backups in the origin device and repeat the process

Of course, no need to delete the back ups if you don’t need to.

Installing LineageOS in the Sony Xperia XZ2 Compact Dual (in GNU/Linux) 4/5: Bringing back Sony’s stock camera app

WARNING

I have no responsibility whatsoever if this guideline causes any harm to your device. The intention of these posts are solely as personal notes for myself. Follow them at your own risk.

WARNING

Through these steps I will unlock the phone’s bootloader, erasing all data. This includes the DRM keys stored in the Trim Area (TA) partition. I’ll attempt backing them up but, as of today, there is no way of restoring them to the previous state nor knowing if the actual backup is usable at all.

Without these DRM keys, several audio and video proprietary functionality provided by Sony won’t be available including some camera post-processing features, color gamut profiles, white balance, noise reduction, X-Reality Video Enhancement, DSEE HX, ClearAudio+, and Widevine L1 support for HD Netflix.

Bringing back the stock camera

In the previous posts we have downgraded the stock firmware from Sony, backed up the Trim Area (TA) partition and installed LineageOS.

Thanks to the great people from the xda-developers forum we have the chance to add Sony’s stock camera app. We will adb sideload it the same way we installed Magisk in the previous post, for example

First, the zip is called SemcCamera (SemcCamera-xz2c-52.1.A.2.1.zip at the moment of writing this) and it is, currently, the only add-on available for the Official LineageOS 17.1 image for the xz2c phone.

We download the file, reboot into Recovery Mode and plug the phone to the computer with the USB cable. Select Apply Update -> Apply from ADB:

root$ adb sideload SemcCamera-xz2c-52.1.A.2.1.zip
Total xfer: 1.00x

Now, Go back -> Reboot system now.

Currently, the stock camera won’t work out of the box. It needs to disable SELinux or set as Permissive. Luckly, since we have Magisk installed and we can grant root privileges, we can install SELinuxModeChanger and do so.

That’s it, now you should be able to use Sony’s stock camera!

Extra treat: add Sony’s Bokeh app

Sony also provides a nice application for taking fancy photos: Bokeh (Background defocus).

Unfortunately, we cannot install it just from Google’s Play Store since it claims that the app is not compatible with this phone.

However, we can force the installation, for example, using the Aurora Store.

Finally, if you want to know about some bumps I got during the road, continue to the Appendixes.

Installing LineageOS in the Sony Xperia XZ2 Compact Dual (in GNU/Linux) 3/5: Installing LineageOS

WARNING

I have no responsibility whatsoever if this guideline causes any harm to your device. The intention of these posts are solely as personal notes for myself. Follow them at your own risk.

WARNING

Through these steps I will unlock the phone’s bootloader, erasing all data. This includes the DRM keys stored in the Trim Area (TA) partition. I’ll attempt backing them up but, as of today, there is no way of restoring them to the previous state nor knowing if the actual backup is usable at all.

Without these DRM keys, several audio and video proprietary functionality provided by Sony won’t be available including some camera post-processing features, color gamut profiles, white balance, noise reduction, X-Reality Video Enhancement, DSEE HX, ClearAudio+, and Widevine L1 support for HD Netflix.

Upgrading to latest stock firmware

In the previous posts we have downgraded the stock firmware from Sony and backed up the Trim Area (TA) partition.

Since the guideline to install LineageOS mandates that we have the latest stock firmware from Sony running in the phone, I upgraded now from the downgraded exploitable version.

Using the built-in updater doesn’t seem to work any more (?!) so I had to flash the latest stock firmware in a similar fashion as I did for downgrading.

I already downloaded the firmware and it is already properly extracted so, in this case, I won’t need to use flashtool, only newflasher.

These would be steps to follow once I connected the phone to the USB cable in flashable mode:

root$ rm "H8324_Customized NOBA_1313-6167_52.1.A.3.49_R4C"/*ta
root$ rm "H8324_Customized NOBA_1313-6167_52.1.A.3.49_R4C"/boot/*ta
root$ cp -a newflasher.x64 "H8324_Customized NOBA_1313-6167_52.1.A.3.49_R4C"
root$ cd "H8324_Customized NOBA_1313-6167_52.1.A.3.49_R4C"
root$ chmod +x newflasher.x64
root$ ./newflasher.x64

[...]

Reboot mode at the end of flashing:
typa 'a' for reboot to android, type 'f' for reboot to fastboot, type 's' for reboot to same mode, type 'p' for poweroff, and press ENTER.
a

[...]

Optional step! Type 'y' and press ENTER if you want dump trim area, or type 'n' and press ENTER to skip.
Do in mind this doesn't dump drm key since sake authentifiction is need for that! But it is recommend to have dump in case hard brick!
n

[...]

Recommended step to skip this! Type 'y' and press ENTER if you want flash persist partition, or type 'n' and press ENTER to skip.
More info https://forum.xda-developers.com/xperia-xz1-compact/help/android-attest-key-lost-bootloader-t3829945
n

[...]

Device is put now out of flash mode.
Sent command: Sync
Waiting sync to finish…
……………… done
Sent command: continue.
Done.
Closing device.

Notice the questions and the answers. After a while, the phone will complete its reboot and we will be able to verify that the running firmware is the one flashed.

As explained in the previous posts, enable once again developer mode and USB debugging in the phone. For the next steps, enable also OEM unlocking in the developer options.

Installing LineageOS

We’ll follow the official guide.

First, we’ll unlock the bootloader. This will finally wipe out the TA partition losing the DRM keys. This is a point of no return.

I checked that my phone’s bootloader can be unlocked. I opened the phone application and dialed *#*#7378423#*#*. The service menu is now open. Go to Service info -> Configuration and checked that the Rooting status: states Bootloader unlock allowed: Yes. Also, noted down the IMEI.

Now, I connected the device to my PC with the USB cable and continued to set it in flashable mode:

root$ adb reboot bootloader
root$ fastboot devices
[...] fastboot
root$ fastboot oem unlock 0x<insert your unlock code>
…
OKAY [ 16.947s]
finished. total time: 16.947s

Unplug and start the phone. As explained in the previous posts, enable once again developer mode and USB debugging in the phone.

At this point, I decided not to keep following the LineageOS guideline since it explains how to use the Lineage Recovery. Instead, I used the TWRP recovery tool just because I have experience with it and like it better. However, I don’t recommend it as I’ve explained in the Appendixes.

Therefore, I explain here the same steps than the official guide. Download the latest Lineage Recovery and LineageOS installation package and connect the device to your PC with the USB cable and continued to set it in flashable mode:

root$ adb reboot bootloader
root$ fastboot devices
[...] fastboot
root$ fastboot flash boot <lineage_recovery>.img

Power off the device and now turn it on into Recovery mode by pressing Volume Down + Power.

Now, being booted into the Recovery mode, I downloaded a pre-install copy-partitions-20200903_1329.zip tool and selected Apply Update -> Apply from ADB.

root$ adb sideload copy-partitions-20200903_1329.zip

Once finished, reboot again into Recovery mode: Go back -> Advanced -> Reboot to recovery. Once back, Factory reset -> Format data/factory reset. Once finished, let’s install LineageOS: Go back -> Apply Update -> Apply from ADB.

root$ adb sideload lineage-17.1-<date>-xz2c-signed.zip

Now, before booting into the system, we want to add some more stuff: Open GApps and Magisk.

Magisk is a suite for customizing Android. Most importantly, it provides root access to the device, which I wanted to have in order to create backups of the installed applications and restore them, among other things.

Open GApps will provided us the core functionality provided by Google for Android. Most importantly, it will provide us Google Play. It is critical to install this before booting for the first time into the system. Otherwise, we would have to repeat the Factory reset step and wipe out all our personal data before attempting to install it.

Open GApps provides different size packages. The recommended for LineageOS are the pico or nano, but nothing bigger. Since I’m a troublemaker, I also wanted to customize the package to include the Android System Webview and remove even further packages from the pico and nano packages.

Hence, I downloaded the stock package for the ARM64 platform and the 10.0 Android version.

For reasons that I explain in the Appendixes, I finally didn’t install the Android System Webview but did remove some packages any way. The way of customizing a package is through a gapps-config file. However, to use this method the installation cannot be done through adb sideload and, unfortunately, the Lineage Recovery only offers this way of installing packages into the system.

Luckily enough, the Open GApps package is no more than a zip file so I could embed my options directly into the installer. So, after installing the LineageOS system, I rebooted again into Recovery mode: Go back -> Advanced -> Reboot to recovery and, back in Recovery, let’s install Open GApps: Apply Update -> Apply from ADB.

root$ mkdir my_gapps
root$ cd my_gapps
root$ unzip ../open_gapps-arm64-10.0-stock-<date>.zip
root$ cat installer.sh # Added the following lines in bold

[...]

echo "Include" > "$TMP/my_config.txt"
echo "" >> "$TMP/my_config.txt"
echo "CalSync" >> "$TMP/my_config.txt"
echo "DialerFramework" >> "$TMP/my_config.txt"
echo "GoogleTTS" >> "$TMP/my_config.txt"
echo "PackageInstallerGoogle" >> "$TMP/my_config.txt"
echo "BatteryUsage" >> "$TMP/my_config.txt"
echo "Speech" >> "$TMP/my_config.txt"
echo "#GooglePay" >> "$TMP/my_config.txt"
echo "Translate" >> "$TMP/my_config.txt"

# Locate gapps-config (if used)
for i in "$TMP/aroma/.gapps-config"\
"$TMP/my_config.txt"\
"$zip_folder/.gapps-config"\

[...]

root$ zip -0 -r ../my_gapps *
root$ cd ..
root$ adb sideload my_gapps.zip

And, now, let’s install Magisk: Apply from ADB.

root$ adb sideload Magisk-v20.4.zip

Once finished we can finally Go back -> Reboot system now.

Congratulations, your Sony Xperia XZ2 Compact Dual is now running LineageOS 17.1!!!

I have to say that, so far, I’m quite happy with the phone. It is a huge improvement for me, coming from a Xiaomi Redmi 2.

However, the camera has lost some enhanced functionality so let’s continue to bring back Sony’s stock camera app.

Installing LineageOS in the Sony Xperia XZ2 Compact Dual (in GNU/Linux) 2/5: Backing up the Trim Area (TA) partition

WARNING

I have no responsibility whatsoever if this guideline causes any harm to your device. The intention of these posts are solely as personal notes for myself. Follow them at your own risk.

WARNING

Through these steps I will unlock the phone’s bootloader, erasing all data. This includes the DRM keys stored in the Trim Area (TA) partition. I’ll attempt backing them up but, as of today, there is no way of restoring them to the previous state nor knowing if the actual backup is usable at all.

Without these DRM keys, several audio and video proprietary functionality provided by Sony won’t be available including some camera post-processing features, color gamut profiles, white balance, noise reduction, X-Reality Video Enhancement, DSEE HX, ClearAudio+, and Widevine L1 support for HD Netflix.

Backup the TA partition

As explained in the previous post, enable developer mode in the phone.

Following this guide, download the latest Magisk release. At the time of writing this it’s v20.4.

Download the tama-mroot.zip with the needed exploit.

Push both archives into the phone (you may need to give consent in a pop up dialog in the phone):

root$ adb push tama-mroot/tama-mroot.zip Magisk/Magisk-v20.4.zip /data/local/tmp
tama-mroot/tama-mroot.zip: 1 file pushed. 0.5 MB/s (21355 bytes in 0.039s)
Magisk/Magisk-v20.4.zip: 1 file pushed. 32.0 MB/s (5942417 bytes in 0.177s)
2 files pushed. 25.4 MB/s (5963772 bytes in 0.224s)

Get into the phone and follow the steps to get a root shell:

root$ adb shell
H8324:/ $ cd /data/local/tmp
H8324:/data/local/tmp $ unzip tama-mroot.zip
Archive: tama-mroot.zip
inflating: magisk-start.sh
inflating: magisk-setup.sh
inflating: tama-mroot
H8324:/data/local/tmp $ chmod 755 tama-mroot magisk-setup.sh magisk-start.sh
H8324:/data/local/tmp $ ./magisk-setup.sh

[...]

H8324:/data/local/tmp $ cd /data/local/tmp
H8324:/data/local/tmp $ ./tama-mroot

[...]

root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -1

[...]

root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -2

[...]

root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -3

[...]

We can verify now that we have really root privileges:

root_by_cve-2020-0041:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:magisk:s0
root_by_cve-2020-0041:/data/local/tmp # uname -a
Linux localhost 4.9.186-perf+ #1 SMP PREEMPT Fri Jan 17 01:22:05 2020 aarch64

Hence, let’s go ahead and back up the TA partition:

root_by_cve-2020-0041:/data/local/tmp # dd if=/dev/block/bootdevice/by-name/TA of=TA-locked.img
4096+0 records in
4096+0 records out
2097152 bytes (2.0 M) copied, 0.039839 s, 50 M/s
root_by_cve-2020-0041:/data/local/tmp # chown shell:shell TA-locked.img
root_by_cve-2020-0041:/data/local/tmp # sync
root_by_cve-2020-0041:/data/local/tmp # sync

Now, from another terminal in the computer, pull the created backup:

root$ adb pull /data/local/tmp/TA-locked.img

That’s it, we have finished backing up the TA partition!

Now, we can continue to install the LineageOS system.

Installing LineageOS in the Sony Xperia XZ2 Compact Dual (in GNU/Linux) 1/5: Downgrading Sony’s Stock Firmware

WARNING

I have no responsibility whatsoever if this guideline causes any harm to your device. The intention of these posts are solely as personal notes for myself. Follow them at your own risk.

WARNING

Through these steps I will unlock the phone’s bootloader, erasing all data. This includes the DRM keys stored in the Trim Area (TA) partition. I’ll attempt backing them up but, as of today, there is no way of restoring them to the previous state nor knowing if the actual backup is usable at all.

Without these DRM keys, several audio and video proprietary functionality provided by Sony won’t be available including some camera post-processing features, color gamut profiles, white balance, noise reduction, X-Reality Video Enhancement, DSEE HX, ClearAudio+, and Widevine L1 support for HD Netflix.

Why

I want to have a phone running Free Software with the possibility of using all the major apps out there. That means, unfortunately, some kind of Android flavor. I also want a small phone and, since I’m a Spaniard living in Finland, I’d like that my phone has dual SIM capability. Until now I was using a Xiaomi Redmi 2 but, after years of usage, I cannot squeeze it any more. I’d also love to have a decent camera, if possible.

After quite some research, my conclusion is that the only real alternative that ticks (most of) the boxes is the Sony Xperia XZ2 Compact Dual.

Preconditions

I’ll be doing all the stems in a Debian Buster GNU/Linux distribution on a x86_64 platform.

Downgrading the stock firmware

If you have read the warning above, you now know that installing LineageOS implies unlocking the bootloader. In turn, this means wiping the TA partition and losing the DRM keys, which will cause several advanced audio and video features to get lost forever.

We want to keep the hope that, at least, we would be able to restore this functionality. This means that we want to backup the TA partition. Doing that without actually unlocking the bootloader is not really possible … unless you exploit a security bug.

The Sony firmwares build 52.1.A.0.618 contains one such kernel bug. Therefore, first thing, downgrading the current firmware in the device to use the one affected.

As a previous step, I downloaded the firmware that was running in my device at the time: 8324_Customized NOBA_1313-6167_52.1.A.3.49_R4C

For downloading the up to date firmware I used the XperiFirm program:

root$ apt install mono-complete
root$ cert-sync /etc/ssl/certs/ca-certificates.crt
root$ certmgr -ssl -m https://software.sonymobile.com
(Entered Y twice when asked)
$ mono XperiFirm.exe

Then, I selected the Xperia XZ2 Compact Apollo: H8324 dual phone and downloaded the Nordic Combined available firmware.

Now, I downloaded and extracted the exploitable H8324-52.1.A.0.618 firmware for the Xperia XZ2 Compact Dual and followed this guide to install it into the phone without unlocking the bootloader.

We want to use the Flashtool to create a bundle with the parts of the firmware we are going to use.

I downloaded the latest version of the tool (0.9.29.0 at the time) and tried to launch it:

root$ DISPLAY=:0.0 ./FlashTool
Running as root.
Error: dl failure on line 603
Error: failed /home/tanty/personal/sony_xperia_xz2c/flashtool/FlashTool/x10flasher_native/jre/lib/server/libjvm.so, because /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /home/tant
y/personal/sony_xperia_xz2c/flashtool/FlashTool/x10flasher_native/jre/lib/server/libjvm.so)

Bad news … it seems this version was compiled against a different C toolchain? Let’s use an older version then. 0.9.27.0 it is.

root$ DISPLAY=:0.0 ./FlashTool
Running as root.
Used java home : /usr
03/057/2020 16:57:14 - INFO - <- This level is successfully initialized
(Flashtool:8027): GLib-CRITICAL **: 16:57:14.971: g_base64_encode_step: assertion 'in != NULL' failed
(Flashtool:8027): GLib-CRITICAL **: 16:57:14.971: g_base64_encode_step: assertion 'in != NULL' failed
...

Voilá!

In the UI, we select Tools -> Bundles -> FILESET Decrypt. In the popping up Window we browse to the folder containing the exploitable firmware: H8324_Customized FR_1313-2469_52.1.A.0.618_R2C. There, we choose the 3 zip files that it contains and move it from the left side to the right side in the window and click Convert.

Once it has finished, we want to skip creating the bundle by just pressing Cancel in the next window. We have finished using flastool.

In the exploitable firmware directory we now have a new folder called decrypted. We want to delete some files there:

root$ rm decrypted/*ta
root$ rm decrypted/boot/*ta

Before we proceed to flash, we need to add some rules to the udev system in our computer so it can identify the Xperia phone:

root$ echo 'SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="0fce", ATTRS{idProduct}=="*", MODE="0777"' > /etc/udev/rules.d/51-sony.rules
root$ service udev restart

Now, we want to use another tool to flash these files into the phone: newflasher. I downloaded the latest v36 version, extracted, placed the executable in the decrypted folder from the previous step:

root$ mv newflasher.x64 decrypted
root$ cd decrypted
root$ chmod +x newflasher.x64

Last thing is setting the phone into flashmode.

First, let’s enable developer mode in the phone: Settings -> About phone, and hit several times the Build number field until it states that you have become a developer. Then, go to Settings -> System -> Advanced -> Developer options and switch on the USB debugging option.

Now, power down the phone. Once off, press and hold Volume Down and connect the USB cable that is connected to the computer in the other end. The led of the phone turns on and stays on. It is now into flashmode. Let’s flash:

root$ ./newflasher.x64

[...]

Reboot mode at the end of flashing:
typa 'a' for reboot to android, type 'f' for reboot to fastboot, type 's' for reboot to same mode, type 'p' for poweroff, and press ENTER.
a

[...]

Optional step! Type 'y' and press ENTER if you want dump trim area, or type 'n' and press ENTER to skip.
Do in mind this doesn't dump drm key since sake authentifiction is need for that! But it is recommend to have dump in case hard brick!
n

[...]

Recommended step to skip this! Type 'y' and press ENTER if you want flash persist partition, or type 'n' and press ENTER to skip.
More info https://forum.xda-developers.com/xperia-xz1-compact/help/android-attest-key-lost-bootloader-t3829945
n

[...]

Device is put now out of flash mode.
Sent command: Sync
Waiting sync to finish…
……………… done
Sent command: continue.
Done.
Closing device.

Notice the questions and the answers. After a while, the phone will complete its reboot and we will be able to verify that the running firmware is the one flashed.

That all by now, next step: backing up the TA partition!

Review of Igalia’s Graphics activities (2018)

This is the first report about Igalia’s activities around Computer Graphics, specifically 3D graphics and, in particular, the Mesa3D Graphics Library (Mesa), focusing on the year 2018.

GL_ARB_gl_spirv and GL_ARB_spirv_extensions

GL_ARB_gl_spirv is an OpenGL extension whose purpose is to enable an OpenGL program to consume SPIR-V shaders. In the case of GL_ARB_spirv_extensions, it provides a mechanism by which an OpenGL implementation would be able to announce which particular SPIR-V extensions it supports, which is a nice complement to GL_ARB_gl_spirv.

As both extensions, GL_ARB_gl_spirv and GL_ARB_spirv_extensions, are core functionality in OpenGL 4.6, the drivers need to provide them in order to be compliant with that version.

Although Igalia picked up the already started implementation of these extensions in Mesa back in 2017, 2018 is a year in which we put a big deal of work to provide the needed push to have all the remaining bits in place. Much of this effort provides general support to all the drivers under the Mesa umbrella but, in particular, Igalia implemented the backend code for Intel‘s i965 driver (gen7+). Assuming that the review process for the remaining patches goes without important bumps, it is expected that the whole implementation will land in Mesa during the beginning of 2019.

Throughout the year, Alejandro Piñeiro gave status updates of the ongoing work through his talks at FOSDEM and XDC 2018. This is a video of the latter:

ETC2/EAC

The ETC and EAC formats are lossy compressed texture formats used mostly in embedded devices. OpenGL implementations of the versions 4.3 and upwards, and OpenGL/ES implementations of the versions 3.0 and upwards must support them in order to be conformant with the standard.

Most modern GPUs are able to work directly with the ETC2/EAC formats. Implementations for older GPUs that don’t have that support but want to be conformant with the latest versions of the specs need to provide that functionality through the software parts of the driver.

During 2018, Igalia implemented the missing bits to support GL_OES_copy_image in Intel’s i965 for gen7+, while gen8+ was already complying through its HW support. As we were writing this entry, the work has finally landed.

VK_KHR_16bit_storage

Igalia finished the work to provide support for the Vulkan extension VK_KHR_16bit_storage into Intel’s Anvil driver.

This extension allows the use of 16-bit types (half floats, 16-bit ints, and 16-bit uints) in push constant blocks, and buffers (shader storage buffer objects).  This feature can help to reduce the memory bandwith for Uniform and Storage Buffer data accessed from the shaders and / or optimize Push Constant space, of which there are only a few bytes available, making it a precious shader resource.

shaderInt16

Igalia added Vulkan’s optional feature shaderInt16 to Intel’s Anvil driver. This new functionality provides the means to operate with 16-bit integers inside a shader which, ideally, would lead to better performance when you don’t need a full 32-bit range. However, not all HW platforms may have native support, still needing to run in 32-bit and, hence, not benefiting from this feature. Such is the case for operations associated with integer division in the case of Intel platforms.

shaderInt16 complements the functionality provided by the VK_KHR_16bit_storage extension.

SPV_KHR_8bit_storage and VK_KHR_8bit_storage

SPV_KHR_8bit_storage is a SPIR-V extension that complements the VK_KHR_8bit_storage Vulkan extension to allow the use of 8-bit types in uniform and storage buffers, and push constant blocks. Similarly to the the VK_KHR_16bit_storage extension, this feature can help to reduce the needed memory bandwith.

Igalia implemented its support into Intel’s Anvil driver.

VK_KHR_shader_float16_int8

Igalia implemented the support for VK_KHR_shader_float16_int8 into Intel’s Anvil driver. This is an extension that enables Vulkan to consume SPIR-V shaders that use Float16 and Int8 types in arithmetic operations. It extends the functionality included with VK_KHR_16bit_storage and VK_KHR_8bit_storage.

In theory, applications that do not need the range and precision of regular 32-bit floating point and integers, can use these new types to improve performance. Additionally, its implementation is mostly API agnostic, so most of the work we did should also help to have a proper mediump implementation for GLSL ES shaders in the future.

The review process for the implementation is still ongoing and is on its way to land in Mesa.

VK_KHR_shader_float_controls

VK_KHR_shader_float_controls is a Vulkan extension which allows applications to query and override the implementation’s default floating point behavior for rounding modes, denormals, signed zero and infinity.

Igalia has coded its support into Intel’s Anvil driver and it is currently under review before being merged into Mesa.

VkRunner

VkRunner is a Vulkan shader tester based on shader_runner in Piglit. Its goal is to make it feasible to test scripts as similar as possible to Piglit’s shader_test format.

Igalia initially created VkRunner as a tool to get more test coverage during the implementation of GL_ARB_gl_spirv. Soon, it was clear that it was useful way beyond the implementation of this specific extension but as a generic way of testing SPIR-V shaders.

Since then, VkRunner has been enabled as an external dependency to run new tests added to the Piglit and VK-GL-CTS suites.

Neil Roberts introduced VkRunner at XDC 2018. This is his talk:

freedreno

During 2018, Igalia has also started contributing to the freedreno Mesa driver for Qualcomm GPUs. Among the work done, we have tackled multiple bugs identified through the usual testing suites used in the graphic drivers development: Piglit and VK-GL-CTS.

Khronos Conformance

The Khronos conformance program is intended to ensure that products that implement Khronos standards (such as OpenGL or Vulkan drivers) do what they are supposed to do and they do it consistently across implementations from the same or different vendors.

This is achieved by producing an extensive test suite, the Conformance Test Suite (VK-GL-CTS or CTS for short), which aims to verify that the semantics of the standard are properly implemented by as many vendors as possible.

In 2018, Igalia has continued its work ensuring that the Intel Mesa drivers for both Vulkan and OpenGL are conformant. This work included reviewing and testing patches submitted for inclusion in VK-GL-CTS and continuously checking that the drivers passed the tests. When failures were encountered we provided patches to correct the problem either in the tests or in the drivers, depending on the outcome of our analysis or, even, brought a discussion forward when the source of the problem was incomplete, ambiguous or incorrect spec language.

The most important result out of this significant dedication has been successfully passing conformance applications.

OpenGL 4.6

Igalia helped making Intel’s i965 driver conformant with OpenGL 4.6 since day zero. This was a significant achievement since, besides Intel Mesa, only nVIDIA managed to do this too.

Igalia specifically contributed to achieve the OpenGL 4.6 milestone providing the GL_ARB_gl_spirv implementation.

Vulkan 1.1

Igalia also helped to make Intel’s Anvil driver conformant with Vulkan 1.1 since day zero, too.

Igalia specifically contributed to achieve the Vulkan 1.1 milestone providing the VK_KHR_16bit_storage implementation.

Mesa Releases

Igalia continued the work that was already carrying on in Mesa’s Release Team throughout 2018. This effort involved a continuous dedication to track the general status of Mesa against the usual test suites and benchmarks but also to react quickly upon detected regressions, specially coordinating with the Mesa developers and the distribution packagers.

The work was obviously visible by releasing multiple bugfix releases as well as doing the branching and creating a feature release.

CI

Continuous Integration is a must in any serious SW project. In the case of API implementations it is even critical since there are many important variables that need to be controlled to avoid regressions and track the progress when including new features: agnostic tests that can be used by different implementations, different OS platforms, CPU architectures and, of course, different GPU architectures and generations.

Igalia has kept a sustained effort to keep Mesa (and Piglit) CI integrations in good health with an eye on the reported regressions to act immediately upon them. This has been a key tool for our work around Mesa releases and the experience allowed us to push the initial proposal for a new CI integration when the FreeDesktop projects decided to start its migration to GitLab.

This work, along with the one done with the Mesa releases, lead to a shared presentation, given by Juan Antonio Suárez during XDC 2018. This is the video of the talk:

XDC 2018

2018 was the year that saw A Coruña hosting the X.Org Developer’s Conference (XDC) and Igalia as Platinum Sponsor.

The conference was organized by GPUL (Galician Linux User and Developer Group) together with University of A Coruña, Igalia and, of course, the X.Org Foundation.

Since A Coruña is the town in which the company originated and where we have our headquarters, Igalia had a key role in the organization, which was greatly benefited by our vast experience running events. Moreover, several Igalians joined the conference crew and, as mentioned above, we delivered talks around GL_ARB_gl_spirv, VkRunner, and Mesa releases and CI testing.

The feedback from the attendees was very rewarding and we believe the conference was a great event. Here you can see the Closing Session speech given by Samuel Iglesias:

Other activities

Conferences

As usual, Igalia was present in many graphics related conferences during the year:

New Igalians in the team

Igalia’s graphics team kept growing. Two new developers joined us in 2018:

  • Hyunjun Ko is an experienced Igalian with a strong background in multimedia. Specifically, GStreamer and Intel’s VAAPI. He is now contributing his impressive expertise into our Graphics team.
  • Arcady Goldmints-Orlov is the latest addition to the team. His previous expertise as a graphics developer around the nVIDIA GPUs fits perfectly for the kind of work we are pushing currently in Igalia.

Conclusion

Thank you for reading this blog post and we look forward to more work on graphics in 2019!

Igalia

Internet radio directory

Following, a directory of Internet radios streaming in a compatible way with open systems like GNU/Linux. Typically, this will mean that no flash plugin nor weird proprietary codecs would be needed.

This post will be updated every now and then.

Stations

Directories

Spain

Grupo Prisa (Cadena SER, 40 Principales, M80, Máxima FM, Radiole, Cadena DIAL, etc)

Other directories

Introducing Facerecognition Resetter Plugin for the Nokia N9

As my mate Simón was writing short time ago in his post Announcing the Gallery Tilt Shift plugin for the Nokia N9, we got published at Igalia some plugins for enhancing the experience of the built-in Gallery application in the N9/N950 through the Nokia Store: Enlarge & Shrink Plugin, Gallery Tilt Shift Plugin, and Facerecognition Resetter Plugin.

The Enlarge & Shrink Plugin is a filter developed by Antía Puentes for the built-in Gallery application which applies a radial distortion to a picture featuring an enlarge or shrink effect (also known as punch or pinch).

The Gallery Tilt Shift Plugin is a filter developed by Simón Pena for the built-in Gallery application which makes a picture look like a miniature.

Finally, Facerecognition Resetter Plugin was developed by me. It is a add-on for the built-in Gallery application which is not a real filter for the pictures. Instead, it is just a way of forcing the deletion or un/protection of the face recognition database through its usage from Gallery. The main reason for doing this is a well known bug in the face recognition feature.

If you are experiencing that the the N9 is not recognizing faces any more or it is not giving any more suggestions just install Facerecognition Resetter Plugin and click on the “Protect” button. You want to do this even if you are not suffering this problem since this will prevent it from appearing in the future.

BTW, comments and reviews in the Nokia Store will be welcomed 😀

But, specifically, why would we want to reset or un/protect the face recognition database? Or, actually, what the heck is that face recognition database? Let’s get to the beginning.

When Nokia released the PR1.2 update for the Harmattan platform they included a new feature which made the N9 to be the first smartphone with integrated automated face recognition.

This feature, when activated, let the Gallery or Camera application to automatically recognize faces on the pictures stored in the device, showing a white bubble with a question mark on top of the region detected as a face.

Clicking on such bubble you would be able to select one of your contacts to be assigned as the detected face.

The algorithm would be even learning as the user selected and assigned faces to contacts so at some point it would be also suggesting the proper contact for the detected faces. The user, then, would only have to double tap on the suggestion bubble to confirm such contact.

Everything seemed great but after a while, some users started to complain that this feature eventually stopped working. Either it was not suggesting anyone, when there were people tagged in a big number of pictures or it was just not recognizing faces any more.

As with any software, the face recognition feature contains bugs and this problem was the consequence of one that Nokia has not yet fixed to the current date.

The technical explanation is that the algorithm that performs the face detection relies in SQLite to store its learning parameters and contacts. This database is located at:

/home/user/.local/share/gallerycore/data/faces.db

This file and its directory are protected through the usage of the AEGIS “powered” gallerycoredata-user user and gallerycoredata-users group. Also, the file permissions mask for them are 070 in the case of the directory and 060 in the case of the file.

When doing transactions to the database file the SQLite driver may create some temporal files as the journal one, to be able to recover the database under disaster. This journal file gets the UID and GID of the running process and the permissions from a combination of the permissions of the original database file and the running process’ umask. As a consequence, the journal file usually has the permissions mask 040.

While using the Camera or Gallery application the SQLite file is open. Whether a disaster may happen, although we hold the journal file, the owner of that file is not able to read it. Hence, the SQLite database remains useless for the processes with the same UID than the owner of the journal file, even when they belong to the same group than that file.

What it happen afterwards is that the SQLite database remained waiting to be “recovered” using the journal file but as the journal could not be read, the face recognition algorithm could not provide the learned information and suggest contacts any more. The solution for this would have been as easy as to change the file permissions of the journal file but this is not even possible for the root user since only the gallerycore-user user and those belonging to the gallerycore-users group were allowed through AEGIS to read and change the files on the parent directory of the database file.

Hence, the only way of being able to do a hack that would solve this problem was that the actual application doing such changes would be either Gallery or Camera. Fortunately, Gallery had the possibility of being extended through plugins and that’s the reason why Facerecognition Resetter is such.

Following, you can watch a video featuring an usage introduction tutorial and a detailed explanation of its usage below it.

The plugin shows 3 buttons for its corresponding actions:

  • Reset the database: As simple as that. It will delete the directory and files containing all the information gathered through the face recognition algorithm. From that on, the face recognition feature will start to work again but the learning gotten previously and powering the suggestions will be lost.
  • Protect the database: This will correct the permissions of the directories and files containing all the information gathered through the face recognition algorithm. From that on, the face recognition feature will start to work again and the suggestions would have the learning gotten previously. The problem will not show up in the future ever again but the database will remain protected and only usable through Gallery and Camera (or any other application with the proper AEGIS tokens).
  • Unprotect the database: This will correct the permissions of the directories and files containing all the information gathered through the face recognition algorithm. From that on, the face recognition feature will start to work again and the suggestions would have the learning gotten previously. The problem will not show up in the future ever again and the database will be available to any other application that would like to make use of it.

The permissions get corrected when un/protecting since the plugin sets the SGID bit to the parent directory of the database file so any other files created under it will belong to the same group than the directory and not to the GID of the running process that created that file. Also, the database will have now the 660 mask so any temporal file created by the SQLite drive will attempt to keep the same mask.

And with this, we can keep enjoying the usage of the face recognition feature of the N9 and go to celebrate it with some beers!!! 😀

This and the other plugins are Open Source, so you can go to their page at GitHub: Enlarge & Shrink, Gallery Tilt Shift and Facerecognition Resetter

Also, don’t forget to take a look at all the applications published by Igalia at the Nokia Store

Download Facerecognition Resetter Plugin from Nokia Store

Igalia wallpapers

Igalia wallpaper for the N9/N950

“Igalia wallpaper for the N9/N950”

Some weeks ago we decided to do an upgrade to the information that we are showing in our Igalia’s website. Due to these changes, I had the chance to play a little bit with some new graphic material that was used in the upgrade.

As a result, I’ve created based on Opsou’s Pedro Figueras original idea some different wallpapers for most of my GNU/Linux powered devices.

Just click in the images and go to download them at their original resolution.

I’ve uploaded it to a public Git repository which you can download with the following command:

~#  git clone http://git.igalia.com/art/wallpapers.git
4x3 Igalia wallpaper

“4×3 Igalia wallpaper”

16x9 Igalia wallpaper

“16×9 Igalia wallpaper”

Igalia wallpaper for the N900/N810/N800/N770

“Igalia wallpaper for the N900/N810/N800/N770”

Extending the life of your N8x0: Second update for Automatic Skype Launcher

Back again with a new release, the 0.0.3, of Applications Fullscreener and Automatic Skype Launcher.

Just download and install them in your N8x0 for making it become a good 24/7 Skype phone. For more information about the goals and features of this project you can check the previous post Extending the life of your N8x0: Automatic Skype Launcher.

Skype Tango Icon

I took the chance to update also the artwork used in these two applications. First thing, I created a Tango-ized version of the Skype logo.

Then, I used the previous magnificent art works from Andreas Nilsson and Jakub Steiner to create the new icons, and these are the result:

Applications Fullscreener Icon Applications Fullscreener Debian Package Icon Applications Fullscreener Icon Applications Fullscreener Settings Icon

Anyway, going to the actual changes.

The most important change for Applications Fullscreener is:

  • There was a second bash helper to launch a certain application and send the fullscreen key event some time afterwards. It was not fully featured but now it is.

You can, also, check the complete ChangeLog for Applications Fullscreener.

The most important changes for Automatic Skype Launcher are:

  • The Automatic Skype Launcher service was not stopping when uninstalled. Now this is corrected.
  • The init service was not starting correctly in some scenarios due to some uninitialized variables. This has been corrected.
  • In the previous version, I added an alarm triggered by the alarmd daemon to restart Skype (and the service). This was not working always. Now, killing Skype is forced.

You can, also, check the complete ChangeLog for Automatic Skype Launcher.

That’s it. Comments and patches are welcomed!