Is Onyx slowering devices via firmware?

[pazos]

Originally Posted by ottischwenk

Look.

You linked something that you seem to ignore.

Any GPU, embedded in any SoC, is capable of doing 60FPS since GingerBread days.

On any modern operating system applications don't drive hardware directly.

In the case of screens they ask the kernel for a representation of the screen as a memory buffer, they write pixels to that buffer and, when ready, they do a system call to the kernel passing that representation. The kernel is the one that does write to the screen.

With one big caveat:. On e-ink screens there's no such thing as a parity between what's the screen holds and what you can see on the screen. That's because you need to ask the screen (again, via the kernel) to refresh its contents after they were wrote to it.

Whatever makes these devices faster than other android e-ink devices happens after the screen is filled with the pixels, shortening the time used to actually refresh the screen.

It is a big improvement over old methods, namely skip 50-55 frames per second or reduce the bit depth of the representation.


tl;dr:
The GPU helps the cpu doing maths (like rasterization of vectors) before the CPU writes those bytes to the memory buffer. No GPU is capable of speeding up e-ink screen.

The thing that onyx marketered as a GPU does something after the memory buffer is filled with bytes and "drawn" to the screen.

[ottischwenk]

Originally Posted by pazos

The thing that onyx marketered as a GPU does something after the memory buffer is filled with bytes and "drawn" to the screen.

No, this thing draws the bytes to the screen - the screen has no other connections.

[popej]

My guess is that it works between chipset GPU and eink display. Like for example GPU writes to SRAM bufer (Winbond chip) and FPGA transfers data to display with specific optimization for eink. Maybe fixed procedure (BSR) implemented in FPGA.

[Renate]

Mmm, we seem to be talking in circles. I'll leave the nomenclature for others. But I have some experience in drawing Linux frame buffers and updating Eink displays.

Android draws on Linux framebuffers, like /dev/graphics/fb0. Tell Android Canvas.drawCircle and it does make pixels change in the frame buffer. The actual circle is usually drawn by the Qualcomm GPU (Adreno and others). But it could just as well be drawn strictly in software.

If you've got a CRT or LCD you will see the circle immediately. You can do a screen grab and you will see the circle. An Eink panel remains as it was, without the circle.

Onyx uses ioctl(fd, SET_EBC_SEND_UPDATE, struct mxcfb_update_data *update) to actually update the Eink. The pedigree of this dates back to Freescale iMX6 processor I believe, which was specifically designed for Eink.

Underlying this in simple Onyx I presume is simple software scanning the frame buffer, calculating changes and issuing waveforms to the Eink.

Underlying the "fancy-schmancy" Onyx I presume is something taking the LCD data directly off the Qualcomm chip and doing the differences and the updates itself. Such a process would be akin to the Mira which takes in HDMI or DisplayPort.

The easiest way to check this hypothesis would be to examine the pin/pad multiplexor on the Qualcomm to see if the LCD lines are being used.

I wrote multiplexor dump programs for the OMAP and the iMX6 processors. The problem with doing this for the Qualcomm SDM662 is a lack of documentation on the mux. If anyone knows where it is...

If somebody has one of the BSR units open, I'd appreciate a good photo. If, as the Onyx graphics shows, this uses a leaded package it would be easy to scope out the pins. And if anybody wants to donate a BSR unit with a broken screen...

Edit: ottischwenk had pointed out here the chips being used for BSR. The FCC photos show them to be BGA packages (i.e. with tiny connections underneath). This would be difficult to do any sleuthing with hardware-wise.

[eReader fan]

Despite this conversation is a complete offtopic of the original topic...

Is ghosting lower with this technology? I knew about it, but since I have read you talking about it I didn't think it could help in the video ghosting problem. There are some users with severe eyestrain problems who use eReaders for a full multimedia experience, like me, and we need less ghosting.

If the video ghosting isn't lowered by the technology itself, I think it's moment to develop and algorithm for video playback with less ghosting. Now the tech is mature enough.