PW3 Can run full blown Chromium browser on up-to-date Alpine Linux

[CarlosMC]

Originally Posted by kindle72

Wow, that looks great!

1) is there a video available? to see how it really feels?
2) is it possible to rotate the desktop to landscape?
3) is it possbile to map the buttons (Oasis)?
4) is it possible to play music over bluetooth?
5) is it possible to connect a keyboard + mouse over bluetooth?

thanks!

same doubts here!

[zaoqi]

Originally Posted by kindle72

Wow, that looks great!

1) is there a video available? to see how it really feels?
2) is it possible to rotate the desktop to landscape?
3) is it possbile to map the buttons (Oasis)?
4) is it possible to play music over bluetooth?
5) is it possible to connect a keyboard + mouse over bluetooth?

thanks!

Someone said that lab126 did not ship all Bluetooth drivers.

It may be possible to connect a keyboard + mouse over otg if you compile+load some kernel modules.

[zaoqi]

Originally Posted by kindle72

Wow, that looks great!

1) is there a video available? to see how it really feels?
2) is it possible to rotate the desktop to landscape?
3) is it possbile to map the buttons (Oasis)?
4) is it possible to play music over bluetooth?
5) is it possible to connect a keyboard + mouse over bluetooth?

thanks!

It may be possible to rotate the desktop to landscape.

1) "L:A_N:application_ID:xephyr_O:R_PC:N" / "L:D_N:application_ID:xephyr"

https://github.com/schuhumi/alpine_k...e_image.sh#L57
2) `xrandr -o ...`

[kindle72]

Thanks, that would be great to rotate the desktop. Typing on an Oasis in portrait mode is a bit complicated because the body is asymetric.

Bluetooth audio could work, because Oasis supports BT audio?

How about a demo video to see how it works at all?

Thanks!

[knc1]

Originally Posted by kindle72

Thanks, that would be great to rotate the desktop. Typing on an Oasis in portrait mode is a bit complicated because the body is asymetric.

Bluetooth audio could work, because Oasis supports BT audio?

How about a demo video to see how it works at all?

Thanks!

Bluetooth audio works on Amazon provided products, not a general purpose BT stack.

You need to build the full BT stack for the Amazon Linux kernel you intend to run.

[kindle72]

Thanks for clarify!

Is there someone who installed it and can make a video how it works at all? I don't want to jailbreak my Oasis to see that it works a lot different than expected from screenshots only.

[schuhumi]

UPDATE
Big news: There's now a KUAL Launcher for this! That does:

• Easily install Alpine Linux on your Kindle, you only have to put the small KUAL extension in your "extensions" folder to get going with all this Attention for anyone trying!! -> Do NOT connect your Kindle to your computer while Alpine is running if you have not enabled USBNetworking! When it goes into USB mass storage mode while Alpine is running, it will destroy the partition! (and possibly even brick, I'm not sure)
• Drop into Alpine shell
• Start Desktop
• Remove Alpine Linux from your Kindle
• Update itself
• It can also install kterm in case you don't have it yet, it's a dependency

You can get the latest release here: Releases page (download the zip)

Also the Alpine Linux install itself has some improvements:

• Chromium now comes with uBlock Origin preinstalled, to cut down on ads and thus CPU & RAM usage
• Onboard works on the lockscreen now
• Small stuff to make this more robust across Kindle models

Also I made a small video so you can see how it looks in action:

(It is not done processing yet though, come back later if it still doesn't work)

Originally Posted by NiLuJe

Fair warning: I have *no* idea what all this is for xD.

The modern variant of this appears to be something like that, although that's not actually aimed at boards w/ an EPDC, which use an older kernel. Also possibly not aimed at the right boards *at all* (that certainly targets at *least* an i.MX6 w/ a Vivante GPU, which I don't think is the case on Kindle & Kobo, we only have the PXP).

I think *someone* managed to dig up the proper tree from NXP a few months ago (possibly on the Kobo forum), FWIW.

----

Back on planet Earth, IIRC, on Kindle, the actual job of requesting eInk refreshes is deferred to awesome via the ligl lua bindings.
That said, I never really looked all that much into it, short of enabling debug logging to mimic its behavior in KOReader.

Thank you very much for all your great advice NiLuJe, I'll have a deeper look into this

Originally Posted by JJYYPPCC

Hello schuhumi I am using your Alpine image to reply you(Because my skipstone can't login to forum),but emmmm,not everything is good as I thought.
·After trying I could make sure that it doesn't like any Usb devices except charge line.(Though I successfully use ADB to install .apk on my HUAWEI Watch through WIFI).
·Though Chromium is so perfect that could be use to watch LIVE,but it cannot afford 2 tabs.(Maybe because of performance or need time to improve)
·Right click on the panel is harder than long-time press to use.
·Onboard's input upper cases is a monster!I must click Capslock many times to input the upper cases I need.
·Cannot open *.AppImage(Because of performance I do not want to make any packages on Kindle)
——————————
A strange thing:There is a package manager "pacman" could be installed by "apk".It looks norml but I don't know how to use.Is it useful?
That's all.Maybe.XD

Incredible that you had the patience to type that out on that slow onscreen-keyboard :P I'm glad that it works for you so far. Yeah USB OTG is a bit complicated, I have looked into it only enough to understand that it is probably quite some work to get working. Regarding multiple Chromium tabs: Keep in mind that this is a low end device with tiny amounts of RAM (512MB). So if you load heavy sites it will fill up quicky. In this new release Chromium comes with uBlock Origin preinstalled, that cuts down on RAM and CPU usage because ads (and the javscript embedded in them) don't get loaded.
I'm aware of the right click issue, it is due to how Xephyr works. I maayyy be able to resolve it in the future, but for now it sadly only works in Chromium as intended (Chromium supports interpreting a mouse device as touchscreen. And Xephyr converts the touchscreen events to mouse events, hence no regular long-tap for right click).
Onboards upper case: Try clicking on the upper case key twice! That locks it
Regarding AppImages I would be careful, keep in mind that this device only has a teeny-tiny CPU and RAM. Alpine Linux is geared towards a low ressource footprint (with stuff like BusyBox and Musl-libc instead of gnuLibc). AppImages package all their dependencies and thus have gigantic footprints, also in general are not tailored to low end devices, so they might just not work due to hardware requirements. Also I'm not sure whether they're compatible with Alpine in general, remember gnuLibc is missing for example.

Originally Posted by kindle72

Wow, that looks great!

1) is there a video available? to see how it really feels?
2) is it possible to rotate the desktop to landscape?
3) is it possbile to map the buttons (Oasis)?
4) is it possible to play music over bluetooth?
5) is it possible to connect a keyboard + mouse over bluetooth?

thanks!

1) Yes made the one above for you
2) Yes it is, try the KUAL Launcher "Drop into Alpine Linux shell", then rotate the screen to landscape (two finger tap for context menu -> rotate screen), then run "/startgui.sh". The only problem is that I haven't found a reliable way to script that yet.
3) I have no idea, I only have a Paperwhite 3 to try stuff out on
4+5) PW3 has no bluetooth, so I can't test anything. Also see knc1's answer, it's not that easy sadly..

[kindle72]

Now there is a video in Youtube. Search for Kindle Alpine Linux. Thank you! Time to Jailbreak...

[schuhumi]

Originally Posted by kindle72

Now there is a video in Youtube. Search for Kindle Alpine Linux. Thank you! Time to Jailbreak...

Sorry I meant to post it immediately, but it took some time to get approved so it ended up above yours now. Also I messed up the youtube embedding, here you go:

[kindle72]

Can't Jailbreak. I saved update_kindle_oasis_9th_factory_5.9.0.6, but my Oasis2 came with 5.9.2.x. No downgrade possible.

Keep this project. It's fantastic!

It's just what I need, a small Linux PC for reading News and Shell in direct sunlight. Devices with Android are old at arrival, that's the reason why I don't buy Onyx and the others.

[schuhumi]

Originally Posted by NiLuJe

I have no experience (at all) with X drivers, but, technically, yeah, once you have a rectangle's coordinates/dimensions, you're only an fbink_refresh() away .

Thank you NiLuJe for your excellent FBInk!!

So some copy&paste + trial&error later here it is: a xclient that refreshes the epaper display according to xdamage events!

Here's a small video: https://imgur.com/gallery/obzmkbW
(That update with 72px height every second is the clock in the right bottom corner)

Here's the repository (+ a small guide on how to use it): https://github.com/schuhumi/fbink-xdamage

It is very hacky right now, but at least it seems to work just fine. I tried all this in the Alpine container, and I'll try to make an Alpine package out of it. Also I'm very happy that a xclient (like a regular x window) can listen to xdamage events and I don't need to fiddle with the server itself.

What's not working so far is Alpine's xserver (did "stop x" and "X" outside the container), because I still didn't get xf86-video-imx (not vivante, epdc) to work. Porting from Amazon sources to newer xorg version seems not so easy. I got it to compile (modify x calls + include header of the original kindle kernel) and recognize the library. But startx fails with:

[119306.969] (II) LoadModule: "imx"
[119306.969] (II) Loading /usr/local/lib/xorg/modules/drivers/imx_drv.so
[119306.970] (EE) Failed to load /usr/local/lib/xorg/modules/drivers/imx_drv.so: Error relocating /usr/local/lib/xorg/modules/drivers/imx_drv.so: imxExaZ160Setup: symbol not found
[119306.970] (EE) Failed to load module "imx" (loader failed, 0)

The other route seems to be modifying xf86-video-fbdev to work with that Y8 pixel data format. But then also all acceleration is gone.

Edit: Also there's a "small" problem where without Xephyr GTK3 windows are just empty using Kindle's X. I'm not sure wether that is due to the old version or some missing feature or whatever. Only the menu/panel/window borders/etc and chromium show their content fine.

[WaseemAlkurdi]

Great work! Absolutely great!
I have a question ... would it work with Kindles with 256 MB of RAM?
The KT2 (Kindle 7th generation) which I own has the same capable CPU as on the Paperwhite, but not the same amount of RAM (256 MB vs 512 MB). Would this be an issue?

[NiLuJe]

@schuhumi: I'll be mildly curious to know, once people with a PW4/KOA2/KT4 try this, whether ordered dithering actually behaves as expected .

It *should* (and it certainly does on similar Kobo HW), but when we enabled it in KOReader, we got reports about extremely broken quantization... :/.

(It's fairly easy to check with the fbink CLI tool and a random image, FWIW ).

[schuhumi]

Originally Posted by WaseemAlkurdi

Great work! Absolutely great!
I have a question ... would it work with Kindles with 256 MB of RAM?
The KT2 (Kindle 7th generation) which I own has the same capable CPU as on the Paperwhite, but not the same amount of RAM (256 MB vs 512 MB). Would this be an issue?

Thank you! It should work, but webbrowsing will probably be an issue. Desktop only + htop amount to 140MB. Desktop + Chromium with 1 light tab open (mobileread.mobi) is 240MB already..

Originally Posted by NiLuJe

@schuhumi: I'll be mildly curious to know, once people with a PW4/KOA2/KT4 try this, whether ordered dithering actually behaves as expected .

It *should* (and it certainly does on similar Kobo HW), but when we enabled it in KOReader, we got reports about extremely broken quantization... :/.

(It's fairly easy to check with the fbink CLI tool and a random image, FWIW ).

Haha that's just a random value I plugged in there for whatever reason and then forgot about it.. As far as I can see there's no way to see any dithering with fbink_refresh on a PW3 because HWD_* is unsupported and "fbink_cfg: Pointer to an FBInkConfig struct. Honors wfm_mode, is_nightmode, is_flashing" i.e. doesn't honor sw_dithering? To be brutally honest I haven't yet understood what the benefit is, probably just for A2 right?

Also after a A2 refresh the only way to get rid of ghosting is probably "is_flashing=true;"? A2 is really cool for scrolling (yay this whole things allows for all waveforms to be used ), but the flashing afterwards when drawing with WFM_GC16_FAST is kinda offputting. I would like to also put in some semi-smart optimization like A2 refreshes when a lot of damage events come in (or when the user drags the finger on the screen), and then do a high quality refresh afterwards..

[NiLuJe]

@schuhumi:

I'll need to recap a few things in order to make the distinction between the is_dithered/sw_dithering FBInkConfig fields, and the dithering_mode argument to fbink_refresh() clearer .

Only very recent devices ship an EPDC that actually supports hardware dithering (Kobo Mk.7, for sure; and potentially Kindle Rex & Zelda).
The driver theoretically supports various dithering algorithms, but, on those devices, in practice, only ORDERED (and, of course, nothing, i.e., PASSTHROUGH) are supported.

In order to be somewhat future-proof (and/or make testing those easier), fbink_refresh allows setting those unsupported modes (in which case the driver safely fallbacks to PASSTHROUGH), hence the dithering_mode argument and the matching enum.


But, for stuff where the refresh is implicit (i.e., everything else ;p), this means we don't need to be able to set a specific algorithm: hence is_dithered, which will use ORDERED behind the scenes.

sw_dithering, on the other hand, is specific to image drawing, and does the dithering in software .

When it's supported, ORDERED will be tweaked to match the expectations of the specific waveform mode used (i.e., B&W for A2/DU, 8 or 16 shades of gray otherwise).
So its use is not limited to A2 (f.g., on Kobo, every screen with an image gets dithered that way, and those are usually GC16, either directly, or via AUTO).

On the other hand, sw_dithering will always dither to the exact 16 'color' eInk palette.

----

A2/DU are designed to be fast, at the expense of ghosting, yeah. You can request a flash with them, but they won't actually flash, and it may not actually help all that much (or at all) with ghosting .

From what I saw on my PW2 with the whole doom fire experiment, AUTO takes some pretty smart decisions depending on the content of the region . Which means it should often be using the *_FAST variants or DU for B&W content.

Which means, that, yeah, if you want to be specifically using A2/DU at some key moments (i.e., scrolling), you'll have to do that yourself .

----

As a rule, with FBInk, if you're not sure of a setting, the default is 0 and should behave sanely in most cases . (f.g., wfm 0 is AUTO, dither 0 is PASSTHROUGH, etc.).