How to control e-ink refresh?

[knc1]

Originally Posted by bulsa

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).

I mean that Amazon/Lab126 has modified the GTK libraries on the device to deal with the e-ink display.

And it is a mystery to me why you would have to go outside of GTK to control the display.

Please post a short example of the code which displays the problem you are trying to solve.

[bulsa]

The problem is not what I want to do, the problem is that I want to do it without ghosting.

[knc1]

Originally Posted by bulsa

The problem is not what I want to do, the problem is that I want to do it without ghosting.

We are willing to help you, but not to play word games.

Attach a working sample of the code that illustrates the ghosting you do not want.
Once we (any of us) can duplicate what you are seeing, we may be able to give specific guidance.

[hawhill]

I think that bulsa will probably be correct in assuming that GTK does only "fast" refreshes, which leave a bit of ghosting on the display. I'm also about sure that the GTK modification will *also* du "full" refreshes, i.e. going through a black/white transition - it'll just look too bad if they didn't. I guess they implement it similarly than I did - use some kind of limit on screen space and number of fast refreshes to trigger a full refresh.

However, even if they *did* implement it in GTK, then I'm really asking myself what way they use. It would show on an strace for the process using GTK. Plus, it would be also subject to the race condition bulsa talked about before. Then, as I consider that condition mainly being theoretical, Amazon's engineers might have chosen to go for that compromise, too.

[bulsa]

Since you insist on code, here is a trivial example that over time produces quite a nice pattern (imho ):

#include <stdlib.h>
#include <glib.h>
#include <cairo.h>
#include <gtk/gtk.h>

static gboolean on_draw_event(GtkWidget *widget, GdkEvent *gdk,
                              gpointer user_data)
{
    GtkAllocation allocation;
    gtk_widget_get_allocation(widget, &allocation);
    int size = rand()%100+10;
    int width = allocation.width, height = allocation.height;
    int x = rand()%(width-size), y = rand()%(height-size);
    double color = rand()/(double)RAND_MAX;
    
    cairo_t *cr = gdk_cairo_create(widget->window);
    
    cairo_rectangle(cr, 0, 0, width, height);
    cairo_set_source_rgb(cr, .5, .5, .5);
    cairo_fill(cr);

    cairo_rectangle(cr, x, y, size, size);
    cairo_set_source_rgb(cr, color, color, color);
    cairo_fill(cr);
    
    cairo_destroy(cr);
    return FALSE;
}

static gboolean update(gpointer widget) {
    GtkWidget *darea = widget;
    GtkAllocation allocation;
    gtk_widget_get_allocation(widget, &allocation);
    gdk_window_invalidate_rect(gtk_widget_get_window(darea), &allocation, FALSE);
    return G_SOURCE_CONTINUE;
}

int main(int argc, char *argv[])
{
    GtkWidget *window;
    GtkWidget *darea;

    gtk_init(&argc, &argv);

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);

    darea = gtk_drawing_area_new();
    gtk_container_add(GTK_CONTAINER(window), darea);

    g_signal_connect(G_OBJECT(darea), "expose_event",
                     G_CALLBACK(on_draw_event), NULL);
    g_signal_connect(window, "destroy",
                     G_CALLBACK(gtk_main_quit), NULL);

    gtk_window_set_default_size(GTK_WINDOW(window), 400, 90);
    gtk_window_set_title(GTK_WINDOW(window), "L:A_N:application_ID:net.bulsa.example_PC:N_O:U");

    gtk_widget_show_all(window);

    g_timeout_add(300, update, darea);

    gtk_main();

    return 0;
}

[bulsa]

After some more research I have finally found out I am not the only one to notice this problem *yay*...
In HackedUpReader they just insert a sleep(1) before a full refresh.

Could anyone give me pointers how to find out what amazon does for their reader app? As mentioned previously I have already tried strace'ing basically everything that has an open handle on the framebuffer, but no luck there (at least no ioctls).

[hawhill]

It just might not have a handle open when you were scanning processes.

You could preload a wrapper to ioctl() and filter out the ones that go to the framebuffer. It's a bit messy, though, and probably needs fiddling with the rootfs.

Other than that - no idea, sorry. I would still continue to fiddle with strace, and have it follow forks (-f/-ff) too. Restrict it with "strace -e trace=ioctl,open" so you don't have to wade through all the calls. I think the eink fb driver (which is open sourced and included in the kernel sources!) only has ioctl() and /proc based APIs. So it's definitely one of those.