"full" terminal for kobo?

[lukeoftheaura]

There are a few terminals available in kobo (one as a script in kobo start menu, another in KOReader) but is there a "real"/"full" (ANSI compatible) terminal available on the kobo? I know for a fact that the kobo has a version of vi available and I'd like to see it running on the device's display itself rather than over telnet or something similar.

[Python Master]

What's the problem with running it over telnet?

[lukeoftheaura]

Originally Posted by Python Master

What's the problem with running it over telnet?

I want it on the device because there's no point in having vi on kobo if I can't run it on a kobo only, if I have to use a telnet terminal I may as well just use vim on my PC. I want to see what kobo vi is like running on the kobo display itself.

[cramoisi]

I think there is something more complete in "pbchess", check that out ! :-)

https://www.mobileread.com/forums/sh...d.php?t=201632

[kisonecat]

I ported a framebuffer-based terminal emulator (fbpad) to the Kobo eink devices (specifically the Kobo Aura ONE, but I think any Mark 6 device would work). The code is at https://github.com/kisonecat/fbpad-eink but I'll try to package it a bit more nicely. The main application is that, with ssh and tmux, it is possible to use the kobo as an external display on sunny days.

[pascal jakobs]

I'm very interested by your terminal. have you progressed in the packaging?
I would like to use my kobo as raspberry pi display so terminal +ssh +tmux is the minimum to start.

[NiLuJe]

I refrained from saying it the first time around to see if that was just a quick PoC hack that would later be cleaned up, but: that's *really* not how you should be using FBInk .

You can simply use it as it was meant to (i.e., a library), passing fbpad's open fb fd to fbink_init() at init, and then using fbink_refresh().
If you were worried it would be making a (in this instance) useless mmap, rejoice: it won't (it's only setup on-demand by stuff that actually requires writing the the fb, which _init & _refresh don't). Which means you won't have to use fbink_close() on teardown, either.

Also, honoring credits, licenses, and all that jazz, that'd be a plus, too .

[kisonecat]

Wow! I am very much honored that you replied NiLuJe!

I've added credits to a readme and added the AGPL license file, which I think is correct given the licensing of fbpad. I am really thankful that you pointed this out.

As is surely clear, I had no idea whatsoever about eink when I started (e.g., I spent a while before realizing I even needed to do any refreshing...) so your code let me get fbpad working very quickly on my kobo device. I really appreciate it.

Using FBInk as a library is definitely the right choice. I'm certainly not happy with how this I put together that version in April.

[rien333]

I've already opened up a github issue, but in case anyone can help me here quicker:

I've successfully compiled fbink for my Kobo (I think), using the cross-compiler tools from the arch linux repo. How do I tell fbpad-eink where to look for the relevant fbink files? If I just run make in the fbpad-eink directory on my linux PC, it (obviously) errors with "refresh.c:12:10: fatal error: fbink.h: No such file or directory".

[NiLuJe]

I won't duplicate what I mentioned on GH, but here's another warning:

I'm not familiar with the details of the arch cross-tools, but see this bit of the FBInk doc about toolchain shenanigans, so you don't get surprised if stuff blows up in fun and interesting ways at runtime ...

(There's a very good chance distro-provided cross-toolchains will target a much, much, much too recent glibc/kernel combo, which won't do here).

[rien333]

I'm really just starting to dip my toes into the linux world of Kobos, so excuse me if I'm wrong, but Kobo Clara HD devices seems to ship with to a pretty recent kernel (4.1), looking at the uname output shown in this tutorial.

My cross-compiled binary comes out with the following kernel version (not saying the rest is correct/asking for further build assistance, the fbpad-eink author should probably fix something first):

$ file fbpad
fbpad: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=9e276f0c2a0318a71301d393266a43df086f93cb, for GNU/Linux 3.2.0,with debug_info, not stripped

The glibc version and other stuff shipped from the Arch Linux AUR could still be incorrect though.

[NiLuJe]

The kernel issues are generally sneakier (that'll usually mean kernel API/syscalls that aren't actually supported on the target device get detected and compiled in as "available", which is bad, and not necessarily readily visible until you hit strange runtime failures in some sneaky corner-cases).

The main issue is the glibc version pulling in newer symbols, for much the same reasons (they're in the header, they look available/usable, they get used). Once you hit the target device, the dynamic loader will complain about undefined symbol(s) and refuse to run your stuff.

The more obvious potential issue with the kernel is the minimum supported kernel version set at compile time by the glibc. That's what gets reported by file, and, indeed, it's rarely an issue (unless you target older devices, which do still run Linux 2.6.xx).