1

I've been looking a lot around, and can't find much of anything clear. The context is I have a stylus-enabled e-ink tablet that I program on for fun, and I'd love to use a native library to read the pen events, and draw directly on the framebuffer. The vendor provides one, secret (a .so JNI lib that you can call with just a size parameter).

I suppose this is intended to activate a direct draw on the frame buffer, eventually with a refresh. But I can't grasp how it's supposed to compose with SurfaceFlinger and Android...

Anyone has experience with generic eink tricks to display from JNI via IOCTL that could explain me why I don't see the pixels changing unless I draw myself in java (I can change the update mode and draw quite fast, but... I want the fastest) ?

How could I verify writes on the FB ? Can an android app be "overlayed" by pixels written directly on the framebuffer ?

Pierre
  • 853
  • 9
  • 21

2 Answers2

1

I figured it out in the end. Using strace to catch calls to fb0 via ioctl + lsof + remote debugging of the official drawing applications showed me that I was wrong.

This particular tablet's vendor software, unlike the remarkable, does NOT draw on the framebuffer directly via magic ioctl commands. All it does is register an area of the screen to be non refreshable by Android normal display primitives. That allows them not to configure each and every view in the hierarchy to be in Direct Update eink mode, while using the android framework with as little custom code as possible.

I could see the command passed that way:

[pid  3997] openat(AT_FDCWD, "/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 30
[pid  3997] ioctl(30, _IOC(0, 0x6d, 0x25, 0x00), 0x1) = 0
[pid  3997] close(30)

This simply puts the screen on lockdown and stop all android refreshes.

This means they could be much faster.

Pierre
  • 853
  • 9
  • 21
0

I suggest you write a basic pixel plotting program in C for framebuffer. Execute it normally and then create a JNI call for the same. The speed difference is negligible to notice.

hexaVik
  • 1
  • 2
  • Yeah but in the end I realized the problem I was trying to solve - to bypass java to draw faster - was solved a different way by Sony: they instead tell the driver the area of drawing has to be locked against eink refreshes as soon as the pen is down, which makes the drawing happen instantly, even if simply made via pixel writes in android. – Pierre Feb 10 '22 at 23:11