Aura HD Debian for Aura HD

[tigran]

I have installed Russian input method:

$ sudo apt-get install ibus-table-rustrad

And switching between input methods (either via Ctrl-Space or the icon in system tray) works fine, but switching between keyboard layouts (I added Russian) doesn't work. Setting

$ setxkbmap -option grp:alt_shift_toggle "us,ru"

makes "options: grp:alt_shift_toggle" show up in the output of "setxkbmap -query", but actually pressing Alt-Shift doesn't cause a layout switch in onboard. Any ideas?

Btw, input methods are really unnecessary, switching keyboard layouts is enough, so I am uninstalling all that ibus-table-* stuff.

In summary: switching layouts manually (via onboard's programmable buttons) works fine, but trying to bind the switch layout function to a key combination doesn't work. I have tried many combinations and none work.

[tigran]

There are not one but two ways to self-destruct this system:

1. Logout (as described before).

2. Rebooting from the previous state being Kobo's Linux environment (with KSM as the base interface of course).

In both cases the "destroyed system" appears like this (maybe someone knows how to recover from it?) --- the panel starts in the second state (the one with lots of useless buttons, some arrows, +/-, image of the Sun etc) instead of the normal state as "system tray" and clicking on "return to normal state" button causes panel to stop completely.

I tried starting xfce4-panel manually from a terminal. It does startup, but as a completely white line at the bottom, no buttons on it.

It just occurred to me that "tray" and "xfce4-panel" are different things. Maybe that "tray" process is responsible for "system tray"? Hmmm, I'll try to figure this out as having to restore from backup every time this happens is quite tedious (even though it is only the rootfs that has to be restored).

UPDATE: I see lots of subdirectories in ~/.config/xfce4/panel --- are they all necessary or is this some junk that can be deleted and re-created on the next startup? Also, I see that (even though nothing actually happened on the system except me entering a few details in OSMO application) 260 files all over the system are different from yesterday's evening backup, most notably these files which I think are the culprit:

home/xu/.config/xfce4/panel/launcher-15/14125051482.desktop
home/xu/.config/xfce4/panel/launcher-26/14112778309.desktop
home/xu/.config/xfce4/panel/launcher-29/141127814211.desktop
home/xu/.config/xfce4/panel/launcher-5/141127843012.desktop
home/xu/.config/xfce4/panel/launcher-7/14183788291.desktop
home/xu/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml
home/xu/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml
home/xu/.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml

The xfce4-panel.xml file is very seriously different and this is probably what is causing the broken panel. I wonder how much of this stuff can be safely deleted and re-created on the next startup...

UPDATE: Ok, I have figured out how to configure xfce4-panel after all, so no more restoring from backups. Still, it is very strange that the configuration gets corrupted by such innocent actions like logout or booting into KSM.

[tigran]

It would be really really useful if it was possible to configure the device (while booted in Debian Linux) to ignore the magnetic cover close and open causing sleep and wakeup events.

Imagine this situation: I am right now installing TeX Live 2016 which takes about 3 hours on this device (about 40 times slower than my desktop) and I need to go somewhere. I cannot go --- I have to wait another two hours until the installation completes because if I close the cover and put this computer into my pocket it will go to sleep and the installation will crash. I know, of course, that power management in the kernel is supposed to be transparent to the apps, but this is IN THEORY, whereas in practice it is never transparent and so it is NOT A GOOD IDEA to try to sleep/wakeup while the computer is actively doing something, as it is most likely NOT going to "just resume" it when it wakes up. It will just crash and I will have to restart the installation from the beginning.

So, having a way to ignore the magnetic cover's sleep/wakeup events (temporarily) would be a very good feature.

[tigran]

Sometimes the system just boots into Landscape mode and is unresponsive for a couple of minutes until the window pops up with the following message:

Failed to execute command "launch "wmctrl -c :ACTIVE:"".

Failed to execute child process "launch" (No such file or directory)

And then the touch screen is still not responding, so one has to shutdown forcibly (by long press of power slide) and restore the rootfs from yesterday's backup (carefully excluding ~/texlive and ~/.texlive* created during 3 hours installation of TeX Live 2016 just now).

Any ideas what caused the failure to launch "launch"?

[tigran]

The mysterious disappearance of the main panel (with all its launchers) is still that --- a mystery. Fortunately, it only happens about once in two weeks and a restore of ~/.config/xfce4/panel/ fixes this.

Also, I noticed that / is mounted with "relatime". For mmc devices it would be better to mount it with a stronger "noatime" (which btw implies "nodiratime" but I noticed in many scripts in /opt/kobo the options "noatime,nodiratime" where "nodiratime" would be superfluous). But /etc/fstab file is empty, so where do I specify the mount options for the rootfs?

[tigran]

The main panel disappeared again after a reboot, with no apparent reason. Comparing with the backup I see that the corresponding launcher files in ~/.config/xfce4/panel are gone, plus the panel configuration files have been modified.

How could this possibly happen? Surely, the configuration files shouldn't change unless one is modifying the configuration?

I suspect that there is an attempt going on here to preserve the state of visibility of onboard and thus corrupting the files --- that would be absolutely ridiculous, because the onboard keyboard should be made visible only by manually clicking on the corresponding icon on the panel and NOT automatically. (why would one want it's state to be automatically preserved?) Generally, the more things are done manually, the better, so I will look hard to "de-automate" some of these fancy GUI things to make it closer to old good Unix with 80x25 terminal with green blinking cursor and nothing else

Judging by the lack of replies to my messages I am assuming that very few people actually use this. But I am glad to report that I have managed to make this pocket computer functionally almost equivalent to my main workstation environment (a result of 20 years of work in basically the same Unix environment), except some things which are not available for armhf platform, like Wolfram Mathematica and REDUCE. So, if I figure out how to prevent these mysterious panel disappearances then I will have a tiny pocket computer almost identical to my workstation, but 30 times slower!

[tigran]

Good news: now you can use your Kobo AuraHD device to navigate to other star systems, both distant and nearby

Seriously, I fixed StarPlot to be useable on Kobo AuraHD and here is the patch:

http://www.bibles.org.uk/patches/starplot-0.95.5.patch

First you grab the original sources from here:

http://www.starplot.org/downloads/st...-0.95.5.tar.gz

Extract the sources and patch them and then do the usual "./configure; make". The resulting starplot binary is not using the buttonbar (too small to access on a highres AuraHD screen) and instead binds all the functions to keyboard shortcuts. Documentation is the actual source code, just read my patch --- it is all quite obvious.

Btw, you can use it without invoking onboard keyboard because I also bound the functions to those panel keys on the second panel (ZoomIn/ZoomOut, Home/End, Left/Right, PageUp/PageDown). This is very convenient as it allows to utilize full screen space without wasting much of it for onboard.

[Markismus]

Originally Posted by tigran

Judging by the lack of replies to my messages I am assuming that very few people actually use this.

I do read it.

However, owing a Aura H2O I cannot use your result directly. Moreover, I still have to dive into the problem of actually getting Debian on the device!

[tigran]

Yes, I wanted to have this whole thing on my H2O as well, but finally decided that it is ok to use H2O as a document reader, leaving HD as a "Linux tablet" or "pocket Linux PC"

I also tried Marek's Debian on Kobo Touch and Mini but found it very fragile and, most importantly, binary incompatible with either this (Debian on AuraHD) or with the standard Linux environment on the Kobo --- the very important consequence of this incompatibility is that you can't use CoolReader and Koreader binaries on it directly.

Oh btw, I benchmarked opening a PDF file (just a typical typeset PDF file of one of my books from http://www.bibles.org.uk/study-edition.html) and got the following results for opening it (for the first time, i.e. without any caches):

1. Koreader --- 0.5 seconds
2. evince on Debian AuraHD (of this thread) --- 8 seconds
3. evince on Marek's Debian on Mini --- INFINITY (i.e. I waited for 95 seconds and then killed evince as it took too long).

So, Marek's environment is at least 10 times slower than Xu's and at least 200 times slower than the native Linux environment of Kobo.

Oh btw, I noticed one odd thing: WiFi on both native Kobo Linux (by "native" I mean Kobo Start Menu plus Koreader plus CoolReader) and on Marek's Debian gives me about 3.5MB/s of rsync speed, but with Debian on AuraHD it doesn't get higher than 1MB/s max (normally about 800KB/s). Any ideas why is WiFi so slow?

[glasnost]

I just picked up an H2O with the hope of turning it into a pocket linux tablet :-) You are an inspiration :-)

[tigran]

H2O? This stuff runs only on HD, not H2O...

Or are you intending to port the entire operating system from H2O to HD? (as far as I understand at least the X server and the Linux kernel will have to be ported, so if someone approached me I would estimate "at least two years of work", but I guess the younger generation (especially in China) do miracles like we all used to do in earlier days and can do these "two years of work" in a couple of weeks...

[glasnost]

Originally Posted by tigran

H2O? This stuff runs only on HD, not H2O...

Or are you intending to port the entire operating system from H2O to HD? (as far as I understand at least the X server and the Linux kernel will have to be ported, so if someone approached me I would estimate "at least two years of work", but I guess the younger generation (especially in China) do miracles like we all used to do in earlier days and can do these "two years of work" in a couple of weeks...

Ah. Well, that's disappointing. I take it I can't just use sed to work miracles ;-) I was under the misimpression that h2o=hd with a different screen & waterproofing, but otherwise the underlying guts were the same.

[tigran]

I have installed Sage on this distribution and it is running fine --- even the notebook interface works! See the screenshot attached. The version of Sage installed is 6.9 ARM downloaded from the official place:

http://www.mirrorservice.org/sites/w...arm/index.html

It would be nice to see if the latest (7.3) can be compiled from sources on this machine. Anyway, 6.9 is good enough...

Also, all scientific packages like numpy/scipy/matplotlib all work fine (but 50 times slower than on my desktop, naturally). I think this is the smallest useable "scientific pocket workstation" in the world.

Btw, I was surprised to see that the screenshot is produced in colour. Obviously, the real thing has no colours, being an eInk. But this is a real screenshot --- not photoshoped or coloured or anything. And the timings of calculating "prime pi" function are real too, of course.

The other alternative is to run Termux (see http://termux.com ) on an Android mobile or phone, but it only has python+numpy. Not even scipy or matplotlib, let alone the full Sage...

[tigran]

I have compiled Embeddable Common Lisp (ECL) 16.1.2 and then compiled Maxima 5.38.1 on Kobo Aura HD. It works perfectly, even plotting works. Screenshot is attached.

Btw, it also works in Termux on Android phones and tablets, see here:

https://github.com/termux/termux-packages/issues/474

[eReader fan]

Tigran, I am absolutely interested in this and have a Aura HD in my hands. I hope I wil have time this week to start playing with this.

I plan to use the linux kobo as a VNC screen for my android phone or as a text editor, and of course, getting involved in the Unix world , a universe about I know almost nothing

Many thanks to every person who worked in this project.