Peter Vágner

In order to make this really work I had to do a few edits to this article. Last change has been made at 29th of december 2016.
Today I was asked by one of the online friends how to make LibreElec htpc software include Kodi screen reader addon.
First we had some disscussion in the #libreelec IRC channel on freenode. We have found out adding Kodi screen reader into the official image is not likely to happen. We are still free to make our blindness specific spin though.
There are several things to overcome.
Rebuilding the whole LibreELEC image is an overkill we just would like to inject our addon.
The addon has a feature that will not start when it's preinstalled into system wide kodi addons directory so we have to patch the addon with a dirty change until a better solution is found.
And this is updated proof of concept tweak how we can hack Kodi screen reader into image of Raspberry pi 2 / Raspberry pi 3 build of Libre Elec.


# Create an empty directory where we will do our job
mkdir /tmp/libreelec
cd /tmp/libreelec/
# download libreelec image. You can get the Kripton or more up to date version but pay extra attention in that case
wget "http://ftp.belnet.be/libreelec.tv/LibreELEC-RPi2.arm-7.0.2.img.gz"
# unpack the downloaded archive
gunzip LibreELEC-RPi2.arm-7.0.2.img.gz
# inspect what partitions the unpacked image has
fdisk -lu LibreELEC-RPi2.arm-7.0.2.img
# Note the sector size of the image is 512 bytes, first partition starts at sector 2048 thus we need to setup a loop device starting at offset 2048*512
sudo losetup -o 1048576 /dev/loop0 LibreELEC-RPi2.arm-7.0.2.img
# create a temporary folder where we'll mount the unpacked image
mkdir image
sudo mount /dev/loop0 image
# unpack squashfs image to a current directory (has to be executed as root to preserve file permissions and ownership)
sudo unsquashfs image/SYSTEM
# Download current Kodi screen reader addon from one of the kodi.tv addon repository mirrors
wget "http://ftp.halifax.rwth-aachen.de/xbmc/addons/krypton/service.xbmc.tts/service.xbmc.tts-1.0.6.zip"
# Change to the directory where you can unpack Kodi screen reader addon
cd squashfs-root/usr/share/kodi/addons/
# unzip the Kodi screen reader addon (do it as root to fit within the rest of the target system image)
sudo unzip ../../../../../service.xbmc.tts-1.0.6.zip
# Patch the addon not to disable it-self on first run when it detects it's preinstalled
sudo sed 's/return os\.path\.exists(preInstalledPath)/return False #os\.path\.exists(preInstalledPath)/g' service.xbmc.tts/lib/util.py 1<> service.xbmc.tts/lib/util.py
# change back to the original working directory
cd ../../../../..
# If you have image including Kodi Kripton or possibly newer version, uncomment the next line to add our addon into the addon-manifest.xml
sudo xmlstarlet ed -L --subnode "/addons" -t elem -n "addon" -v "service.xbmc.tts" squashfs-root/usr/share/kodi/system/addon-manifest.xml || : # ignore error
# Recreate the squashfs SYSTEM image (again it's important to do that as root)
sudo mksquashfs squashfs-root SYSTEM -b 131072 -comp lzo -no-xattrs
# Create a md5 sum for your new squashfs image
md5sum SYSTEM > SYSTEM.md5
# now if you like you can compare size and features of both the images.
ls -l SYSTEM
ls -l image/SYSTEM
unsquashfs -s SYSTEM
unsquashfs -s image/SYSTEM
# Finally move your newly created SYSTEM and SYSTEM.md5 files into the proper place
sudo mv SYSTEM* image/
# unmount the image as we are done tampering with it
sudo umount image
# If you like just check the image if it has been really modified recently
ls -l LibreELEC-RPi2.arm-7.0.2.img
# Compress the image inplace as much as gzip allows
gzip -9 LibreELEC-RPi2.arm-7.0.2.img
# Flash / upload file for a friend and clean up your self please

In my Emacs A11y Tip #1 I've already touched the topic of this #2 from #EmacsA11yTips slightly. I did not explore all the details at the time so I feel I should try to correct this now.
When installing Emacs there are various possible build configurations and some of them have been adopted as a defacto standards meaning analogous packages are available in the multiple linux distributions package repositories. These are emacs, emacs-nox and emacs-gtk2.

Guessing from the package names it's obvious -nox variant has all the graphical dependencies stripped out. That means we will only see text UI when running no matter if we are in a graphical X session or on a text only console. I was expecting full package would therefore be unnecessary for me because it brings in a few more dependencies and the window it presents is inaccessible to orca anyway. So given this reasoning I assumed it might have minimal impact and I won't need X support in my install of Emacs.

My complicated reasoning has proven not to be quite right and X support within emacs might really be usefull. I have found out a few differences between X and no X variants and some of them are serious enough for me to install X support.

• When X support is installed, emacs kill and copy commands insert the text into the clipboard so it's possible to copy and paste from emacs into other applications and the other way round.
• No X variant can be also running within a terminal emulator like gnome-terminal. It means you can use orca's flat review to examine its output.
• When X support is installed Emacs creates its own window seperated from a terminal if emacs is started from a terminal emulator. It is completelly inaccessible to orca and it consumes all the keyboard input so orca even can't receive the insert / capslock key presses. It is possible to decide during runtime when X aware version of emacs is installed if we want / don't want X support. Run
  emacs -nw
  to start emacs with no X support.
• Installation which also features X support can also be started in pure text only console. In such a case X support won't be used obviously. Emacs should otherwise be as functional as intended. I've found askubuntu answer supporting this argument. Some parts of Emacs appear to inherit native accessibility and I am not sure where this is coming from. For example pressing C-x C-f brings up find interface accessible with Speechd-el but pressing F10 shows up GTK2 based menu bar and activating Open... from the File menu pops up GTK2 native file chooser dialog.
• emacs-gtk2 has X support and as an addition it also features mixture of its natural UI with some GTK2 based widgets. I don't know if there is something usefull for us here.

Given the fact there is no complete full browser inside Emacs, copy and paste is really essential. Additionally it is possible to configure Emacs to open web links in 3rd party apps so depending if you are in X or not you can configure to open these in Firefox or elinks directly.

There might be other notable differences when running emacs within X session or pure text console for example gpg agent setup or integration with other 3rd party tools. If I find it to be significant enough I will post a new tip.
I don't consider emacs with gtk+2 support particularly appealing just yet because it does not appear to be practical switching between operating system native and emacs specific screen reading app.

Update: Originally I have assumed graphical ATK accessible menu is only within emacs-gtk2, however it's also present in the original emacs with no GTK support. It sounds a bit dissapointing that we have no speechd-el accessible menu in this mode. But using keyboard shortcuts and other things is worth the trade I think.

Update2: Run

emacs -nw

if you would like to decide at runtime whether you do want an X support or not.