[schuhumi]

Originally Posted by 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.).

I understand, thank you very very much for that thorough explanation @NiLuJe !

The last few days I did this:

• started with an automatic A2 mode in fbink-xdamage. Now it keeps track of areas which are subject to change, and xdamage rectangles that intersect those areas get added to the area. All that is so that the rate of change in each area can be tracked, and when it's less than 500ms between xdamage events, A2 mode is activated for that area. When the quick xdamage events stop again a normal refresh+flashing is done to clear up the ghosting. What I'm not too happy about right now is the criterion for switching to A2, because even simple stuff like opening a terminal window triggers a number of xdamage events. I think I'll go for something like "if user drags the finger on the screen" or something like that. The ugly code: https://github.com/schuhumi/fbink-xd.../master/main.c
• I reached out to Marc Juul who does the http://fread.ink/ project because I had trouble getting his free graphics driver to work. That turned out to be an issue with compiler (or rather linker) flags because Alpine Linux uses muslLibC, so no ldconfig and so on. I figured out how to packages stuff for Alpine, so I'll clean up all the things and also provide APKBUILDs ofc.
• I fiddled with xf86-input drivers, and settled with evdev which provides fully working multitouch -yay! So there's drag to scroll in all GTK3 apps as well now, and also pinch to zoom

So in essentially I got the graphics working completely inside Alpine without the Kindles Xserver / Xephyr.

You can see a short video here with drag2scroll (Chromium and GTK3), pinch2zoom, GTK3 touch-text-selection and auto-A2-mode working here:



Stay tuned for the next update, I "only" need to package everything properly and create a new release