Kobo Clara BW as thin client?

[enthdegree]

Hello, I'm interested in eventually using a Kobo Clara BW as an ssh thin client. I am no expert on the device yet but it seems the broad steps are:

• Load in the uhid kernel module so that it actually accepts bluetooth keyboard inputs as others have done here: https://github.com/jmacindoe/kobo-ke...ules/tree/main
• Run inkvt

Both would involve cross-compiling to this new device, which I guess has been done since I notice people use koreader on it.

Is anyone more knowledgeable than me aware of why this is a bad idea or if some other major development I'm not seeing is needed?

Thanks

[enthdegree]

Reading through inkvt logic it's unclear whether inkvt will ever actually read from the bt kb input device without some extra steps to read it. Am I mistaken here? It is possible the onscreen kb / --osk flag will do it, since it seems to hook up everying fbink_input_scan finds...

Can't try anything until I have a device...

[elinkser]

OK, I don't have a BW or even a bluetooth-capable ereader, but if I may stick my two cents where it may or may not belong...

-Inkvt: relatively easy to compile on Linux, seems like a pro designed it, but not as easy as Fbpad to get working - in fact the devs literally say:
Warning: this project is very experimental! It might brick your device. Only install this if you know what you are doing.
https://www.mobileread.com/forums/sh...16&postcount=4

-KOReader terminal: Koreader release page on github says initial support for BW, so this could be your backup plan. Basic terminal works fine for shell, ssh, vi, but not so great for w3m.

-SSH: I think lordeagle already installed NiLuJe's kobostuff dev utilities package on Elipsa 2E, which is MTK device like BW. If not, there's Alpine binaries, etc,(not an issue).

Security: I personally don't like using my Kobo as an SSH client to a device that does critical stuff like email. I would much rather use an up-to-date iphone or chromebook, or even an out-of-date Blackberry - you know, a device that has concepts of non-root users, fine-grained filesystem access, sandboxing, firewalls, and stuff like that.
Ironically, by locking down the bootloader for the new MTK series, Kobo also succeeded in locking out Quill/Inkbox, which WAS adressing these kinds of issues!
But if you're SSHing to a non-critical device, I guess it's analogous to securing a beater bike with a lightweight cable lock - I do that too!
Edit: I guess if I ONLY use the Kobo for SSHing (not for javascript browsing,running untrusted apps,running Telnet on public networks,etc)then my attack surface is reduced, analogous maybe to only parking my bike in safe neighborhoods, for short periods, etc...
You may also say "no one is targetting your widdle Kobo." I don't argue with that, but I also won't rely on that as a defence of a high-value (critical) device.Funnily, I did have another bike analogy where I used to lock $60 pawnshop bike with a dollar store lock, and it actually worked for months...until one day I parked it in a rundown neighborhood - had to take the bus home.

Buy or Not:Cmon, where you going to get so much functionality and FUN for such a low price?
It'll probably SAVE you money you would spend on other gadgets, but you will now be too busy for!

[enthdegree]

Thanks for the encouragement, elinkster A few technical questions about the Clara BW, possibly relevant to any new device. I'd be grateful for any help:

• Has anyone successfully compiled its kernel? I got the kernel source from here and pulled /proc/config.gz from my Clara BW. However `make ARCH=arm CROSS_COMPILE=~/[the toolchain dir]/bin/arm-kobo-linux-gnueabihf-` fails in two cases I tried:
  • koxtoolchain nickel env fails at some #preprocessor term in the ARM assembly... not a good sign.
  • gcc-linaro-4.9.4-2017.01 gets past that part, but apparently I don't have all the needed compile-time variables: when compiling drivers/devfreq/helio-dvfsrc-opp.c it can't find the header helio-dvfsrc.h (in the same directory) because it's referenced in angle brackets. If I hand edit that file to quotes it starts failing for the same reason for headers in /drivers/misc/mediatek. I'm not informed enough with the build process to know where these vars should be set.
• In spite of not getting the whole kernel to build, I did manage to compile just the module uhid.ko with `make [...] modules`. But then `insmod uhid.ko` via koreader terminal fails with "device or resource busy." Further, I notice the Clara BW's kernel config already has CONFIG_UHID=y anyway, so it seems like this whole kernel & module build is unnecessary?

To investigate further I have to wait, my device came with backlight defects and I'm getting it replaced.

Edit: ah, just now getting up to speed. This Mediatek SOC signed boot situation is unfortunate: https://www.mobileread.com/forums/sh...d.php?t=363175 . Some words & dump on the same or similar SOC here: https://www.reddit.com/r/kindle/comm...th_generation/ .
Given the similarity I wonder if some work on the paperwhite 5 is not applicable: https://kb.taktpraha.cz/projects/kindlepw5 . The Clara's UART pads are obvious, see here: https://guide-images.cdn.ifixit.com/...MldedEWXk.huge. I wonder if there is anything to be learned during early boot. I don't know what the other 4 pads below the Clara's UART are.

Has anyone learned what exactly fusing these Download pads on the Clara Color PCB does? (presumably the BW has the same pads). I wonder if connecting them during a reboot forces it into MediaTek BROM mode. If that's the case, then I wonder if anything useful can be learned through https://github.com/bkerler/mtkclient, (in particular I'd like to see if the device has any efuses set). Maybe by some miracle a MediaTek bypass implemented in mtkclient will unlock the bootloader. Another slim but obvious first line of attack would be the proprietary chimeratool. At any rate running a new kernel is far more involved than anything I want to do on the device, for now.

[mergen3107]

Signed boot aside, you need kobo toolchain with armhf probably. https://github.com/koreader/koxtoolchain
Run with:
./gen-tc.sh kobo
Then add ~/x-tools/ to PATH.

[enthdegree]

Originally Posted by mergen3107

Signed boot aside, you need kobo toolchain with armhf probably. https://github.com/koreader/koxtoolchain
Run with:
./gen-tc.sh kobo
Then add ~/x-tools/ to PATH.

The kobo toolchain (set up using source [stuff]/koxtoolchain/refs/x-compile.sh kobo env) gives the same issue as nickel (same make command as above):

arch/arm/mm/proc-v7.S: Assembler messages:
arch/arm/mm/proc-v7.S:560: Error: junk at end of line, first unrecognized character is `#'
make[1]: *** [scripts/Makefile.build:393: arch/arm/mm/proc-v7.o] Error 1
make: *** [Makefile:1002: arch/arm/mm] Error 2

[elinkser]

Yes, the CONFIG_UHID=y means already compiled into the kernel, but sounds like you know that already

Are you compiling on a Linux box? Some use docker or vm, but for me MX Linux worked on first try.
Can't say it was due to any expertise,lol.

[enthdegree]

elinkser, what device did you compile a kernel for, how did you set up your toolchain and how did you call make? I’ve set up my dev environment as described above on Debian Bullseye

[elinkser]

Oh I misread your comment.
I did not compile the MTK kernel - just used the KOReader toolchain.
It would be nice if someone put the steps in a nice comment, though don't know what one can do if bootloader won't take the unsigned kernel anyway.
I think NiMa and Szybet from the post you linked looked into it.

[enthdegree]

Alright for now I'm giving up on the mtkclient stuff. shorting those download & reset pins was clearly doing something to the device, but I don't know if it's relevant to boot and I can't get the choreography right for mtkclient to see it. (Or maybe I haven't even got mtkclient working). Got spooked, don't want to brick my brand new device. I think I'll go back to doing userland stuff for now. Maybe some other day...

[enthdegree]

Confirming I can pair my bluetooth keyboard to the Kobo Clara BW out-of-the-box through the BT interface confirming a 6-digit handshake. There's almost nowhere to use the keyboard and the line editor is extremely basic (no key repeat on hold, no delete key, no select/copy/paste), but you can type in the search box and browser URL bar.

inkvt doesn't take any inputs from the device, I'm going to try and fix it

[enthdegree]

With a few small source changes I got inkvt to read from the BT kb evdev without issues. The device seems to lock or die when screen-drawing terminal apps run, which I'm guessing is because of inkvt's very simple buffering logic.
Rather than try to reinvent the wheel I went looking for other options & cross-compiled Debian's patched fbterm (+ deps freetype, fontconfig).

fbterm seems like it could work great: beautiful freetype font rendering w/ DejaVu mono & the emulator didn't choke on 2 tmux buffers + 1 running top. That said, some obvious UI stuff needs rearranging:

1. fbterm itself never asks the eink panel to redraw from the framebuffer, so I had to do it myself blindly in the background with `watch -n 0.2 "fbink --refresh" &`. Maybe fbterm needs a new renderer that calls to NiLuJe FBInk for on-demand local redraw.
2. fbterm input wasn't listening to the BT kb evdev; really it was taking inputs from the SSH tty (ultimately, my host PC's keyboard). Reassuring to see how responsive it is even with this extra hop. Not sure the right way to fix this, but a simple way is to start fbterm with an IM server that grabs the BT keyboard connected to the Kobo.
3. It draws all over the native UI, which itself draws back over fbterm. Wifi disconnects often, Bluetooth turns itself off after a bit, device falls asleep. Other apps are managing this just fine, a helper script could fix all this.

Fixing these seems like a viable path towards a responsive terminal.

[enthdegree]

Thank you for the help everyone! Here's a working prototype. It is beautiful to see running

https://github.com/enthdegree/efbpad

[enthdegree]

And, finally, I got emacs running: https://github.com/enthdegree/kobo-emacs/

It’s realy usable. I wrote the README through tramp.