How to control e-ink refresh?

[bulsa]

Hi,

I am playing a little with writing in C for the Kindle PW (using gtk).
It works generally fine, but I cannot find a way to do a full e-ink refresh.

I dug a little in the obfuscated class files for kindlets (KRepaintManager) and I found that it calls setSensitivity in KindleFrameFactory before and after repaint, but there I got stuck. It calls setWindowParameter with some parameter "S", but I have no idea what that does (I was not able to decompile parseWindowParams).

Of course I can just open the frame buffer and do it like I would on my old K3, but surely there has to be a better way?

[bulsa]

Is there relly nobody who knows how to do this? Or is it just impossible?

[hawhill]

No, you didn't descibe enough of what you're doing ("playing a little with writing in C"). I'm also unsure why you're searching in the Java code when you're going the native code route. The interesting parts for you would be in the native libraries for the Java framework, not the Java code.

Opening the framebuffer and doing the proper ioctl() ought to work just fine, though. I'm not sure if there's an API for the X11 layer, though. Anyway, you didn't tell whether you are using that.

[bulsa]

Yes I was looking for some way to do it in X11. My problem being that strictly speaking if I do refreshing via ioctl I have a race condition between X drawing and the eink screen rereshing.

As far as the Amazon framework is concerned, I have not dug deep enough to even discover which native methods it calls. Also I think I have already seen the effect of such a race condition in the Amazon reader, where it first does a full refresh and then draws different contents.

[knc1]

Originally Posted by bulsa

Also I think I have already seen the effect of such a race condition in the Amazon reader, where it first does a full refresh and then draws different contents.

That is designed-in (on purpose in this case) -
It minimizes "ghosting" and improves contrast on the e-ink screen.

Some models / firmware versions allow user control of this feature.

- - - -

You may want to read up on the lipc and eips controls -
and/or
Read through how other people are doing screen controls -
yeah - I mean read other people's code - it is one of the reasons everyone here publishes their code.(*)

For instance - the posts of twobob - he has done a lot of work with the Kindle display handling in the applications he has ported.

(*) If you are doing an application for the Kindle, people who help you here will be expecting that you will post your code somewhere, with an OpenSource license.
It is rare that anyone will get any help from the members here on building closed source software.
(Well, intentionally that is, the Doukan Project and Lab126 take lessons here - without giving credit.)

[bulsa]

Originally Posted by knc1

You may want to read up on the lipc and eips controls -

I don't see anything there that would help me avoid the problem of the full refresh happening BEFORE the stuff I draw with X lands in the framebuffer.

Originally Posted by knc1

Read through how other people are doing screen controls -
yeah - I mean read other people's code - it is one of the reasons everyone here publishes their code.(*)

I've done a little of that already, however I could use some pointers here...
Specifically I have looked at koreader, which thoroughly ignores X as far as I can see and draws directly to the framebuffer, and at kterm, which does no eink specific repainting at all.

Originally Posted by knc1

For instance - the posts of twobob - he has done a lot of work with the Kindle display handling in the applications he has ported.

If there was a function that lists a users posts here, I would gladly follow your advice ... Am I blind?

[knc1]

Originally Posted by bulsa

- - - -
If there was a function that lists a users posts here, I would gladly follow your advice ... Am I blind?

https://www.mobileread.com/forums/sho...d.php?t=237083

[bulsa]

So I have read through a lot of stuff... I know now yet another racy way to repaint the screen:

echo 1> /sys/devices/platform/mxc_epdc_fb/mxc_epdc_update

But still as I have no idea when the X server is writing my stuff to the framebuffer, when should I call this?

Can you point me to any code that a) uses GTK/Qt/etc. for drawing and b) does full eink refreshes without race conditions? I have not seen such code anywhere.

An interesting thing I came across was this einkdamage tool, but I gather nobody really knows what it does, is that correct?

[knc1]

You may want to give up on writing to X11 and use the GTK (or QT) framebuffer driver.

The major challenge is the fact that the e-ink display is meta-stable (I.E: not scanned/refreshed at a fixed rate the way a dynamic display is run).

[hawhill]

And yep, Koreader ignores X11 completely. The reason is mainly historically: There wasn't X11 in the Kindle models up to and including Kindle 4.

In fact, I wouldn't be surprised if there wasn't any X11 protocol based API at all. I think Amazon's tech staff just introduced X11 for convenience (GTK, webkit, window management all readily there). But adding e-ink to the game - I wouldn't be surprised if they'd chosen the dirty way.

On a theoretical level, looking from the application's perspective, it's probably a race condition. But when you look at it from the framebuffer driver's perspective, it isn't. You can refresh, you can repaint pixel-wise - both things will be done atomically. There's no order guaranteed, so there's no "right point in time" specification-wise. In a practical sense, however, there is. We're talking single CPU, so a single threaded application will paint, then sync. X11 is special, and probably a game-changer in this regard.

I think analysis hasn't been done yet for this. If I were to start it, I think I would make the framework use TCP as transport protocol, then dump the traffic using tcpdump and use wireshark to look at it (it has a X11 protocol dissector). Maybe there isn't anything to see, though. So alternatively, I'd attach strace to a client and look for refresh ioctl()s.

[knc1]

Looking at twobob's port of gcalculator (its also in the Kindle Menu package) may help.
(It is a gtk app.)
- - - -

PS: Unless things have changed recently, the QT framebuffer driver has not been maintained for a long time. (The Buildroot project dropped it for that reason.)

[bulsa]

Originally Posted by hawhill

So alternatively, I'd attach strace to a client and look for refresh ioctl()s.

I've already done that before and was unable to find any process that refreshes via ioctl for the framework, that is what lead me to asking here.

Edit: Concerning gcalculator, I'd love to have a look, but I cannot find the source modifications twobob made anywhere (distributing binary without source notice is technically speaking is a violation of the GPL).

[knc1]

He mentioned he only changed the glade settings.

Have you checked his public repositories on the various repository sites.
It is not like twobob to fail to post sources.

[knc1]

Originally Posted by knc1

He mentioned he only changed the glade settings.

Have you checked his public repositories on the various repository sites.
It is not like twobob to fail to post sources.

Made a fresh review of the posts - -

There is no mystery to the refresh for GTK apps on the Kindle - that has been built into the GTK build supplied on the Kindle by Amazon.

Just use (link against) the Kindle libraries - -
https://www.mobileread.com/forums/sho...d.php?t=189372

[bulsa]

Originally Posted by knc1

There is no mystery to the refresh for GTK apps on the Kindle - that has been built into the GTK build supplied on the Kindle by Amazon.

Do you mean a full (flashing) refresh our just a normal 'update'?
Because the former still is a mystery to me (when not done manually with sysfs/ioctl).